Closing Out the Project – Part 1
Posted by Brad EgelandWhen you’ve reached the end and deployed the solution, then it’s time to make sure everything has been completed, all paperwork is done, and no stones are left unturned. It’s best to do that with some sort of checklist and I propose using a list similar to this:
- Have all the project objectives been achieved?
- Is the client satisfied with the overall project?
- Have the necessary post-project support agreements been established?
- What were the major concerns with the project?
- What are the key lessons learned from the IT project?
- What would you do differently?
- Do you feel the solution was cost effective?
- When would it be applicable to enhance or update the delivered solution?
- What is your executive leaderships view of the project outcome?
In Part 1, we’ll discuss the first three items above:
- Have all the project objectives been achieved?
- Is the client satisfied with the overall project?
- Have the necessary post-project support agreements been established?
Have all the project objectives been achieved?
This should be fairly easy to evaluate. Look at the project schedule and review all milestones and deliverables. Have they been met? At this point, we’re not considering timeliness or budget, we’re just concerned with did we hand the customer what we said we would. Did we supply a Functional Design Document, did we provide weekly status reports, was training completed successfully and signed off, was user acceptance testing (UAT) fully completed including re-review of all issues and did we get official signoff, etc.
Though it definitely shouldn’t be the first time during the engagement that you do this – it’s also a very good time to go back to your kickoff session notes and see that all points discussed during that meeting have been addressed. Make sure at this point that the customer knows you’re concerned that you fully covered everything for the project – they’ll appreciate it and it definitely helps with customer satisfaction levels and can increase the chances of repeat business from this customer.
Is the client satisfied with the overall project?
You may think you can simply answer this yes or no based on your knowledge of how things went on the project and the communications you had with the customer along the way – but that is not always the case. On some projects, you can end up being very surprised by the customer’s on viewpoint of their satisfaction levels.
I’ve had customers on projects that went extremely smoothly later state that they weren’t happy about how I handled something or weren’t pleased with one of my team members or how we delivered ‘x’ deliverable. And I’ve had other projects were I was certain the customer was just about ready to ask that I leave the project only to find out that they were very happy with me and with the team and how things were going. They were just demanding and somewhat needed. But we were meeting their needs and they were happy. It’s amazing how off your perception can sometimes be concerning your perception of the customer’s satisfaction level and what their satisfaction level truly is.
Have the necessary post-project support agreements been established?
Usually you’ll move from deployment into a post-deployment with some sort of pre-defined plan to both hand-off overall support to your tech support group but also you’ll agree to make your original delivery team available for a 30 or 60-day window to do immediate fixes should problems arise in the functionality of the delivered solution. That’s something that just needs to be worked out with the customer and something that was likely planned for both by Sales with the customer during the sales process and discussed between you and the customer during kickoff.
Just make sure that whatever the plan is, you act on it. If it’s to keep your team available for 60 days should problems arise, then make sure that every team member knows that and that each of their managers know that as well. It can have an affect on their next assignments, but it must be addressed in advance of deployment.
Next
In Part 2 we’ll further discuss these items in terms of the project closeout checklist/review…
- What were the major concerns with the project?
- What are the key lessons learned from the IT project?
- What would you do differently?
Related posts:











Closing Out the Project - Part 2 | Project Management Tips || Project Management, Collaboration and Knowledge Management Blog says:
[...] Part 1, we started the process of covering some critical questions to ensure all of the project [...]
Peter Taylor says:
I am a strong advocate for a Project Retrospective these days. I describe the project clsure report and the review meeting as the evaluation of the ‘hard’ project facts and the retrospective as the ’soft’ facts, the emotion of the project.
I strongly recommend Norman L Kerth’s book on Retrospectives.
Peter Taylor
The Lazy Project Manager
I have a full guest post on this subject here:
http://blog.brodzinski.com/2009/09/value-of-lessons-learned-art-of-good.html
Brad Egeland says:
Peter-
Thanks for your comment and for your own insight on the project closure process. The book sounds interesting – I’ll try to take a look at it. Thanks again.
Closing Out the Project - Part 3 | Project Management Tips || Project Management, Collaboration and Knowledge Management Blog says:
[...] Part 1 and Part 2, we covered the first six critical questions listed below that should be addressed when [...]