A good analyst understands the importance of asking insightful, probing, and sometimes difficult questions. He/she helps ensure that implementation decisions are made at the right time, and with sufficient information in hand.
Occasionally, an analyst will encounter a stakeholder who wants to prescribe the detailed solution on day one. What then?
Below are a couple techniques that have served me well over the years.
Restate the request in the form of a capability
When a stakeholder asks, for example, for a specific software module to be added on to the existing system and for several other interesting services, fields, widgets and shiny objects, restating the ask in the form of a capability can be an effective way to bring the conversation back to the desired level for requirements. For example, I might ask:
“If I understood you correctly, customers need to be able to pan and zoom the high-resolution images accompanying product listings so they can see potential product imperfections. Is that right?”
Certifying the need by restating implementation detail as a higher-level capability is a great way to get the discussion back to the appropriate level. Through gentle reminders and consistent use of this technique over time, I’ve found that I’ve been able to coax/train some stakeholders into providing needs and capabilities instead of implementation details.
You might notice the subtle use of the common user story construct “As a [actor/stakeholder] , I need to be able to [capability] so that [objective/goal] . ” in the restatement. This helps the analyst not only to understand the capability, but also the actor and the reason the capability is important.
Find out why
Now, this is a little different from a BA’s beloved “Five Whys” technique to get to the root cause of a problem. In this case, we are trying to learn why a stakeholder seems drawn to a particular implementation. In this case, I might ask:
“Ms. Stakeholder, you seem to have an affinity for this particular way of solving the problem. Generally, we try to stick to higher level requirements – needs and required capabilities – at this stage, but I sense you have reasons why you feel we need to follow this particular path. Could you describe those to me?”
Often, this type of questioning reveals other requirements, constraints, or, at minimum, will uncover concerns the stakeholder has which may be important to understand and document, even if not as requirements.
I like these techniques because they validate the stakeholders’ well-intended and valuable contributions, while gently redirecting the conversation to a level of detail appropriate to requirements discovery. Instead of using negative language, (“No, that’s not what I’m looking for..”) the analyst is able to affirm and frame the subsequent dialog in a positive way.
“Occasionally, an analyst will encounter a stakeholder who wants to prescribe the detailed solution on day one.”
Hah! The only issue I have with your statement is the “occasionally” part, Jonathan :-). Over the years I’ve been asked to help bring multiple projects in trouble back on track, and in all cases, a big part of the problem was what you describe (stakeholders jumping into solution mode and prescribing the detailed solution to the problem before its fully understood). The problem is compounded by weak business analysts who don’t think of questioning the approach taken by the business stakeholders.
I believe this problem is prevalent in many companies, especially when there’s a “wall” between business and IT (which makes stakeholders suspect that, unless they provide a very detailed specification, they won’t get what they need). This makes the recommendation you offer extremely valuable, in particular for new BAs, who may find it difficult to push back when a stakeholder brings a detailed design to the table. Without taking a step back to look at the big picture, and the need behind the request, it’s almost impossible to ensure you are building the right solution. Following your advice is critical for any BA who wants to add value to their projects.
Thanks for the comment, Adriana. Yes, “occasionally” was probably putting it mildly! It’s funny, though, I find that when I’m not in “work” mode, I can be the same way about solving tricky probablems re: home and family, personal finance, etc. I want to jump straight into solution mode and fix it now, often without stepping back and seeing the big picture and thinking things through as you mentioned.
Of course, at home I have my wife as my trusted adviser and counterbalance to make sure I am thinking things through so I feel safe going ahead because I know she’ll draw me back and keep me grounded. In a similar way, analysts have the opportunity to advise stakeholders, providing that sense of safety and counterbalance to the impulse to jump ahead to conclusions without sufficient thought.