Closing a Project or Phase

“Close Project or Phase is the process of finalizing all activities for the project, phase, or contract.

The key benefits of this process are the project or phase information is archived, the planned work is completed, and organizational team resources are released to pursue new endeavors.

This process is performed once or at predefined points in the project.

The inputs, tools and techniques, and outputs of the process are depicted in Figure 4-14” (PMBoK Guide p121).

Closing a project is not like switching a computer off. There is still a lot to be done, and a lot that can go wrong.

The Close Project or Phase process is another one where the Project Manager takes center stage and will be checking that that all project work is completed and that the project has met its objectives, including work and objectives that were added along the way as the result of approved change requests.

Just a reminder here that the type of “phase” mentioned here is a mini-project inside the main project.

The activities necessary for the administrative closure of the project or phase include:

• Actions and activities necessary to satisfy completion or exit criteria for the phase or project such as:

  • Making certain that all documents and deliverables are up-to-date and that all issues are resolved;

  • Confirming the delivery and formal acceptance of deliverables by the customer;

  • Ensuring that all costs are charged to the project;

  • Closing project accounts;

  • Reassigning personnel. Depending upon the organization type (we will be covering organization types later in the course) the project staff will be assigned to another project, or they will return to their usual jobs, or their contracts will be finalized and they will leave the organization to take up the next contract.

  • Dealing with excess project material. This can mean dealing with the materials and equipment that is lying around after the project has finished. For example, after completing a building there will be piles of bricks, sands, roof tiles, offcuts of wood, bags of cement, and so on. All this needs to be dealt with. Some can be returned to stock, machines will be returned to the store, or returned to the hire company, and material that can’t be reused or recycled but be cleared away.

  • Reallocating project facilities, equipment, and other resources; and

  • Elaborating the final project reports as required by organizational policies.

• Activities related to the completion of the contractual agreements applicable to the project or project phase such as:

  The next activity is:

  • Confirming the formal acceptance of the seller’s work. It the work is not up to the agreed standard, the seller should bring it up to standard. This is often a contentious area, with the seller trying to charge for re-work as an “enhancement”. This is where you need to be as clear as possible on the scope and quality requirements. But you can’t think of everything.

    For example, on a project I was managing, to produce a new financial system, one of the required functions of the system was to pay contractors at the end of each month, for the work they had done during the month. We tested the module a number of times. There were a few bugs discovered, but the developer fixed them.

    But on a full-scale test of the whole system I discovered that if a contractor had no billable hours during the month, the system would process a payment for zero dollars and attempt to make a zero dollar payment to them.

    I reported this to the appropriate developer as an obvious bug.

    His response was “It is an enhancement. You did not specify you didn’t want the system to make zero dollar payments of no work performed”

    So, never assume “common sense” applies to contracts.

  • Finalizing open claims. This is where you have made claims against a provider for work that you believe is substandard, but the provider is arguing the case. Or it could be penalties built into the contract have been triggered. For example, there may be a penalty in the contract if the provider fails to meet certain milestones. But I have found in practice, that penalty clauses seldom work, and trying to argue them can cause the provider to stop work. And if it goes to Court, you will pay the lawyer more than the provider owns you.

  • Updating records to reflect final results, and

  • Archiving such information for future use. As well as being a sensible thing to do, most countries have laws to ensure that business records are retained and securely stored.

We are examining the activities necessary for administrative closure of a project phase. These would also include:

• Activities needed to:

  • Collect project or phase records,

  • Audit project success or failure,

  • Manage knowledge sharing and transfer,

  • Identify lessons learned. Please note that you should be recording lessons learned as they are learned, rather than waiting until the end, because you will have forgotten them.

  • Archive project information for future use by the organization.

• Actions and activities necessary to transfer the project’s products, services, or results to the next phase or production and/or operations. The whole point of the project is to create a unique product, service, or result. But that means you have to hand them over. In most projects, deliverable will be completed and handed over throughout the project, rather than doing it all in one hit. The one hit problem is you may discover a serious, previously undetected fault in the dying stages of the project. This is a very bad time to discover a serious fault.

• Collecting any suggestions for improving or updating the policies and procedures of the organization, and sending them to the appropriate organizational unit. This will probably overlap with recording lessons learned. Remember to be as specific and focused as possible. Use metrics where possible, because if you can’t measure it, you can’t tell if it has been improved.

• Measuring stakeholder satisfaction.

  The Close Project or Phase process also establishes the procedures to investigate and document the reasons for actions taken if a project is terminated before completion. In order to successfully achieve this, the project manager needs to engage all the proper stakeholders in the process. My preferred way to do this is by questionnaire and survey. And “no”, questionnaire and survey don’t mean the same thing. The questionnaire is the question and answer sheet, and a survey is a tool for analyzing the results.

CLOSE PROJECT OR PHASE: INPUTS

1. PROJECT CHARTER

   The project charter documents the project success criteria, the approval requirements, and who will sign off on the project. My tip is, specify the “office” rather than the person. For example, “This document to be approved by the area Financial Controller”, rather than, “This document must be approved by Efrem Zimbalist Jr”, because, in a number of months’ time, Efrem may have left, changed position or gone on leave. As I mentioned earlier, the problem with common sense on projects is that it isn’t very common.

   People are worried that they may be replaced one day by Artificial Intelligence and Machine learning when the truth of the matter is that a few of them could be replaced by a few lines of code.

   Avoid the hassle, specify the “office” rather than the person.

2. PROJECT MANAGEMENT PLAN

   All components of the project management plan are an input to this process.

3. PROJECT DOCUMENTS

   Project documents are used on the project but are not considered part of the Project management plan. They could include:

   • Assumption log. This records all the assumptions and constraints that guided the technical specifications, estimates, schedule, risks, etc. Assumptions are what you believe to be true for the duration of the project, and constraints are what you believed to be limiting your ability to manage the project. I guess now is the times to find out if you were right. My advice is to maintain a record of the source for you believe in these assumptions and constraints because it the project has gone badly, and the blame-game starts, the blame-game will start with the assumptions and constraints – then the risk register, and move on to the Basis of estimates. These documents will be your first line of defense.

     But… of the records indicate you are to blame for the failure – shredding the records is not an option :D

   • The basis of estimates. The basis of estimates is used to evaluate how the estimation of duration, cost, resources, and cost control compared to the actual results. The same note as for assumptions and constraints. Keep a careful record of where these came from.

   • Changelog. This records the status of all change requests throughout the project or phase. You should have been doing a regular audit of this. But this is your last chance to check that nothing has slipped through the cracks.

   • Issue log. Again to a final check to make sure all issues have been dealt with.

   • Lessons learned register. The team will have been recording lessons learned throughout the project, and so this is really a final edit to remove all the junk, prune out the ten versions of the same problem, recorded by ten different people, or ten versions of the same problem, recorded by the same person, who has some “issues”, to make it suitable for transferring to the lessons learned repository.

   • Milestone list. The milestone list shows the final dates on which the project milestones have been accomplished.

   • Project communications. Project communications include any and all communications that have been created throughout the project.

   • Quality control measurements. The quality control measurements document the results of Control Quality activities and demonstrate compliance with the quality requirements.

   • Quality reports. The information presented in the quality report may include all quality assurance issues managed or escalated by the team, recommendations for improvement, and the summary of findings from the Control Quality process.

   • Requirements documentation. Requirements documentation is used to demonstrate compliance with the project scope.

   • Risk register. The risk register provides information on risks that have occurred throughout the project.

   • Risk report. The risk report provides information on the risk status and is used to check that there are no open risks at the end of the project.

4. ACCEPTED DELIVERABLES

   Accepted deliverables may include approved product specifications, delivery receipts, and work performance documents. Partial or interim deliverables may also be included for phased or canceled projects.

5. BUSINESS DOCUMENTS

   What are business documents? They are documents created outside the project, which result in a project being initiated. The Project Manager uses them but does not update them.

   Business documents include:

   • Business case. The business case documents the business need and the cost-benefit analysis that justify the project. And now is the stage to check if the justification was valid.

   • Benefits management plan. The benefits management plan outlines the target benefits of the project. This will also be used to determine when to confirm when the benefits are to be verified as achieved, who will check them and the criteria to be used.

6. AGREEMENTS

   In this case, “agreements” means the contracts that were issued for the project and recorded in the Procurement Management Plan. The actual requirements for formal procurement closure are included in the Procurement Management Plan and can be checked against the terms and conditions of the contracts.

7. PROCUREMENT DOCUMENTATION

   To close the contract, all procurement documentation is collected, indexed, and filed.

8. ORGANIZATIONAL PROCESS ASSETS

   The organizational process assets that can influence the Close Project or Phase process include:

   • Project or phase closure guidelines or requirements (e.g., lessons learned, final project audits, project evaluations, product validations, acceptance criteria, contract closure, resource reassignment, team performance appraisals, and knowledge transfer).

   • The configuration management knowledge base containing the versions and baselines of all official organizational standards, policies, procedures, and any project documents.

CLOSE PROJECT OR PHASE: TOOLS AND TECHNIQUES

1. EXPERT JUDGMENT

   Expertise should be considered from individuals or groups with specialized knowledge or training in the following topics:

   • Management control,

   • Audit,

   • Legal and procurement, and

   • Legislation and regulations.

2. DATA ANALYSIS

   Data analysis techniques that can be used in project closeout include:

   • Document analysis. This is used to extract information to record in the Lessons Learned.

   • Regression analysis. This technique analyzes the interrelationships between different project variables that contributed to the project outcomes to improve performance on future projects. Sometimes this can be combined with Sensitivity Analysis techniques, which involves re-examining the interrelationships, which keeping a single variable constant throughout the analysis, then repeating for each variable, to see which variables had the greatest impact.

   • Trend analysis can be used to validate the models used in the organization and to implement adjustments for future projects. This is important because there is a tendency to blindly trust business models, even if some weaknesses are beginning to show. The models need to be checked against reality, and then be adjusted or replaced.

   • Variance analysis can be used to improve the metrics of the organization by comparing what was initially planned against the end result.

3. MEETINGS

   Meetings, such as close-out reporting meetings, customer wrap-up meetings, lessons learned meetings, and celebration meetings, may be used to confirm that the deliverables have been accepted, to validate that the exit criteria have been met, to formalize the completion of the contracts, to evaluate the satisfaction of the stakeholders, to gather lessons learned, to transfer knowledge and information from the project, and to celebrate success. However, it has been my experience that a celebration meeting works best if held in a restaurant.

CLOSE PROJECT OR PHASE: OUTPUTS

1. PROJECT DOCUMENTS UPDATES

   All project documents may be updated and marked as final versions as a result of project closure and archived in the organizations records management system.

2. FINAL PRODUCT, SERVICE, OR RESULT TRANSITION

   A product, service, or result, once delivered by the project, may be handed over to a different group or organization that will operate, maintain, and support it throughout its life cycle.

   This output refers to this transition of the final product, service, or result that the project was authorized to produce(or in the case of phase closure, the intermediate product, service, or result of that phase) from one team to another.

3. FINAL REPORT

   “The final report provides a summary of the project performance. It can include information such as:

   • Summary level description of the project or phase.

   • Scope objectives, the criteria used to evaluate the scope, and evidence that the completion criteria were met.

   • Quality objectives, the criteria used to evaluate the project and product quality, the verification and actual milestone delivery dates, and reasons for variances.

   • Cost objectives, including the acceptable cost range, actual costs, and reasons for any variances.

   • Summary of the validation information for the final product, service, or result.

   • Schedule objectives including whether results achieved the benefits that the project was undertaken to address. If the benefits are not met at the close of the project, indicate the degree to which they were achieved and estimate for future benefits realization.

   • Summary of how the final product, service, or result achieved the business needs identified in the business plan. If the business needs are not met at the close of the project, indicate the degree to which they were achieved an estimate for when the business needs will be met in the future.

   • Summary of any risks or issues encountered on the project and how they were addressed.”

   (PMBOK Guide p127)

4. ORGANIZATIONAL PROCESS ASSET UPDATES

   Organizational process assets that are updated include:

   • Project documents. Documentation resulting from the project’s activities; for example, project management plan; scope, cost, schedule, and project calendars; and change management documentation. The project Calendars record the times when resources will or won’t be available. It may be that the [project is finishing earlier – or more likely, later – than expected, and so the resource available needs to be updated on the appropriate calendar.

   • Operational and support documents. Often, especially in the case of Information Technology projects, the project team operates, supports and maintains the product or service. This is the time when the support documentation is handed over to the support department, and responsibility for operation is passed to the Business. This is one of the reasons why you should close the project as soon as possible, otherwise, your team will be kept busy supporting and operating the products, long after required. And the costs for this are coming from your project budget.

   • Project or phase closure documents. These are formal documents that record completion of the project or phase and the transfer of the completed project or phase deliverables to others, such as an operations group or to the next phase. The Project Manager will review prior phase closure documentation, customer acceptance documentation from the Validate Scope process, and the agreement (if applicable) to ensure that all project requirements are completed prior to finalizing the closure of the project. It could be a disaster of the project were formally closed and the team disbanded, only to discover that deliverable or a significant body of rework was still outstanding. However, in the case that the project was failing, and was closed prematurely, the formal documentation will record why the project was terminated and formalizes the procedures for the transfer of the finished and unfinished deliverables of the canceled project to others, as well as the return to stock, or sale of unused materials, or they may be passed to the customer, depending upon the agreements.

   • Lessons learned repository. Lessons learned and knowledge gained throughout the project were maintained in a Lessons learned register, but the final, edited version, is now transferred to the lessons learned repository for use by future projects.

That brings us to the end of the Close Project or Phase.

And it’s also the end of the Project Initiation Management module

The next module is “Project Scope Management”

Please read the corresponding chapter in the PMBoK Guide before watching the video.