Kick-Start Requirements Discussions With These Four Questions
“What should I ask to get good requirements?” a developer inquired, continuing, “I don’t have a business analyst, so I have to do my own requirements gathering, and I don’t know where to start.”
Whether you are a business analyst or not, the key is to ask thought-provoking questions, especially while the project team is in a ‘discovery’ frame of mind early in the project. Business analysts often say, “Requirements gathering is just order-taking.” Requirements elicitation, the preferred term, introduces strategic thinking by asking whether this effort solves the right problem at the right time, in the right way, and whether the effort spent will be profitable. Good requirements elicitation almost always requires several conversations. Four questions in particular open the door to much richer requirements elicitation discussions with stakeholders.
1. What problem or opportunity are we solving for?
This is the opening volley in understanding why the project exists. Stakeholders regularly jump straight to their solution. The request may come to you as, “We need a report,” or “We want a new ___ on the website.” One approach is to treat a request as if you have never heard of the product, the company, or the industry, even if you are very familiar with it. Asking business partners to explain the situation as if you were new to the company could reveal details about the problem or opportunity from a fresh angle. Gently probe with “why” and “what” questions to explore what the stakeholder expects.
2. What is the definition of done?
Ask stakeholders for acceptance criteria. What must the solution do? What results must it produce? What must be true to release the project into production? By asking stakeholders to clarify what “ready” means to them, you establish guard rails to help define scope before the work begins. Later, if the stakeholders add to their original list of requirements, you also have the basis for managing scope creep, which may inflate the cost of the project, lower the return on investment (ROI), or keep the project from releasing on time.
3. How will you know it succeeded?
This question prompts stakeholders to consider key performance indicators (KPIs), measures that support the organization’s overall strategic goals. ROI is only one such KPI. Tactical-level stakeholders may not know how to develop or test success metrics. They only know a “thing” feels necessary, or they must meet a certain goal. Elevating the entire team’s awareness of the relative cost of effort as compared to the expected lift in sales, profit, or reduction in cost may reveal that the current project isn’t the right one to support the organization’s business goals.
4. Have we identified the right stakeholders?
Stakeholder A from the business analytics team asked for the report, but should you consult the database team as well because it uses their data? How will the consumers of that report use it? Even if one stakeholder emerges as the decision maker, consider all those who interact with the problem or opportunity before reaching final decisions about a solution approach or design.
Whether or not you hold the title of business analyst, you can still ask these important questions when faced with a new assignment or project. They prompt the entire team to consider the “who,” “what,” and “why” of a project in a way that opens the door for even more thoughtful questions and answers.
