Get it in Writing – a Business Analyst’s Guide to Tracking Tech Projects Through Sign offs

Written by Brad Egeland on November 22, 2017. Posted in Articles.

Projects are all about documenting things, right?

Schedules, resource planning, budgets, budget forecasting, status reports, project plans, kickoff meetings, requirements, design documents, communication structures, testing, etc. etc. etc. The list goes on and on and on. Before nearly everything was done electronically, the number of trees that died for the sake of large projects was probably astounding. Now we rarely do anything with real paper – I’m amazed when I feel the urge to print out a document to do some review and editing on – it feels wrong but also very right at the same time. Depends on the document and level of detail I’m reviewing it.

Now, with all this documenting of everything – albeit electronically – there needs to be some form of acceptance. When I conduct project meetings I follow up with notes from the meeting and send them out to everyone. I request review and acceptance or changes by noon the next day so that we can all be on the same page. There is nothing worse than conducting what you thought was a successful meeting of 10 people and finding out there were 8 different versions of understanding walking out the door at the end of an hour long meeting. Not everyone has A+ listening or attention skills.

So, consider this…. project closeout is critical, right? There are often some critical steps to follow – either officially or unofficially – when closing out a project. Through experience, I have my “unofficial” closeout check list and it includes – at a minimum – the following…

Review the financials. Start by reviewing the project financials. Is everything still on budget? And just as important, are invoices being paid by the project client?
Re-review UAT. Was customer testing successful? Were there any remaining issues or action items that needed to be handled…and were they successfully closed out? Help the customer out – but don’t do the work for them… that would be a conflict of interest. But you know how to create test cases and test scenarios and they may not… so oversee that process carefully to make the UAT go as smoothly as possible… and with few or no delays.
Check the schedule milestones. Conduct a detailed review of the project schedule with your team and then follow that up with a review with the project customer. Make sure everyone agrees that all deliverables were delivered and all milestones completed successfully.
Finalize all training. Most customer solutions require some level of training to be conducted for the customer’s end user community. The training tasks were likely tasks you had built into the project schedule from the beginning. Does the customer feel adequately trained and ready to use the end solution?
Document lessons learned. Lessons learned sessions are skipped by so many project managers when even just a one hour phone call could end up being of great benefit long term. Don’t pass over this opportunity to learn from the project you’re completing…it can be invaluable.

Make sure you have all the sign offs. This one is critical and very important as a CYA (cover your a**). But it is also the project manager and business analyst’s way of documenting acceptance of everything important on the project. And since the business analyst is the most hands on individual on the project, official client sign off of deliverables, milestones, etc. comes through him. These sign offs are a way of documenting – officially – that all these things above have been completed and that the customer agrees they were finished appropriately.

What sign offs are we talking about? On a technical project there can be many – the business analyst is working closely with the project tech team and the subject matter experts (SMEs), some key end users, and the project sponsor or leader on the customer side… basically all of the customer project team… on many aspects of the project throughout the engagement. So anything that can be completed, officially handed off to the customer and considered DONE is a candidate for an official sign off.

Some areas that come to mind:

Functional system design
Technical system design
Plans and key documents that get reviewed like a communication plan, etc.
Functional design documents (FDDs)
Technical design documents (TDDs)
Requirements documents
Traceability matrix (if you create one)
User acceptance testing (UAT)
Any and all change orders
Any turnover/support agreement
Final system/solution acceptance and handoff

Getting sign off on these – at a minimum – on a technical project is very critical to the closeout of the project and to help ensure that the customer agrees with and pays for all the hard work you and your project team have put into the engagement.

Summary / call for feedback

Sign offs – real official sign offs – are good to have no matter how the project has gone and no matter what your relationship with the client may be. Things can go from great to bad in the middle of the project or 30 days after deployment, it doesn’t matter and you can’t predict it. But if you have sign off on everything important than you always have recourse to say something is done, accepted, approved, etc. and should be paid for or at least can’t be considered a reason for them to come back to you for what the client may consider to be unfinished business. You may be surprised how quickly a client who suddenly doesn’t like the outcome can come back to you asking for a refund or asking for more work, etc. even though they were happy with the work at the time and likely paid in a very timely manner for it. What I’m saying is… always avoid the potential risks and get it in writing.

Readers – what is your take on this? Have you had a situation where a client came back to you for what they thought was more necessary work or unfinished work and you either did or didn’t have official sign off? Has official sign off helped you get old invoices paid or change orders paid for when you otherwise may not have received payment? Please share any experiences… good or bad… you may have had and let’s discuss.