"Requirement gathering" often results in a giant rambling document written in a pseudo business / IT speak that the business says it can not read and the IT guys say is not detailed enough for them to build from, writes contributor Craig Reid. 8 steps to ensure that you are giving the business what they really want.
"Go out to the business and gather their requirements!" is a phrase that immediately fills me with dread. I conjure up images of men in suits wandering through dark forests without maps, looking for mushrooms...needles in haystacks and the like (you get the idea...).
What generally happens is that business analysts go away and do just that - gather requirements - what the business thinks they want. Here is what often happens:
Typically, this results in a giant rambling document written in a pseudo business / IT speak that the business says it cannot read and the IT guys say is not detailed enough for them to build from. So ,the BA goes away and creates a functional spec, which the IT guys love, but by this point in time it has morphed so far from what the business want, they have a heart attack when they see the final product!
"That is not what we wanted!" they say!
"But that is what you told us!" say the BA's and IT guys!
It does not have to be this hard. Here is how you do it:
Step 1: Define the successful customer outcome(s).
What is it that the customer really needs? What does the business need to do to meet those needs?
Step 2: Define the process scope.
Establish what the process actually is from the customer's perspective - current state (if a current state exists!). Do not take the business's word for it - their interpretation of what a process is may be radically different to yours.
Document the process at a high level (e.g., SIPOC) - confirm with the business.
Step 3: Define the current process.
Proceed to document the process at a task level. Do not waste too much time on the as-is if you are going to change the process. Photos of sticky notes on a wall are sufficient.
Step 4: Improve the process / define new process.
List all the tasks in the current process and eliminate or improve tasks focussing on the outcomes required. If a new process, sticky note the tasks required to achieve the outcomes required with the minimal amount of activities.
Do not just consider "sunny day processes" where everything goes right - consider everything that can go wrong! Look at the paths from every business rule in your process. Consider all process permutations.
Step 5: Link Process Tasks to Procedural Steps.
For each task, create procedural steps - how and why each process step is done rather than what is done. This can be done very simply in a spreadsheet. What is more, you can then split it into a procedural document for your staff to use for training and day-to-day operational procedures.
Step 6: Link Procedural Detail to Business Requirements.
The procedural detail helps to create a granular level of detail that greatly benefits the creation of specific requirements. It forces the analyst to think of all possible permutations and options - it forces them to think in the context of the real world, not a gobbledegook business requirements document.
Step 7: Link Business requirements to test scenarios.
Use procedural detail and business requirements together to develop ,test scenarios and use cases - IT can then use these for their unit testing ,then they can be re-used for user testing. Easy.
Step 8: Build it. Iteratively.
Presuming that there is actually an IT solution involved (and let's face it, there usually is), it is best to adopt an iterative (agile) approach where there are short development cycles with high business involvement. I have seen too many waterfall development disasters in my time.
So ,in eight steps a Business or Process Analyst can create complete traceability from the customer outcomes to the delivery.
It is not really that hard, but isn't it amazing that so many people can make it seem that way?
[eventPDF]
First published on www.theprocessninja.com. Reprinted with permission.