Archive for September, 2010

Goal oriented business analysis

September 28, 2010

Idea: Goal oriented business analysis focuses on trying to understand stakeholder’s goals rather than their requirements. Often requirements are ‘solutions in disguise’.

Trying to elicit stakeholder requirements is a common stumbling block in business analysis. Often stakeholders will discuss their favoured ‘solution’, suggesting how they would like a problem solved rather than explaining what the problem is.

Starting with a solution is bad for a whole host of reasons, not least because it closes down the design process before it has even begun. Taking a suggested solution (rather than a stated problem) to a designer or software developer severely limits the opportunity for them to explore the problem and propose creative solutions. This often results is sub-optimal, or worse unnecessary, system functionality being developed.

To avoid this problem and to fully exploit the creative resources of the problem solving team (including designers and developers), business analysts need to elicit problems rather that suggested solutions from project stakeholders.

Focus on the stakeholder’s goals rather than their requirements. Rather than asking stakeholders what they need, or what they would like to see developed (what their requirements are), ask ‘what do you want to achieve here?’. Get stakeholders to describe their vision of the situation under analysis after the problem is fixed rather (a goal) instead of how they see the problem being fixed (a solution).

Advertisements