CHAPTER 4

Project Closure

4.1 Introduction

Project closure may happen in different ways:

1. The “normal” way is when the project has been delivered as to what had been agreed in the beginning (contract, project definition).
2. The other way is when the project has been terminated during execution due to the business case reevaluation and it turns out that it is no longer of any use to proceed with the project.

This chapter deals with the “normal” way of ending a project.

4.2 Business Case

At the end of the project, the business case needs to be validated for the last time. During the course of the project, the business case may already have been changed several times due to change in conditions.

You could draw a kind of a timeline to show how the business case developed over time in order to indicate the differences from the initial business case up to the final business case.

The main thing is that you should verify what has been delivered versus the final version of the business case.

4.3 Final Report

The final report at the end of the project is intended to review how the project performed compared to the initial project document (in Prince2 the Project Initiation Document).

Sharing the lessons learned is crucial. Address both what went well and what didn’t go well. The target audience could be (not limited to):

1. All stakeholders (of course also the sponsor)
2. The entire project team. For virtual team members use video conferencing
3. The people who have been involved at the RfP/RfI process (legal, pricing, etc.) and all TSMs
4. Other project managers
5. Quality assurance representatives

The report could contain (not limited to):

1. Review of the initial business case (looking at benefits for instance)
2. Review of the project objectives (costs, time, etc.)
3. Review of the team performance
4. Review of the products (quality records, etc.)
5. Lessons learned

4.4 Project File Closure

It should be noted that the project file should be preserved for a number of years, which is dependent on the local legal regulations and the regulations of the supplier.

How often does it happen that a project file is transferred (the question is often to whom) and that access is not provided to the project file after the project is completed (thinking in particular electronic project files)?

The project file is a very important piece of evidence during internal/external audits and also when, for example, a project is for an external client and the client, for whatever reason, is so dissatisfied that legal action is taken against the supplier.

In this case it is crucial to have the original project file available and it is a challenge for the supplier to refute the accusations of the client based on the contents of the project file.

4.5 Discharge

Once the project is fully completed, the project manager gets a formal discharge from the sponsor.

The project manager shall verify the accuracy of the project definition or actually delivery of what was agreed on (observing also changes with it). The project manager also shows if the results have not been achieved, how this proceeds, and who is responsible.

All outstanding issues should be assigned to an owner (an owner can have multiple issues assigned but an issue can only be assigned to one owner). Also check that all changes have been completed. It is also crucial to ensure that all products have been delivered to the right parties. Has the business as usual management organization have the right and sufficient knowledge/experience built up in the meantime and sufficient capacity to manage the deliverables during the maintenance phase? In fact, this last point is not the responsibility of the project manager but the business as usual management organization. Likewise, the management organization is responsible for the fulfillment of the service-level agreement, which specifies the times during which services are provided.

Check the spent hours (and total costs) and verify that no changes need to be made and that all invoices (especially to external parties) have been paid. The sponsor must have the final financial overview of the project with estimated costs, actual costs, and profit/loss on the project overview (not applicable in case of a fixed price project, of course). For external projects, the sponsor must be able to see whether the project has yielded the expected profit. Often the “gross profit” (%) is indicated.

The discharge may be granted which should be in the project file (obviously) saved by sending an e-mail.

4.6 Team

It is advisable to arrange a conclusion identical to the “kick-off” of a project. For example, organize a meeting with all stakeholders, including the project manager, where at least the sponsor and project manager are present. This is also the time for giving awards (not only to individuals but also to the team). When much overtime has been spent it is wise to give the team members and their friends a dinner voucher so that “home” is not forgotten, or, for example, a “drink” to allow them to interact in an informal atmosphere.

4.7 Remaining Items

In quite some cases projects are closed with (some) items yet to be finished. This can be due to a lot of reasons.

The project manager should compose a list of these remaining items to be handed over to the organization which will take over these items. This could be the organization that is going to maintain the deliverables.

Items to be arranged and considered:

1. The project will be closed, which means that no more costs can be charged to the project. Who will cover the transfer and other costs associated with finishing the remaining items?
2. The receiving organization needs read access to the project file in order to get information. Write/change access is not advised while the project file still belongs to the organization carrying out the project and should not be modified by people outside the project team.
3. Arrange for team members (including you as project manager) to be available for questions later on and how they can book their time spent.
4. Create a detailed list of remaining items containing, for example,
   1. Description item
   2. Location item within the system (context)
   3. Where to find information (link to information)
   4. Contact person for further details
   5. Known issues and risks
   6. What needs to be done to finish the item

4.8 Transfer to Business as Usual

Once a project has been completed and all deliverables have been completed, the management organization (Business As Usual) takes over the business. Unfortunately, the transition from project to management is often quite a problem for those involved with the project. At the end of the project, people are often tired and the motivation is not always optimal. The budget may have been consumed and one wants to close the project as soon as possible.

When the transfer to the management organization is not started on time, this is asking for trouble, which can still affect the project manager. My experience is that the transfer should be in the project, with close collaboration with the receiving organization as early as possible. Make sure to agree on who bears the costs for the transfer to management because it appears sometimes to be forgotten. Transfer costs on both the project side and the receiving side must be covered.

What is a good time to get involved? My advice is during the project definition phase, especially when it comes to what will be delivered and when. First, the management organization, which needs to indicate what they have to manage in accordance with the requirements agreed with the client (possible deliverables to be produced by the project). Secondly, the management organization needs to plan their capacity in advance as well so they know when they are supposed to be ready to start taking care of the deliverables.

Prevent the project result “being thrown over the wall” to the management organization, which then becomes the owner of all issues. The end users will ultimately be the victims of such a debacle that may arise between the project organization and management organization.

The management organization is rather often based on acceptance criteria, which they have prepared themselves and which are known to the project organization. After formal transfer is arranged to the management organization, the project team is relieved of its duties. If not treated this way you might run into problems. It is possible that not all problems are resolved before the transfer actually takes place.

Pay special attention to transfer licenses and certificates. Especially in certificates of software products or services start and end dates should be included. It will not be the first time that a certificate expires and software therefore no longer functions. Solving such problems may take time because it is not as common, and as a result, much time is lost to find and solve the problem.

4.9 Lessons Learned

At the end of a project it is important to look back, especially to learn which things went well and which did not. This is not for just the project manager but also for all those involved. I find it is critical to share knowledge and experience to help prevent the same mistakes again. For example, it is also crucial to share what has gone well because we can learn from others here too.

The sharing of knowledge and experience, both through presentations and storing in a database, can help too. There are special “tools” available in the market regarding knowledge management.

Think of sharing not only the “hard” facts but also the “soft” aspects. For example, how was the collaboration among team members, how were conflicts resolved, how was the atmosphere in the team, and was good communication kept both within the project team and outside with people?