Case Study Part 1: Adding a process flow diagram to a Q & A driven requirements process

I recently suggested to my boss a way to incorporate a process flow diagram technique in to our requirements gathering process. She liked the idea and allowed me to run a pilot at my last requirements gathering meetings. This is Part one of two articles documenting my experience.

As an Implementation Consultant for a SaaS product, the big kick-off for each project is a 2-day meeting at the customer site. This is a requirements gathering session driven entirely by an online tool that ensures I ask all the critical questions so I can generate the Business Requirements Documents and have the product configured. This question & answer, tool driven process is part of a broader Six Sigma, repeatable and reliable implementation path that the company has invested heavily in over the recent past. This in turn generates lots of data points, measurable and reportable milestones which the QA team use as a stick to beat us lowly Implementation Consultants with when we don’t meet them 🙂

However I felt as though this drive towards fully quantifiable actions and processes had resulted in a very stale and un-engaging requirements meeting. The tool forced the meeting away from a qualitative semi-structured discussion, in to a repetitive question and answer session…for two days!!

  • Where was the consultative approach our implementation procedure and job title highlights?
  • Where was the business process analysis?
  • Where was the free-flowing discussion and use of more traditional BA methods of enquiry and elicitation?

My concerns at this particular issue possibly taps in to a broader problem of operational efficiency programs, such as Six Sigma, throttling fuzzy, qualitative procedures, but that was not my problem to address.  However I saw a great opportunity to include a visualization technique to capture the customers existing workflow that would be directly affected by the new software I am implementing. What I proposed was a business process diagram method, but what that would look like I had no idea at the time.

The key objectives were:

  1. It must be quick and simple to draw / develop in real-time in front of the customer.
  2. It must generate discussion and allow the customer to walk through the process, as it exists today, with no consideration for how it will change with the new software, or more in-depth technical considerations.
Process Flow Diagram Example
Process Flow Diagram Example

This is the example I developed after some online research (thanks to David Morris @GreySkinnedBoy on Twitter for pointing me to the BPMN) and showed to my boss. It builds on a swim lane type method although it will not conform to the linear timeline aspect normally the case with swim lane diagrams.

My hope is that this high level overview and story telling on the customer’s part will elicit requirements that would normally go undiscovered until later in the process. I also want to create a then and now document so the customer will know how the process will look at the end of the implementation, as well as a proposed process flow diagram if efficiency saving options are open following analysis after the meeting.

Overall I hope the introduction of a visual artifact will offer both value to the customer, improve the requirements gathering process and offer more opportunity for real value add consultative work.

Look out for Part 2 next week to see how the pilot went.

Advertisements
Case Study Part 1: Adding a process flow diagram to a Q & A driven requirements process

Does the BA look at the user experience?

Website Prototype; you can't beat paper for starters
A paper website prototype

Just a quick follow up to my last post which aimed to gather comments clarifying a couple of points.  What are the key functional differences between the BA and Information Architect (IA) roles, and how the split falls between requirements gathering and user centered design (UCD).

I am an avid listener to the Spoolcast podcast from User Interface Enginerring (UIE).  It is really informative and Jared Spool always has some great guests discussing UCD and UX topics. One of the recent guests, Todd Zaki Warfel, was talking about prototyping experiences, and during this discussion he touched on the very same role definition issue. Jared at one point posed the question to Todd, does the BA in even look at the user experience? This brought up some interesting points I wanted to share.

Todd felt that the BA’s typical remit on a project was functionality.  What functional requirements does the product need to fulfil.  So although the BA is involved in the design of prototypes, he saw these as being on the wireframe, boxes and arrows, Visio end of the spectrum. A prototype designed to show that the functional requirements elicited from the users and stakeholders will be met, and visually how those functions will look, in their rawest form.

However an Information Architect or User Interface Designer will approach building the prototype by trying to take it that much closer to the final look and feel of the site will be.  Again the functionality will be there, but there would be more care and attention to the usability and user experience with the site.  He also felt that the designer would be more willing to take a risk and create something very new, whereas the BA may be more inclined to stick to existing structures.  He used the specific example of the designer adding AJAX type aspects to their prototypes.

I certainly think that makes sense and although every BA and IA role will vary from company to company and project to project, I can see this line holding true the majority of times.  It does also back up my contention that in fact there is a fine line between the BA role and the UCD process and that the two sides could easily be joined if necessary.  This provides excellent room for growth in a BA’s armory if they can bring in valuable usability and user design techniques and perspectives to the requirement’s gathering remit. Particularly when expressing those requirements visually, which always seems to be the best way to really engage the stakeholders in the requirement’s process as they start to see the result to all the questioning.

Does the BA look at the user experience?