Visual Paradigm logo
Jump to Menu

IT Project Management - Closeout Phase

A quick walk-through

The Closeout Phase of the IT Project Management Lifecycle

The previous phase, which is the Execution and Control phase, ends with the acceptance of project deliverables. In this phase, the Closeout phase, the project team documents the lessons learned from the project, and transfers the deliverables to operations staff, who will use and maintain the deliverables as an on-going activity.

Part of this phase involves having the project manager captures the lessons learned from the project, and developing a Lessons Learned document. This document will serve as an input for similar projects in the future, allowing these projects to run more smoothly. Another document to develop is the Project Closeout Report, which consists of studies of variances between the actual and baseline performance goals, project cost and schedule. It also includes a description of on-going operation and maintenance plan.

Activities and deliverables

The table below lists the major activities of this phase and the deliverables (i.e. process documents) output from the activities.

Activity Description Deliverable
Conduct Closeout Meetings Conduct closeout meetings with different project participants in collecting and discussing their feedback so that lessons learned are captured. These meeting also helps the project manager in developing a plan for project transitioning.
Develop Lessons Learned Develop a Lessons Learned document that describes the things that went wrong and well throughout the project lifecycle, and with recommendations. Lessons Learned
Develop Closeout Report Develop a Closeout Report which document the variances from the baseline plan. Project Closeout Report
Archive Project Documents and Artifacts Ensure all project documents are properly stored for future access.
Conduct Transitioning Activities Transfer the deliverables transferred to the operations staff.

Conduct closeout meetings

This phase begins by conducting meetings with different participants of this project, which include but not limited to the stakeholders who took part in different project activities such as requirements elicitation and acceptance testing, and the project team members. The purpose of these meetings include:

  • Identify lessons learned: Discuss things that went wrong and went well during the project, and determine how the experiences earned from this project can benefit similar projects in the future.
  • Develop transition plan: Discuss the arrangement of the transitioning of project deliverable to operations staff.
  • Develop post-implementation review plan: Discuss the dates for post-implementation reviews.

Develop Lessons Learned

Now that you've completed the Identification, Initiation, Planning, and Execution and Control phase of the IT Project Management Lifecycle, it's time to document the lessons learned based on both the positive experiences, and the negative experiences that result in undesirable outcomes.

Lessons learning is a process to convert experiences into knowledge to aid future decision making and problem solving. It helps improve project performance, avoid mistakes from happening again, and maintain good practices. A typical lessons learned document consists of three parts.

  • Project successes, which are the key successes of the project.
  • Project challenges and difficulties, which are the difficulties faced during the project lifecycle
  • Shortcomings, which are the tasks and decisions performed and made wrongly

Project Successes

Project success refers to key successes achieved by the project. Instead of just describing the successes the project has had, it's more valuable to state the factors that contribute to these successes so that similar projects can repeat the successes.

Here are some examples of Project Successes:

Success Success Factors that Contributed to the Success
Activities are completed as planned Project risks were identified early and discussed often, reducing the chances of changing schedule caused by unexpected issues.
Quick deployment of changes The use of continuous integration makes deployment fast and stable.
Budget within control Appropriate cost benefit analysis, resource and procurement planning.

Project Challenges and Difficulties

Project challenges and difficulties refer to the conditions, not under the control of the project team, which affects the project negatively. Unlike Project Successes, you have to describe the challenges faced, and a solution recommended. A recommended solution can be one that's implemented and found effective. It can also be a better alternative of the implemented option.

Here are some examples of Project Challenges and Difficulties:

Challenge Recommended Solution
The existing system must be kept running whilst the developing of new system Separate the development and production environment.
Stakeholders aren't clear about their needs Try to use storyboard and wireframe to gather and confirm their needs.

Project Shortcomings

Shortcomings are the tasks that were done wrongly or poorly, or any decisions made incorrectly. It's sometimes confused with challenge and difficulty, yet it is neither. To make it simple, challenge and difficulties are adverse situations that require resolving in order for the project to complete, while shortcomings are fault and failures.

Here is an example of Project Shortcomings:

Poor communication among the team Recommended Solution
Activity Use instant messenger in project.

Develop Closeout Report

The deviation between project result and project plan is inevitable. Part of this activity involves identifying the variances from the baseline plans, in terms of project performance, project cost and schedule. Besides stating the planned and actual figure, it is important to state the variances and, most important, an explanation of why such variances exist.

Let's take a look at the contents of a typical closeout report.

Compare variances from baseline plans
  • Performance goals: Describes how the project performed against each performance goals established in the Project Performance Plan.
  • Project cost: State the planned and actual cost for the project. It also documents the variances and explains why such variances exist.
  • Project schedule: Document the initial approved schedule baseline against the actual completion dates. It also describes the schedule variances with explanation.
  • Scope changes: Document any changes to the project scope and their impact on performance, cost, or schedule baselines.
  • Project resources: Identify to whom each project resource was transferred and when it was transferred. Account for all project resources utilized by the project.
  • Operations and maintenance plan and cost: The plan for operation and maintenance of the project deliverables. It states the estimated annual cost of operations and maintenance.
  • Project documentation: Identifies all project documentation materials stored in the project library or other repositories. It identifies the type of media used and the disposition of the project documentation.
  • Post-implementation review and report: Identifies the date for completing the post implementation report and the person responsible for this action.
  • Open issues: The open issues for resolution within the context of project closeout.

Archive Project Documents and Artifacts

The project manager has to work with other project participants in storing all project documents and artifacts for future use or references. He also need to ensure that all necessary approvals and signatures are present. Besides, make sure the required final versions of documents are archived in auditable form in the agreed upon place, and ensure that they cannot be edited. Store the other project artifacts according to the agreed upon procedures.

Conduct Transitioning Activities

Project transitioning

The project is about an end. You have to transfer the physical product and any other knowledge require to operate it, to the operations staff who will use and maintain the product as an on-going activity.

Generally speaking the transitioning involves the transferal of the items below:

  • Knowledge Transfer: The knowledge required in order to operate with the end product. Examples include an understanding of how the product gear up with the business workflow, how the features work, any login credential required, any assumptions made, who can be contacted for help, and how. A user training could be a good method for knowledge transferal.
  • Documentation Transfer: The written material that gives instructions or information regarding the use of product
  • Physical Transfer: Physically turn over control of the product to the operational unit responsible for supporting it.


Turn every software project into a successful one.