Search This Blog


6 January 2007

Is process design integral to capturing workable business requirements?

My friend Patrick Castauro has written an article for the BA handbook on Requirements Management and Process Analysis. I reproduce it here.

You can read more about BA techniques and processes here.


In my experience, there seems to be very little emphasis on process design as a precursor to capturing business requirements. How is possible to know what you need, when you have little or no understanding of its application (what you need it for)?

Many BAs are able to, through prior exposure or experience, guide the requirements gathering process with or without the support of relevant business subject matter experts, and capture requirements relevant to the scope or intended objective of the initiative.

In most cases, it is because the BA understands how the business operates, that this activity, in the absence of process understanding, delivers what is required.

What happens when the BA is new to the organisation, doesn’t have any operational exposure, or business (stakeholders/users) are unable to offer subject matter experts?

In the absence of well managed and facilitated leading process work, it's not possible, in my view, for the BA to produce adequate requirements relevant to the intended scope of the initiative. Furthermore, in the leading stages of a project the focus from the business is somewhat limited - remember very few initiatives proceed to implementation. It's when the initiative receives the green light, and in many cases this is towards the middle of the development lifecycle, that the business decides to take attention.

When this occurs, the business will be seeking validation that the requirements provided thus far will meet their needs, and how is this achieved?

By defining, through process mapping, how the business intend on operating the solution. Better late than never but, ultimately this late validation will see the need to remove or add additional requirements. This may not be too much of an obstacle, assuming the project can absorb any development delays and cost blowouts but should it not be able to manage this change we end up with a solution riddled with gaps. And, how many of those have we seen!

Whether it be capturing high level requirements or detailed requirements, in all cases, these activities should be lead by process design (remember to have your scope confirmed and agreed to before process mapping.)

Many will argue, "But we have no solution to know how to manage the process." Yes, this may be true, but do not discount the value of understanding some of the key process activities for which the solution is required.

You may not have the detail to fill the gaps, but an experienced analyst will (be it a business analyst with process mapping experience, or a pure process analyst working with a business analyst) be able to guide the mapping to identify key lifecycle functions, key process activities to be undertaken across the lifecycle functions (the inputs and expected outputs) and procedures that may be required to manage the processes, across all workgroups and IT applications (be it known or unknown).

The activity itself will assist stakeholders in defining impacts and deriving requirements. Process mapping and requirement gathering are intrinsically linked. Ultimately, the requirement is there to manage a process of some sort – why do we forget this?

Patrick manages a project office at Optus in Australia.