Dealing with the ‘How’ When You are Looking for the ‘What’

Written by Bob McGannon on March 19, 2012. Posted in Articles.

It is the classic problem facing business analysts and other project team members who are collecting project requirements – when asking “what needs to be done?” the responses from stakeholders invariably describe ‘the how’. Many requirements collectors overlook the value of this input, as it can be used as a springboard to more complete, valid project requirements. Here is how you can take this ‘how’ input and extract the most value from it as you create your requirements documentation.

Collect and Separate

Rather than reject the input that describes how to accomplish something, versus getting details on what needs to be accomplished, capture the input as valid and characterize it. As you listen to your stakeholder and record their input, use a flipchart with two columns: one marked ‘What’ and the other marked ‘How’. Recording instances where the stakeholder has shared ‘the how’ allows you to recognize their input as valid, and pursue the requirement further with questions such as “What would you do with this tool if it was available to you today?” Through this questioning, you can ascertain ‘the what’ behind ‘the how’. According to Mindavation staff member and business analysis expert Haydn Thomas, “Sometimes ‘the how’ reflects the essence of the way your stakeholder understands their requirement. Capturing it, and asking further details, not only validates the stakeholder’s need, but it gives you additional understanding as well.”

Utilizing this technique also serves to reframe the thinking of your stakeholders, which can yield additional requirements. As the stakeholders see the project team member sorting the requirements into the ‘what’ and ‘how’ it is likely the stakeholders thinking will mirror this approach. Lastly, when repeated, the ‘what’ and ‘how’ separation technique will help instill better habits amongst stakeholders as they will see the focus on obtaining and understanding the ‘what’, and will display a greater tendency to present requirements with a focus on what they are trying to accomplish.

What is missing?

Projects by definition create change in an organization. From the stakeholder’s viewpoint this change could a) fulfill a gap, b) add capability and/or c) increase their productivity or accuracy with the work they perform. If this is true, then something is missing in the existing processes and systems that could enhance their job. A good requirements gatherer will utilize a sense of curiosity to find out what that missing capability is, and what will be required to provide that capability. In addition, characteristics of the missing capability can be explored with the stakeholder to ensure the requirement is fulfilled in a pragmatic, easily acceptable manner. This can be done while still focusing on the ‘what’ – and separating the ‘how’ – should it surface. In instances where an existing system or process is being altered, stating ‘the how’ can be the best way to understand and capture the requirement into a ‘what’ format. This alteration usually reflects the need of the stakeholder, and describes how a new capability can be incorporated into a current environment without requiring substantial new tools or processes.

What’s Good About It?

Often stakeholders will share ‘the how’ by actually asking for a process or tool with which they are familiar. This is human nature at work; often stakeholders view this as ‘the what’ when they are actually conveying ‘the how’. They do this because they know of no other example or means of conveying their requirement. If a tool is not mentioned by name, ask for specifics so the tool can be investigated. From there, move on to probing questions about what the stakeholder liked about the tool or process, what they didn’t like about it, and how it changed (or enhanced) the way they completed their work. From this, the requirements gatherer can extract ‘the what’ that is needed to complete project requirements documentation.

Take the Deep Dive

The process of requirements gathering starts with a collection of organizational needs. Ultimately however, detailed requirements including functional requirements, process steps, business rules and performance criteria need to be captured and documented. Although many business analysts are not accustomed to ‘flip flopping’ between high level and detailed requirements gathering, this approach can be effective. With stakeholders that have a definitive ‘how’ in mind, a discussion involving detailed requirements is another way of extracting the ‘what’. This approach can also develop an understanding of the way in which the stakeholder prefers (or needs) to work.

Questions that recognize the tool and process the stakeholder is promoting, yet lead to viable detailed requirements gathering include:

When would you use the tool or function?
Are there instances when the tool or process you are using had to be augmented by a manual process? If so, when and what was the manual process?
In a perfect scenario, how would the tool work?
What degree of authority do you have when you use the tool? Could that degree of authority be varied? In what instances would your authority change?
What decisions do you make yourself, what decisions are made by the tool or process, and should the decision making approach vary? If so, how?
What are the exceptions to the process that require approvals or variances to the normal process?

Check the Viability of the Tool or Process

Many inexperienced business analysts either a) accept the ‘how’ as the requirement or b) ignore the information and fail to recognize the value in the ‘how’ input they receive. It is important to keep in mind that, in the mind’s eye of the stakeholder, the ‘tool’ they are proposing is their understanding of a requirement. Proper, balanced and open minded investigation on the part of the analyst is appropriate to understand the stakeholder’s requirement. A great deal can be learned from this investigation, including:

Verifying if there is a tool or similar process that is already available within the organization
Discovering functionality that might be beneficial with other stakeholders or on other projects
Developing a greater understanding of the process(es) the stakeholder is expecting to utilize
Understanding if cross functional relationships between processes or tools exist that might increase organizational efficiency

Care should be taken when investigating these tools or processes however. Common items that should be noted and probably avoided when moving to the solution stage of the project lifecycle are:

Stakeholder enthusiasm due to familiarity with a tool. Other tools might be as good or better and not known to the stakeholder
Influence from marketing. Effective marketing of a product, tool or service can make it appear there are few or no other choices in the marketplace. Careful scrutiny of these stakeholder requests should be applied
Holding on to the current state. Many ‘requirements’ come from an unexpressed desire to minimize change in the stakeholders approach to work. This is not always prudent.

Requirements gathering is a fine art. Successful requirements gathering is best performed by taking full advantage of all the input received from stakeholders. Sorting the ‘how’ from the ‘what’ and investigating appropriately is an important means of validating the expressed requirements, yet staying true to the business analysis objectives.

Don’t forget to leave your comments below.

Bob McGannon is a Founder and Principal of MINDAVATION; a company providing program and project management training and consulting, leadership workshops, keynotes and project coaching worldwide.