5.1 Closing the last project phase and the entire project

Closing the last project phase and the entire project

This section explains particularities of closing the last project phase which falls together with closing the entire project.

Evaluation, acceptance and transition of accomplished deliverables, performance evaluation, decisions about continuation and administrative closure happen at every phase end. However, at the end of the last phase, when it is also project end, many of the phase closure activities are combined with the project closure. Let us see them one by one.

Evaluation, acceptance and transition of accomplished deliverables, and performance evaluation.

The evaluation criterium of a phase or of the project is the accomplishment of objectives. And objectives refer to the scope of delivery according to requirements, in time and in budget plus satisfaction of any other defined success criteria.

Concerning the scope of delivery of the last phase: it accomplishes the project scope. Acceptance and transition of the scope delivered in the last phase means acceptance and transition of the end deliverable of the project. Functional requirements and quality attributes of the scope delivered in the last phase must satisfy the product requirements defined for the completed key deliverable of the project. During the review meeting of the solution, you would present documentation demonstrating that these acceptance criteria are fulfilled.

Schedule and cost performance at project end are best evaluated using the schedule baseline and the cost baseline. The earned value analysis is at project end less useful. Its strength is as early indicator of tendencies. But at project end earned value and planned value are 100% unless the project suffered early termination without delivering the solution. But if you delivered the solution the work performed is 100% of the planned work. And so, there is no schedule variance, and the schedule performance index is 1, even if the project finished late.

Therefore, the earned value analysis is not useful to measure the schedule performance at project end. It can, yes, be used to measure the cost performance, as you would compare the earned value that is equal to the approved, entire budget at completion divided by the actual costs incurred. If you delivered the entire scope budgeted at 100 and your actual costs were of 140, then the cost performance index of 0,71 would show realistically the cost overrun.

Due to this anomaly of the earned value analysis at project end, the best practice at project end is to compare actual delivery date and actual costs with the schedule baseline and the cost baseline.

However, if those baselines have changed during the project, it is debatable in how far you have to compare to the very first baselines. Let us say that following change control procedures the baselines were updated during the project to reflect changes that turned to be necessary during execution. If those changes were approved by the change control authority, they also approved the impact of those changes to the schedule and the cost baseline.

Do you have- nevertheless – to compare to the original baselines? Sometimes we listen in the news: “…Project X (normally a public funded project) was finished 400% over its original budget, and three years later than planned…”.  That is a comparison of actual costs and actual dates with the first baseline, regardless of all what happened in between that made the project change. Not only explanations at project end are needed. Political skills would be of good use. But, if you survived as project manager such a project, you have probably the political skills to demonstrate that the project was successful. And if the project manager was replaced and you are the new one, it is clear who is responsible from a political point of view. Rarely we see sponsors take responsibility for project failure. It is much handier to hint at the project manager.

Evaluation of stakeholders’ satisfaction. This evaluation is a standard item both for phase closure and project closure. For stakeholders who participated to the entire project you may combine the satisfaction survey for the last phase and for the entire project into one. For stakeholders who intervened only in the last phase the survey would be part of the phase closure.

Also lessons learned are part of a phase closure and of project closure. Concerning the last phase there are lessons learned specific to the type of work done in the last phase. When you are gathering them, you are actually closing the last phase. You may have learned lessons specific to construction, or to training end users during the deployment phase. And these lessons are unique and specific to a construction or to a deployment phase. There is value in gathering and documenting them. They will not help to improve any next phase because there is no next phase at project end. But the organization will certainly benefit from them when another similar project is executed.

Lessons learned with a full project perspective may or may not have something to add to what has already been captured at each phase closure. Otherwise, the main work at project end is to collate lessons learned and documented at closure of each phase. Distilling the most important ones with a full project perspective is probably good value.

The described areas of the project evaluation are what you would include in a project closeout report: achievement of project objectives, delivery of the defined scope, time and budget performance, stakeholders’ satisfaction, and a summary of lessons learned. A list of follow-up activities is also a good idea, for instance not implemented should-be and can-be requirements that could be implemented via a potential follow-up project or any other follow-up activities to be performed by the new owner of the project deliverable.

Decisions about continuation

All previous phases had a process of planning and approving the next phase.  At closure of the last phase there is no next phase to plan. So, this aspect of controlling phase gates is not performed for the last phase.

The comparable process from a whole project perspective would be planning a follow up project. And you would not plan for a follow-up project at project end. The decision about a possible follow-up project must go through a portfolio management process which is governed at corporate level. Perhaps the organization’s management has other priorities than to conduct a follow-up project to complete some requirements that were put in the backlog during the project ending now.

If the closing project is part of a program it is highly probable that another project in the program will use the key deliverable of the closing project as a necessary input or an enabler, but that is part of program management.

So, this aspect of closing does not apply neither for the last phase of a project nor for a  project as a whole at its closure. At least not from a project perspective. Perhaps yes from a program management perspective if the closing project is not the last project of the program.

Administrative closure

At the end of the last phase of the project, you have to conduct administrative closure activities that are specific to the last phase. As it is also project end, they may look like project closure activities, but – from a conceptual point of view – they are phase closure.

For instance: when releasing resources used in the last phase, that is phase closing. Same for phase specific suppliers. Evaluations are done as you would do at the end of any other phase.

If you have resources and suppliers that worked for the project during the entire project, then you did not release them at the end of previous phases. You would release them now at project end. Conceptually this would-be part of project closure. This does not prevent the project management team from having evaluated them at the end of each preceding phase.

If there are any claims open, definitely at project closure you have to settle them or hand them over to the legal department because the project will not exist anymore after project closure.

Archiving project information and assuring that all project logs are updated, the last two activities of phase closing are also performed at the end of the last phase. A project closure perspective for this type of closing activities would be consolidating and cleansing all these files and migrating them to the corresponding organizational repository.

Project success.

There are two questions at project end that need to be answered. Was the project successful? And is there anything else that needs to be done?

To answer these questions, we should revisit the project charter, which contains  the project success criteria and the business requirements.

The project success criteria should have been answered with the evaluation elements explained before.

The business requirements formulated in the project charter are the capabilities the organization ambitioned to acquire when initiating the project. A yes to this question depends on how well the scope of the project was defined. Defined, not delivered. We have evaluated how well the defined scope was delivered. With the question about the business requirements, we are asking how well that scope was defined in order to obtain the business capabilities desired by the organization.

If we did a good job during the elaboration of the project charter, the answer would be yes. If there was a mismatch between the business requirements and the defined key deliverable supposed to deliver those capabilities, then we would have, in a best case, a scope delivered according to product requirements, in time and in budget but that did not deliver the capabilities envisaged by the organisation. Another project will be necessary to fill the gap and the closing project would have a less than perfect rating, despite having delivered the defined scope in time and in budget.

Another and last aspect to consider: the benefits. This can be a trap for the project manager. Do not fall into it. The business case used to justify the project may show an expected return of investment of – for example – 16% from the project.

You should not have in your project charter a 16% return of investment as success criteria for the project. Because at project end you cannot have achieved it. Your project success criteria should be achievable with the scope of delivery of the project.

From a sponsor’s perspective however, corporate will expect the 16% return on investment and/or other benefits defined in the business case. But that should happen outside the scope of the single project and is subject of program and portfolio management. Both comprising operations and programs to obtain benefits (programs) and achieve corporate goals (portfolios).

From a project manager’s perspective, if the project delivered according to the project baseline, including other elements of success defined in the project success criteria, including business requirements and project management requirements, then, the project team and the project management team can and should celebrate success and should be celebrated as such.

À propos celebrate: you have achieved the end of this course.

Congratulations!