"Go out to the business and gather their requirements!"
How many times do we hear this said?
When I hear this being it immediately fills me with dread; 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 in these situations is that business analysts go away and do just that - gather requirements - what the business thinks they want. Typically what this results in is a giant rambling document written in a pseudo business / IT speak that the business say they can't read and the IT guys say isn't 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's not what we wanted!" they say!
"But that's what you told us!" say the BA's and IT guys!
It doesn't have to be this hard. Here's how you do it:
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?
2. Define the process scope
Establish what the process actually is from the customer's perspective - current state (if a current state exists!). Don't 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. Tick in box from business?
3. Define the current process
Proceed to document the process at a task level. Don't waste too much time on the as-is if you are going to change the process!Photos of sticky notes on a wall is sufficient. Tick in box from business?
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. Don't 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!
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 ( For example my Process Ninja Workbook that utilises the CEM Method). What's more, you can then spit it into a procedural document for your staff to use for training and day-to-day operational procedures.
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.
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.
8. Build it. Iteratively.
Presuming that there is actually an IT solution involved (and let's face it, there usually is), it's best to
adopt an iterative (agile) approachwhere there are short development cycles with high business involvement. I have seen
too many waterfall development disastersin my time.
So in eight steps a Business or Process Analyst can create complete traceability from the customer outcomes to the delivery.
It's not really that hard, but isn't it amazing that so many people can make it seem that way?
Cheers,
TPN
