Commitment can be a scary thing. Just ask anyone who is moving jobs, getting married or buying a house. The same is true for stakeholders when they sign off on a requirements deliverable. You are asking them to take ownership for verifying that the requirements elicitation and analysis effort is concluded and that the written outcome is acceptable. Even for small projects with relatively limited deliverables it can be an anxiety provoking experience, particularly for those new to the software development processes.
So, how do you manage a stakeholder that is anxious about the requirements verification process? Try a few of the simple ideas below:
- Educate them. Don’t assume that everyone knows the process. Sometimes even the basics are not clearly or consistently understood, such as: frequency and timing for reviews, participation requirements and feedback delivery method.
- Empower them. Emphasize that this is their opportunity to be the “Voice of the Customer” and to provide valuable input into the project from the perspective of the business. Note that you are not asking them to be development experts, but rather specialists in their own domain.
- Ensure that you have the appropriate audience for the review when compared to the subject being reviewed. An executive stakeholder is the perfect audience for reviewing the project’s strategic business objectives but would likely not have the knowledge (let alone interest) to review the functional requirements for an operational report.
- Work with the business and the project manager to define a reasonable period for review and feedback. Shoving a date down their throats never works, but neither does having an open ended arrangement.
- Provide the deliverable in advance of the review session. Keep in mind that the amount of time needed is dependent upon the density and complexity of the deliverable. A process flow may only need 1 – 2 days advance publication, whereas a 50 page Vision Scope Document may take up to a week.
- If using the Structured Walkthrough technique, follow the POI BARS mnemonic from the International Institute of Business Analysis (IIBA), A Guide to the Business Analysis Body of Knowledgeâ (BABKOKâ Guide) to help guide the meeting. NOTE: These are not necessarily in the order in which you would execute them.
- P – Review the purpose of the deliverable being reviewed
- O – Clarify the objective of the review
- I – Introduce the various participants and outline their roles during the review process
- B – Provide background on the project (if needed) to help set the context for new participants
- A – Summarize the agreed upon actions from the review (ex: list of edits to be made to requirements)
- R – Review the deliverable with the group
- S – Clarify the status of the deliverable (ex: initial review, final draft, etc…)
- “Leave titles at the door.”
- “Disagree with ideas and not people.”
- “Come prepared.”
- Cohesive – Does a given group of requirements relate to a single thing and support the overall purpose and scope?
- Complete – Are all needed aspects of the system documented? Is each requirement self-contained without any missing information?
- Consistent – Do the requirements use the same wording style? Do any contradict each other? Are they all defined at the same level of detail?
- Correct – Does the requirement express the actual need as assessed by the subject matter expert or user?
- Feasible – Is the requirement realistic to implement within technical and business constraints?
- Unambiguous – Is the requirement easily understood by all and not open to interpretation?
- Testable – Can the requirement be tested in the Quality Assurance effort such that it can proved as fulfilled?
Hopefully with these techniques as a guideline, your stakeholders will become more comfortable in their role and be able to provide their John Hancock when the time is right.