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.