Occasionally I’m asked, “Are formal sign-offs necessary?”
My take on this is, “Are you kidding me?” Do you want a receipt or some documentation when you pay your taxes, mortgage, or rent? Should you have a will that directs what happens with your kids and money if something happens to you? Ok, lots of people don’t have a will in place, but at least we all know we should.
And when we are working on, say, a $1.5 million project, should we not be documenting the formal acceptances of the work we do along the way toward full completion of that project engagement? It’s how we know for sure that tasks and deliverables are complete. It’s how we know for sure that the customer – who pays for these deliverables – accepts that they are complete and that formal acceptance, then, is how we are justifying invoicing the client for the completed work and how we know that we should expect to be paid for that work.
See how you can manage your projects and get the sign-off from your project sponsors.
What to get formal project sign off for:
For me, it’s critical to get formal sign off on four items or categories of project efforts:
- All project deliverables. This includes all up front planning documents and any key deliverables throughout the remainder of the project. These are usually documented in the project statement of work (SOW)document and indicated in the project schedule in the early planning phases and then throughout the project schedule as other key milestones and deliverables.
- Change orders. Getting a formal sign off on each project change order is extremely important. It documents the customer’s acceptance of the estimate and their agreement to pay for the work that your delivery team is about to perform that has been deemed outside of the original project scope or requirements.
- User acceptance testing. A formal sign off after UAT shows that the customer agrees that they have thoroughly tested the solution and that they agree that it is bug-free and ready for deployment. Without this formal sign off, any issues at the time of deployment could be in dispute setting the delivery team up for requested fixes and changes at rollout that they have no documentation to defend against.
- Solution acceptance. Finally, a formal sign off at the time of solution deployment says that ‘everything’ is done and that the customer agrees with this. It may require a sit-down review of the project schedule vs. the project statement of work (SOW) to verify that everyone agrees that all proposed deliverables were, indeed, completed. But your formal sign-offs on each of those deliverables – as mentioned above – will help with this process.
The real reason for project sign off
This all brings us to the reasons for final, formal sign-offs that we’ve been discussing. First and foremost, it shows completion of the work on the project. Having formal sign off says you think you’re done and the customer also thinks you’re done. And even more importantly, the customer is satisfied with each deliverable and item they’ve signed off on to the point that they accept the work performed. That’s critical.
Additionally, a formal sign off on every necessary item is good from a legal standpoint. It may never be necessary, but if there is even one project during your career where there is a dispute about the work performed, having a formal sign off from the customer on any work in question will be of considerable help in any subsequent legal proceedings or arbitration meetings. Trust me; you’ll want to have those sign-offs documented in a project folder for safe keeping…just in case.
How formal you go on many project details often depends, of course, on several factors. How complex the project, how large the project budget, the preferences of the project client, etc. However, it will always be a good idea to ask for and obtain formal sign-offs from the customer for the work that you and your team deliver to them. In the end, it may not be necessary to have, and it may be something you’ll never have to go back to or refer to, but having it means it’s always there if the need arises. It’s good project management best practices, and it’s just good business.