Project Close Activities
Ending Projects Properly
Projects usually have a clearly defined end – a bridge opens for public use, a product launches, or new software rolls out to everyone in your organization.
As you approach the "go live" stage and you're getting ready to hand the new process over to "business as usual," are you looking forward to relaxing for a while, or are you already planning your next project? Either way, before you move on to new challenges, it's important you don't ignore the final step of project closure.
This doesn't just mean dotting the "I's," and crossing the "T's," or tying up any loose ends. It means capturing the lessons you've learned during the project, so that your team – or other departments within the organization – can benefit from them next time. And, it also means taking stock of what you've achieved, and celebrating your successes.
The steps you need to take to formalize the project's acceptance are sometimes called the "close project process." This process verifies that the project has delivered the required outcomes, and that stakeholder expectations have been met. It also makes sure that everyone involved in the project knows how to move forward. Without formal closure, there's a risk that issues may arise, and no one will be assigned to resolve them.
Project closure has many different elements, and the best way to carry out a closure is to plan for it from the start. This way, you have the opportunity to decide which criteria you'll use to show that the project is actually completed, and you can budget time and resources for the closing activities. As with all goals, it's important to know what you need to do to cross the project finish line.
Sometimes, a project is canceled before it's finished. When this happens, some parts of project closure become irrelevant. However, other elements may still need to be completed.
In this article, you'll learn the steps for closing a project properly. Start by adding the following guidelines for project closure to your overall project plan. We've arranged them using the project closure outputs defined by the Project Management Body of Knowledge (PMBOK) Guide, and endorsed by the Project Management Institute (PMI). As you read, think about the specific methods you'll use to plan sufficiently for closure practices.
These activities relate to the overall management and oversight of the project. You need to address issues such as these:
- Decide how you'll test deliverables (in some projects, for example in complex systems implementations, testing may occur much earlier than the closure project stage.)
- Establish a plan to review and analyze "open" issues.
- Decide how you'll collect project records, and who will be responsible for doing so.
- Determine how you'll analyze success or failure (this is often expressed in a project's Project Initiation Document, as modified by scope control processes).
- Gather lessons learned so you can apply them in future.
- Plan for knowledge transfer. If you used external consultants, decide how you'll capture and retain their knowledge of the project details.
- Establish project finances. This includes details like closing project codes in the finance system, and accounting for any remaining assets.
- Decide how to manage communication related to closure. How many meetings will you hold, who will attend, and what specific closure documents will you need?
- Archive project information.
- Shut down the project office.
A Post-Implementation Review (PIR) is an essential part of administrative closure. This formal review process helps you determine the overall effectiveness of the project. It provides an excellent framework for gathering lessons learned, and maximizing the benefits of the program.
These activities formalize the acceptance of the project outcome and deliverables.
There may be an actual contract document when dealing with external customers. If the project is for an internal department, you may simply have an acceptance email.
Either way, planning for contract closure is important, because you need to know exactly what defines project completion before you begin. Here are some things to consider:
- Determine how you'll define acceptance criteria.
- Define exactly what the acceptance criteria are (again, this is usually defined in a Project Initiation Document, as modified by the scope control process).
- Identify who is authorized to approve project completion, and determine that criteria have been met.
- Determine how you'll control and manage the inevitable changes to the contract.
- Decide what terms are needed if the project is not completed.
During the project closure phase, the project team is responsible for meeting predefined criteria. It's also important to make sure that the client or end user is fully satisfied with the results. If any changes have been made to the contract before project completion, the contract document may need to be updated appropriately. The business requirements analysis is a key input to the project closure process. The more of these up-front planning tools you use, the easier it will be to bring the project to a close.
Transition/Handover of Project Results
As well as formally acknowledging that the project criteria have been met, determine how you'll hand over responsibility for the project result to "business as usual." When a project deliverable is being developed, the project team is in control. However, when the deliverable is ready to use or implement, then the end users need to know what to do. To plan for handing over the final product, be sure to address these issues:
- Determine what end-user training is required (again, in complex projects, this may need to happen much earlier than the project close stage).
- Identify who will provide the training, and when.
- Determine how much time the handover activities will take.
- Decide how and when handover will take place.
- Identify who will formally approve the transition process.
After the final transition to your client, internal or external, you should receive a formal statement of acknowledgment. This finalizes your contractual obligations, and it gives the project team final recognition of their accomplishment.
Consider a project completion celebration for the team, end users, and other key stakeholders. This is a great opportunity to recognize a job well done, and it can motivate workers as they prepare for their next assignments.
It's important to recognize team members' achievements, both privately and publicly. Thank and praise each person individually. Then announce the project's completion, and highlight how the team's efforts benefited the organization.
Archive the project information so that it's an accessible resource for future project teams. This function is easy to overlook, especially as team members separate and move on to other work. As with the other project closure activities, the more proactive you are with planning, the better the result. If you establish archive expectations at the start of the project, you'll be more likely to collect and store the information you need. Your archive system should include these types of items:
- Project files – planning documents, risk documents, status reports, presentations, financial reports, contracts, and significant communications.
- Formal acceptance documents – statements issued by end users, approved change requests, and documented issues and solutions.
- Project closure documents – contracts, invoices, schedule of training provided, and an "open issues" file.
- Historical information – lessons learned, and a knowledge database.
You should gather and store these unique organizational assets electronically as well as physically. Many of these will be computer files, so back them up regularly. With physical files, make sure the information is well organized, and stored where people can easily access it.
The end of a project is a significant event. Therefore, it needs its own set of processes and activities for formal closure. This shows that the project goal has been met, and it provides a sense of accomplishment for the project team.
Closure also ensures that lessons learned are gathered and stored, and that end users' needs and expectations have been met. With an official close, you know that the stakeholders are satisfied. Then you're free to reassign the project team, and reallocate resources to other projects – and start the cycle all over again.