Business Analysts are often thrown into projects to help gather requirements around a known, defined problem. Other times we’re asked to analyze the current state of a certain process, organization, system and look for ways to improve areas that are clearly lacking. I’ve noticed that when we are brought on a project, the problems described are likely only surface symptoms to large issues. For example:
· This system can’t handle more than X transactions per hour and it’s killing our procurement process’ performance
· This organizational unit doesn’t have the right staff to be able to keep up with the demands being placed on them
· This process is obsolete and overlaps with three of our other processes
While it’s great to have a problem identified, it is well worth the effort to ensure that you are analyzing a root cause problem and not only a symptom of a greater issue. If you don’t do this step, you may end up using lots of resources at what amounts to a band-aid solution.
A great technique to help delve into a problem and identify possible root causes is the ‘Five Whys’. When an issue is presented you ask the question ‘why did that issue occur?’ Once you have your answer, ask the question ‘and why is that so?’ Continue until you have asked ‘why?’ at least five times, even if you felt you’ve reached the root cause after 2 or 3 responses.
Joel Spolsky details a good example of how using the Five Whys can elicit solutions to underlying problems. Recently I came across a similar example with a client (certain details have been changed).
Issue: Employees did not receive their pay stubs on pay day.
· Why? Because the printing system failed the day before pay day.
· Why? Because the system could not recover from a hardware fault.
· Why? Because the system uses outdated hardware that has no automatic redundant backup.
· Why? Because the system hasn’t been replaced as it hasn’t been identified as a high enough priority to allocate budget to its replacement in the current economic climate.
· Why? Because the organization does not have an enterprise planning methodology that weighs the risks of current operational systems failing versus the criticality of these systems and the impact of such a failure.
Some people may have been tempted to stop after the third or fourth question. We could have rushed to find a way to set up either an automatic failover system or to increase the availability of resources to replace legacy hardware in the event of a failure. Or we could have determined that the system needs to be replaced and develop a business case to do so. But the overall challenge that faces the organization is a way to assess the relative risks of failure for all enterprise applications and come up with mitigation strategies in light of the available funds to maintain and replace systems going forward and to holistically evaluate the replacement of such systems over time.
It may still be a good idea to address the symptoms found during this activity. In the end the root cause(s) that you identify may be deemed to be outside of the domain of you and/or your project team’s responsibility. The key is to recognize that there are potentially larger issues that may need to be addressed; otherwise this issue may resurface with different symptoms in the future and to pass along this information to those who can act on it.
The Five Whys isn’t the only tool you may want to use to help identify potential root causes (here are some suggestions on how to improve its efficacy at finding root causes), but I believe that it can be used to quickly assess whether a problem that has already been defined may in fact be a symptom of greater hidden issues.
Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com