Requirement sign off is one of the key milestone on the Software Development Life Cycle and often considered as a dreaded milestone by the approvers or the signing authority.
Before we move on see why this is considered that way, and how do we approach this, let’s understand, why an approval is required on the requirement package.
Why sign-off is required?
When a requirement is presented for the sign-off, the requirement is basically the business analyst’s understanding of the scope, business requirements etc. Obtaining a sign-off ensures that the stakeholders goes through the understanding that the Business analyst have and fill up the gaps if any; that way, ensures that the solution requirements are captured and will be delivered in the right direction (this is the first step towards building the right product). This also helps in resolving any conflict that may arise in future where the stakeholder may change their mind on the requirement and the construction has already begun.
Why this is considered a dreaded milestone?
Once the solution is developed and presented to the business users for the validation, there would be instances where the solution differs from the business expectation on certain aspects. Now, trying to find out what/where this went wrong, one of the probable reason is where the solution is in line with the requirement specs, however, during the review and approval phase, the stakeholder either overlooked this or interpreted the requirement in a different way. That’s exactly where, there is a fear to be blamed among the stakeholders by the management. And they want to avoid this process.
- A single document with all the requirements, which are owned by different stakeholders or group of stakeholders. So, an individual will be very much reluctant to approve the document, which they don’t own individually or in it’s entirety.
- Time constraint to review the document.
- Lack of confidence or the right set of knowledge from the stakeholders.
- Fear of blame by management for something goes wrong in future
How do we approach these challenges
Extend RACI Matrix to RASCI, with ‘S’ for Sign off. Identify the right set of people at the beginning itself and formally agree with them to provide the sign off on the deliverable.
Help the stakeholders to understand the review and sign-off process. Also, communicate the process of managing any subsequent changes post the sign-off.
Help the stakeholders to interpret the requirement and for them to co-relate with the business scope and expectations easily. As required, provide them with the Glossary or the Data dictionaries. Share the communications (email exchanges) related to the decisions taken previously as part of the requirement package.
Plan properly and provide a heads up to the stakeholders ahead of the milestone, that the requirement is on the way for their review and approval. Also, provide enough time once the requirement is shared, for them to review. Note, this may not be the only task at hand and there could be other deliverable where the stakeholders would be working upon.
Conduct join review session to walk-through the requirement package, it’s structure on how to read this out and the content as well, to avoid any issues with the interpretation.
Foster relationship and build trust with the stakeholders. I believe, this is one of the key ingredient to get the sign-off. That way, a reminder may not treated as an escalation. In fact, one of the best way to remind is to approach at his desk for an informal talk.
Hope this will help. There could be other ways too; would love to hear from you. Please drop in your thoughts and approaches on the comment section. Thank you.