So you’ve had your discovery sessions with the customer and your requirement document is now submitted for review. All you need to do is get the customer to sign off and you’re ready to start coding. Sounds simple doesn’t it? It’s not. Getting requirements signoff can prove to be a very challenging activity and is a great test of the customer relationship. This post will tell you three invaluable tips that you and your project team can use to help steer your document towards the signoff milestone.
Over-communicate, Silence is deafening
Never assume that if you’re not hearing from the customer during their review of the document that things are going well (ex. “no news is good news”). If you haven’t heard from the customer it likely means they haven’t reviewed the document. Constant touchpoints are a great way to keep the customer accountable (yes, this is work for them that they need to do). Make sure that the customer understands that there is a deadline for them to review and provide feedback on your document and failure to meet that deadline can result in schedule delays. Gentle persistence with some tact is a great way to keep pushing on the customer to do their internal reviews. Once the customer has done their reviews of the document, doing an online review together with them is a great way to quickly flush out any gaps or discrepancies – do not have ‘conversations’ within the document – always interact with your customer as much as you can to gain clarity. Keep the lines of communication open as much as possible during this phase of your project.
Be Clear, Be Concise
Requirements documents often help form the true scope of your project so it’s crucial that they be very clear and easy to understand by all readers, both technical and non-technical. There’s a good chance that the person who is accountable to sign off on the document will not have a strong technical background. Requirements should state very clearly what the problem is, and what the solution will do to solve the problem – that’s it. There should be very little (optimally none) of the ‘how’ in a requirements document – if there is, that could lead down a path of designing the solution before defining what the solution should be. Fall in love with the problem, not the solution.
Match Scope to Contract
A lot of times your requirements document is referenced in your contract as the true definition of the project scope. Due care and attention should be given to matching your requirements back to the original contract to allow the customer to see that the scope defined in the contract is accounted for in the requirements, or conversely, showing the customer the new/changed scope in the requirements document. This allows the customer to see the full transparency and helps put minds at ease when signing off on a requirements document that essentially forms the scope of your project.
Getting requirements signoff is typically not an easy thing to do. It requires trust but also requires a lot of guidance and persistence from you and your team. Following these three tips alone won’t get you there but heeding this advice will certainly get you a few steps closer.