At first glance, gathering requirements for any project may seem like a straightforward task, but in reality, these sessions can be daunting and typically devolve into a discussion of solutions (the “how”) rather than discussing the business problem at hand(the “what”). In general, businesses tend to race to find a solution and expect their solution to act as the deliverable they are seeking.
This type of behavior may stem from feeling pressure from upper management, who typically wants to see progress and value added. In that context, spending time defining a problem for an already “known” solution may not seem like the best use of company dollars. But in my experience, delivering the solution presented by the stakeholders may only address part of the problem and usually tends to be a band-aid for the problem itself.
Form Follows Function
Let’s look at a non-technical yet complex project most of us can relate to: residential architecture. A family who is considering building a home meets with an architect. When asked what it is that they would like, the family describes their ideal home: 4 bedrooms, 4 baths, open floor plan, 3-door attached garage and a backyard to play in. If the architect could phrase questions so the family could talk through their challenges, the outcome of this conversation would do more to identify problems to be solved; the kids have outgrown sharing a room and need some privacy, the family tends to have a lot of guests so the common area needs to accommodate groups, maybe someone works out of the house so they need a quiet area where they won’t be disturbed when others are around, or even, because of inclement weather, we’d prefer to go from our car directly into the house without having to walk outdoors. At this point, the architect has enough information to present the client with a possible solution, addressing their needs rather than their wants.
Ask the Right Questions
Asking “what” questions during requirements-gathering can keep businesses focused on identifying their business problem. It would be unrealistic to expect this conversation not to drift back into talking about the “how” but an experienced Business Analyst could steer this conversation back on track. Some useful “what” questions are:
- What business problem is your organization facing?
- What workflows already exist in your organization?
- What does success look like?
- What type of communication is expected?
- What functional limitations does the system/website have?
- What would happen if the way things are done today doesn’t change?
- What changes are happening in the organization that may impact the success of this project?
- What type of users will have access to the system/website?
- What are the problems that your organization is facing without a system/website?
- What type of reporting is essential for success?
Once the “what” requirements are approved, the solutions team takes over. The “what” requirements serve the solutions team with guard rails on what must be true while they develop solutions for “how” users interact with the system/website.
Focus on the “What”, not the “How”
In the end, businesses can save themselves time and money by working through and identifying the “what” of their business problems rather than only addressing the “how” and placing a band-aid on their problem. By working through the “what”, businesses can identify the root cause of their problem and may expose other closely related problems that need to be addressed.
