Often human minds are geared towards solving a problem, this task uses creativity, logic and it’s a fun thing to do. As a Business Analysis professional, we see this all the time, which can be sometimes challenging when we are trying to elicit stakeholder requirements.
Sometimes there are other practical reasons why the stakeholders and the project team members might get into the solution mode before requirements definition. Examples of such are Cost (eliciting requirements takes time), Experience / Confidence (we know exactly what we want), Unclear or Disguised Agenda (solving the problem which is not part of the project scope but making it look like it’s the best fit for the project).
Whatever the reasons may be, one of the key aspects of the Business Analysis task is to get the breadth and the depth of the requirements based on the project stage. When we begin to talk about solution before the requirements we may not be utilizing full potential of the project resources including creativity, out-of-box thinking, expertise and experience that the team brings with them. Focusing on the solution before requirements definition comes with a risk, where the end product may not really address the problem or may just solve a portion of the problem.
Here are five indicators that we are in solution mode before requirements definition.
1) We need a new user interface that looks exactly like the user interface ‘A’ with different parameters.
Here the stakeholder is convinced that adding a new user interface similar to the existing one is what they want. Stakeholders have been very impressed with the existing interface and feel that having such an interface for other problem areas is the solution. The issue here is that the detailed implementation requirement is mentioned without clearly stating the business problem that needs to be solved.
2) It’s very simple, just add the new parameter into the existing calculation and it should work.
Here the stakeholder is convinced that adding the new parameter into the existing calculation should work. Are we changing the scope of the existing calculations? Has the business definition changed for what the calculation stands for? There might be downstream impacts of changing the existing calculation to represent something different. Again, without knowing the WHY it is difficult to say that adding an existing element will solve the problem (we don’t have the problem definition yet)
3) Just add these attributes to the user interface.
What are these new attributes, and what do they do? Do we have them in our organization domain or is it brand new concept to our organization? Is it captured elsewhere today? If yes how are we going to manage the updates? What would be the system of record for these new attributes? So many questions, and again the business problem is not identified.
4) We need to implement ‘Solution A’ because that is what other similar industries are using.
We need to understand the problem we are trying to solve by implementing ‘Solution A’. It may be a standard or a practice similar organization may follow, but to compare we need to understand company culture, business relationships, team size, team hierarchy/structure, environment, etc., (tangibles and non-tangibles). Collecting such information objectively is harder than defining the actual business problem; because once we have the definition, we can get the solution that is best suited for our organization.
5) Buzz words – By using buzz word “zzz” all of our problems will be solved; we would not be in this mess.
Need to understand the concept that is relayed by the buzz word “zzz”; although we feel amazed by this new concept in the industry, we have to go through the scrutiny of understanding what problems can be addressed by this new concept. Again, it starts with a clear definition of the problem statement we are trying to address. Sometimes things may not be broken, but we may want to upgrade to new technology. Even if we decide to upgrade our existing unbroken system, we still need the rationale, the problem statement.
One of the ways to bring the project team members back to requirements is to clearly define the one or two key business problems/issues we are trying to solve as part of the project. Note that the real problem definition will not be in IT terms, it will be in business terms to explain why they need something. Sometimes it is crucial to drill down to 4 or 5 why's to get to the root of the problem statement; note that understanding the rationale why something is needed is a very important in order to frame an accurate problem statement. This is the hardest part. Once this is defined, we need to declare the scope and then the train will be on the right tracks. If the business problem and requirements are defined clearly, with some degree of accuracy, the solution will fall in place.
1 BABOK v3, A guide to Business Analysis Body of Knowledge, IIBA