You’ve reached the final stretch! Congratulations is in order – but before the podium, comes the declaration! Everything has an end. Project closure is a time to take stock, assess the successes and failures, and take lessons and learnings that you can transfer to future projects. But so often, this stage of the project is neglected – project managers are already moving onto the next assignment and want to get things wrapped up. In order to achieve a clean project completion, a lot of activities are necessary, which do not happen by themselves, but have to be planned and controlled just like everything else.
Project closure is as much a part of the project as any other project phase. As with project start, closing activities must be planned and controlled. In the best case, they are firmly integrated into the project planning. In this phase, the project manager has the last chance to actively influence his project. Anything that comes after this is beyond his power. It can be so tempting to ignore project closure. After all, we’re through. The client seems pleased, the team has moved on to other things, and we’re ready to move on too. In some cases, we may be mourning the end of a totally fun experience, and in other cases, we may be exceedingly grateful that it’s finally over. Good or bad, we may be simply ready for some new challenges or new people in our work lives. Whoa there! Don’t stop…. There are some important steps that need to be taken to properly close out your project. Here are some steps you don’t want to forget as you head into project closure.
Assess the project plan
Remember eons ago when you started the project? You said you were going to accomplish certain objectives. You said that you were going to measure your success with specific metrics. Have you done that? Don’t assume your project was successful because everyone is glad to be through and the client seems reasonably happy. Go back and look at what you said constituted success. Were you successful? Try to identify why you were successful or not. You will learn much from that experience that will inform the way you manage future projects, the way you bid on future projects, and the kinds of projects that you take on. If you do find something you missed, don’t panic. If it were critical, it likely would have come up in testing, QA or before transitioning services. The best thing to do it to be transparent to your team and to your client, and find a way to weave the items in.
Ask the client for feedback
Not all clients are open to this, and not all companies are willing to let you ask, but if you have a good relationship and know it won’t cause problems, ask about what went well and what didn’t go well. I don’t make as big a production of this as I do with our internal retrospectives, but there’s insight from outside your company that you could find valuable. I’ll usually just ask a few questions in email, casually – like “Hey, was there anything that specifically stuck out for you about this project, good or bad, that you can tell me about?” It’s not extremely invasive, and can easily be ignored if the client is not inclined to give you additional information. For maximum impact, get client feedback before finalizing your internal retrospective and share the information with your team. Internal feedback is great; client feedback is irrefutable.
Review and release team members
Don’t just leave your team wondering what happened. If your project was done in a corporate environment, make sure that HR knows you are no longer using these people and that they can be assigned to other projects. That said, a highly functioning team can be a huge resource and if you’ve spent months building one, do everything you can to keep the team intact. Write a performance appraisal on each team member and discuss it. If appropriate, write a review on LinkedIn, and/or a testimonial that the team member can use on his or her own marketing site. In this project world we live in, we all count on our project leaders to support us as move on to our next projects. Remember reciprocity.
Document any lessons learned
After you have taken the time to go through the process of identifying lessons that you’ve learned, where are you going to document them? Do you have a lessons learned catalog? This is especially important for corporate and non-profit projects. No one likes to make the same mistakes over and over again and that is guaranteed to happen if you don’t really analyze what happened and document what you learned in some kind of searchable, usable format.
Follow project closure procedures
In some teams, project closure requires some accounting updates, or possibly documentation requirements that apply in some verticals. There could be any number of things that the PM is required to do at the end of a project that you might not think to do. You should already have a good sense of what is required, but if you’re not sure what is expected of you, make sure you ask!
Take a really deep breath
Take a really deep breath, and if you can, a nice break from work for a bit to congratulate yourself on a job well done, and to clear your mind for your next launch. This advice isn’t just for complex projects, where it’s pretty obvious that you should take a breather, but even for more run-of-the-mill projects. Clearing your head, putting a mental “period” at the end of the project sentence, can be really cathartic. If you can get outside, that’s ideal – look up at the sky, get a lungful of fresh air, allow yourself to go through the last little bits of loose ends from your retrospective and the look on your team’s faces when you gave them a tiny cupcake in brand colors, and breathe out. Reset for the next big wrap-up. And give yourself a high five if no one is looking 😉
