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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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…)
  7. Also within the context of the Structured Walkthrough, it helps to set ground rules for the review session. Richard Larson and Elizabeth Larson provide the few simple concepts below in their CBAP Certification Study Guide v2.0, but I also like the Golden Rule of “Treat others as one would like others to treat themselves.”
    • “Leave titles at the door.”
    • “Disagree with ideas and not people.”
    • “Come prepared.”
  8. Acknowledge that perfection is not what you are seeking. Business analysts don’t walk on water! Plus, there are many reasons why perfection is both an unreasonable and unrealistic expectation when developing a software solution. Sometimes simply acknowledging this in the beginning can help set proper expectations and short circuit the “perfectionist” in all of us.
  9. If you aren’t seeking perfection, then what are you seeking? On this point, the IIBA provides the following evaluation criteria that can help form the basis for your review:
    • 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?
  10. Be available for offline questions or commentary. For a variety of reasons, individuals may be uncomfortable reviewing requirements in front of their peers or management. Allowing them the opportunity to contact you one-on-one may help them effectively review without threat of reprisal or fear of embarrassment.
  11. Acknowledge all feedback and publish it in a centrally accessible location for stakeholders to review as needed. It is helpful to capture the feedback in an independent change log so that it is not lost when reviewing the subsequently updated deliverable. This will allow even the most suspicious stakeholder to easily validate that their input was received and to tell what action was taken.

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.