Make Sure Done Means Done

You’ve come to the end of a long technical project, and you’re rolling out the solution to the customer and their end users.  Perhaps it’s a handoff; perhaps it’s a training session or some sort of demo dog and pony show.  

But you’re looking for final signoff so that you can proceed with final billing and closure as you switch from delivery to support of the engagement.  The last thing you want to do is find out four months from now that you have an open invoice because you failed to finalize a particular project deliverable by not obtaining an approved signoff.  For the project manager and business analyst – who often leads the actual development of documents and preparation for things like user acceptance testing (UAT) standpoint – that can be a bit embarrassing.

Anything left unfinished can give the appearance that you are anything but in complete control of your project.  That’s bad because any items not complete may give the customer cause to be concerned about thoroughness in other areas of the project.  You want this client to be confident that you and your team have done your jobs.  You have tested and delivered the solution the client is expecting, and that everything will work when you wave good-bye and flip on the switch.  In short, you also want full final payment.  I know, I’ve been on one of those issue-filled projects when the client was concerned to call it done because so many issues had come up near the end that they were certain there would be more.  Gaining final acceptance and payment was excruciatingly painful.

Related Article: Getting the Project Client to Focus on Requirements

To ensure the project is done, here is my list of four key areas to cover and actions to take as the project is closing down.

1. Review all invoices for payment in full.  The Project Manager likely will need to lead this task – with the help of the Business Analyst.  Review all invoices with accounting and ensure that all that were sent to the project customer have been paid in full.  If any invoice is left unpaid, check with the customer to see if there was any reason for this.  Was there a problem with the deliverable?  Was it just an oversight?  I had this happen on one project and there were no issues. The project sponsor had just failed to pass an invoice along to his accounting department for payment, and once I contacted him, they promptly paid.  On very large projects, this is not all that uncommon to have happen.

2. Review the project schedule to ensure all deliverables show complete.  The Project Manager and Business Analyst should carefully review the project schedule to ensure that all tasks have been properly updated and show as completed in full.  Review any question marks with the resource or resources assigned to those tasks.  The key here is that you want to be sure you can hand over a revised project schedule to the project customer that accurately depicts all tasks as 100% complete and signed off.

3. Contact the client to see if they have any concerns about remaining outstanding issues.  The Project Manager and Business Analyst need to conduct a meeting with the client to discuss the project at a high level and find out if the client has any concerns over any outstanding issues or uncompleted work.  This meeting is not the same as a lessons learned session – the purpose of this meeting is just to ensure agreement on the completeness and verbal acceptance of the final solution.  While verbal acceptance is good and something you want as you’re working on this final check of project done-ness, never overlook that formal final signoff and acceptance by the customer.  It could end up being the most critical document on the entire project!

4. Review acceptance test documents.  One huge sign of final acceptance is final customer signoff and approval of user acceptance testing.  The customer handles test cases and test scenarios.  The Business Analyst and other tech staff on the project can help them, as needed.  But the Business Analyst can’t do it for them.  If the BA did, it could cause a conflict of interest because the delivery organization – as the developers of the solution – may have be biased when it comes testing.  The real testers needed are the future end users of the solution.  When their testing is complete we’ll know the project is ready to be accepted and signed off (as long as there isn’t a gap between the documented requirements (approved and signed off by the client) and what the end users need).  If there is a gap, then you’ll be drawing up a very large change order.  The project customer needed to have ensured that their end users were on board with acceptance of the documented requirements and project scope way back at the beginning of the engagement.  Any work on that now will be expensive.

Summary / call for input

There’s never a guarantee that you’ve covered everything.  I once closed out a year-long agreement with a client and then realized that I had agreed to a two-part billing on a deliverable to give them additional time to pay.  Instead, I completely forgot to bill part 2 and collect it – remembering it only when I was ready to invoice new work at the end of that first engagement.  The client knew they owed it. However, it was my sloppiness at handling the billing that caused delays.  While I did finally get the 2nd portion of the invoice paid, it took awhile because it was not a small amount.  At least, in that case, I hadn’t dropped the ball on a deliverable, just an invoice.

What about our readers?  Have you had any embarrassing rollouts where you realized – or the customer pointed out to you – that something had been skipped?  Possibly a deliverable was never produced, or a document was never revised following feedback and delivered in its final format?