Project Termination

Project termination (or close-out) is the last stage of managing the project, and occurs after the implementation phase has ended. Acceptance testing has been carried out, and the project deliverables have been handed over to the client. The project team has been disbanded and unused resources have been disposed of as appropriate. All outstanding bills have been passed for payment, and the final invoices for work carried out have been issued. The main purpose of the close-out stage is to evaluate how well you performed, and to learn lessons for the future. A final project status report is prepared that should contain a summary of changes to the project scope (if any), and show how actual completion dates for project milestones and costs accrued compare with the final version of the project schedule and budget. All significant variances from the project baseline should be explained here. A review is then undertaken with the client and other project stakeholders, during which the project outcomes are evaluated against the project's stated aims and objectives. The results of the review are recorded in a close-out report. The questions the stakeholders should be asked will vary depending on the nature of the project, but will normally include questions such as:

Projects fail for many reasons, some of which are outside the control of the project manager. External factors that can affect the outcome include a changing commercial environment, lack of support from senior management (including the provision of adequate resources), or lack of co-operation from the project client. Internal factors include inadequate expertise within the project team, a lack of planning and management, poorly defined project objectives, and a failure to communicate effectively. However, despite the fact that a project may not have fulfilled the expectations of its stakeholders, future projects can benefit from the lessons learned from a post-project appraisal process. It is important to learn lessons from successful aspects of the project as well as from mistakes. In that way, not only can the same mistakes be avoided in future, but good practice can be implemented in future projects.

The close-out report will be the final report for the project. It will include an executive summary, the final status report, and an analysis of lessons learned that includes recommendations for improvements to be implemented in the handling of future projects. The close-out report will be made available to future project managers so that the lessons learned and the recommendations that are derived from them can be utilised. The project documentation itself will also be archived for future reference, and if it contains accurate information that has been kept up to date throughout the project it will provide a valuable source of historical data. When evaluating problems that have occurred, it is important to identify the root cause of the problem and come up with strategies for ensuring that it does not occur in future. The avoidance of certain types of problem cannot always be guaranteed (changes in scope will often occur, for example, but they can rarely be predicted). Even so, it may be possible to identify a means of detecting problems earlier in the project management process so that the negative consequences can be minimised.

The importance of the availability of up to date, complete and accurate project data to the close-out process cannot be overstated. The analysis of problems and the derivation of solutions to those problems (as well as the ability to recognise and document good practice) will only be meaningful if based on a full and accurate record of what occurred during the course of the project. The memories that individual project team members and other stakeholders have of events that occurred will be distorted by time and personal bias, and therefore cannot be relied upon. It is also to some extent unfair to ask project team members to submit statements that appear critical of colleagues, or show themselves in a bad light, particularly if such statements would be made in the context of a project team de-briefing and could possibly cause some embarrassment. The idea is to highlight problems and suggest solutions, rather than to apportion blame. The project manager may well be called upon to assess and report upon the performance of individual project team members, but this assessment will usually take the form of a confidential written report that is seen only by the line manager of the individual concerned.

If the project has been a success, there will be cause for some kind of celebration. This could take many forms, but represents an opportunity to thank the project team for a job well done, and to offer then a sense of closure. Even if the project has not been a complete success, it is important to thank the members of the project team for their efforts, since they have no doubt all worked hard. Where performance merits it, either the team as a whole or individual team members should be rewarded accordingly. Appreciation for a job well done may take the form of a financial reward or something less tangible. Sometimes, for some people, a sense of being truly appreciated is just as important as money. Recognition of a valuable contribution made is often sufficient incentive to ensure that an individual’s future performance will be just as good as before, if not better.