I believe that one of the most important success factors in just about any project is having a shared understanding of the “problem” that needs to be solved. Once the problem has been clearly defined, it is much easier to define the scope of the project (and far easier to analyse, define and prioritise requirements).
The trouble is that not all business stakeholders think in this way. Business stakeholders will often focus on the solution first . This is completely understandable – after all the “solution” is something tangible, you can see it and touch it. The “problem” is something abstract and often invisible.
Take this theoretical example:
“We are receiving an increased volume of complaints, and our current complaints system cannot keep up. We need a more efficient complaints case-handling system, which can report on (and enforce) strict Service Level Agreements to ensure we respond to our customers quicker. I have seen that xyz systems incorporated offer an off-the-shelf system. We’re going to initiate a project to implement that system…..”
This statement focuses on the solution (a more efficient claims handling system) rather than the problem (an increase in complaints). In this hypothetical example, a more efficient and effective solution might be to re-train staff, or to re-engineer specific business processes so that there aren’t so many complaints in the first place!
As Business Analysts, we can add a great deal of value in projects by professionally challenging our stakeholders, and working with them to define the problem. Here are some quick tips that might help:
1. Define the problem (or opportunity) at the outset: Work with key stakeholders to formulate a “problem statement”. This needn’t be more than a few paragraphs, but it should clearly and unambiguously define what needs to change. Ideally it should also include a list of key success factors – these will help to measure the success of the project, and can help to guide the high level requirements. If the project is looking to exploit a new market opportunity, then you might want to refer to this as an “opportunity statement”
2. Ask questions: “Why” and “How”: Remember that the problem that is initially presented to you might be the tip of the iceberg. Keep delving; ask lots of open questions. Why, How, What, What if. If you have the time, a workshop can be an effective way of achieving this. Try to incorporate the views of a wide range of stakeholders, not just your sponsor. Remember, operational business users who are “closer to the ground” may be able to uncover essential detail about the problem or opportunity.
3. Check for constraints (real and imaginary): There may well be real constraints that need to be met. For example, if there is a regulatory change that needs to be implemented by 1st January, then this may well impact on the solution and it is worth documenting these constraints at the outset. However, it is worth challenging all constraints – people often state constraints which could be unintentionally misleading. For example: “We need to increase efficiency through automation” when clearly automation isn’t the only way to increase efficiency. Challenging these constraints earlier in the project lifecycle is likely to make your job as a BA easier!
4. Reign people in: Use the rapport you have with your stakeholders to “reign them in” when necessary. For example : “That’s a totally valid point, but I think we’ve stepped into the solution domain here… can you remind me of the business problem that we need to solve?”.
Challenging stakeholders in this way gets easier over time, particularly as your organisation learns the true value that robust Business Analysis brings. It’s a great way to get people thinking, and to ensure that your project has the best possible chance of delivering the required benefits for your stakeholders and clients!
Do you have any top tips for keeping people’s focus on the problem, rather than the solution? I’d love to hear from you, so feel free to reply to this blog post!