“Bring me solutions, not problems”. How often have we heard those words uttered by management? In the main it’s a sensible ask however, for a Business Analyst, quite the opposite is true. Our job is to define business problems when often we are presented with solutions.
“We need a new reporting tool because the MI we receive isn’t always correct”.
We could initiate a project on this basis; gather detailed requirements, develop a new reporting tool and roll it out across the organisation but would this address the issue and if it did, would it really be the most effective way to do so?
Could it be that there is a problem with the data entry or with the way the MI is being interpreted?
The above problem statement is merely a symptom of a problem and does a poor job at describing what the real problem is.
Would a Doctor simply prescribe pain killers to a patient who complains about headaches or would he probe further, try to identify the reason for the headaches and offer treatment accordingly? So too must the Business Analyst probe deeper and recommend appropriate options.
The above illustrates why we cannot always rely on stakeholders to provide an accurate problem definition alone. There are other reasons too. For example, different stakeholders will have different (and sometimes conflicting) perspectives on the problem and for that reason, it is essential that the right people are engaged and the right information is elicited.
CFO - “We need a new reporting tool because the MI we receive isn’t always correct”
MI & Reporting Manager - “I need more resource because the demand for MI exceeds our current capacity”
Senior MI Analyst (Team Lead) - “There is too much re-work” “Team morale is very low”
MI Analyst - “The reporting suite is to complex. The MI that I provide is always correct but I’m often asked to redo work with slightly different parameters”
Night Watchman - “I’ve no idea. All I know is that boy seems to work awfully late!”
So maybe you might not interview the Night Watchman – but useful information does often come from surprising places!
In order to develop a true problem definition we must explore and challenge all of the problem statements that we have captured. In reality, there will be many and we must analyse each in turn to develop a short list of problem candidates.
There are many ways to explore the problem statements some common techniques are:
- 5 Whys
- Root Cause Analysis
- CATWOE
An explanation and templates for these techniques are readily available online.
Once we have our problem candidates, we should assess each of them in turn to determine whether they are in scope, relevant, a true problem or feasible. This should then lead to a clearly defined problem definition or in some instances a number of defined problems. When a number of valid problems are identified, the Project Team and Sponsor should decide which one to address.
So, the final step will be to get the problem owner to confirm and accept the problem definition but remember, never, ever go to management with a problem! Not without an appropriate solution anyway!
- See more at: http://www.peterjefferies.co.uk