Closing the project or phase

We'll review different phase-oriented project configurations next, but let's assume all project work has been completed, the customer has signed off and formally validated that you produced the deliverable(s) correctly, they have accepted the result as completed, and all procurements have been closed. There is still some work left to do to formally close a project or phase.

It is quite common to have a final meeting to discuss lessons learned and create a final report. Administrative closure may include archiving project documents, and making sure all procurement items have been closed and waivers have been signed. At this point, the product life cycle is about to begin and may require a physical or technical transfer of the result to the customer/end users, and potentially you will release your team.

 In some cases, there will be training for those that will support the product, or maybe the customer's help desk needs to take over, so they will be trained or updated prior to close.

Even if a project is canceled in the middle, you would go through a formal closure and would still need a signature accepting whatever deliverables have been produced before you could close the project formally.

The process groups, or life cycle, of a project are designed to have time to plan and build out comprehensive plans; while executing those plans, keep an eye on things and make changes as needed. If you just went back to re-read time to plan and snorted a bit, I understand. I'm snorting too.

The perfect world gives us time to be as comprehensive in our planning as is needed to be successful. If you go head first into execution and project work, I feel your pain. Maybe you can blame all these new best practices on me or CompTIA and ask for time to create templates and implement new skills to save the company money. Remember to include the money bit in your conversations and hopefully you'll have the time you need. My conversations usually start with I have an idea on how to improve the organization with new best practices for project management. The responses range from, We've always done it this way to Yeah... no. Those conversations usually end with me responding with, Yeah, but that isn't working. Organizational-process assets strike again!

If that is your world right now, choose your documents and best practices wisely to help plan (yet streamline) your project work. I always tell my project managers that the slow-moving wheels of progress need some help from time to time, and typically without proof, progress stops completely.

Keep note of any documents and best practices as you read through this guide that resonate with you or sound like something you need. Jot them down and try them out. These best practices, once implemented, can provide the documentation and actual cost and time savings to show to your organization to get those wheels moving again. Game on!