It is important to ensure that a project is properly closed for two reasons. Firstly, there is a tendency for projects to drift on and become, or develop into, other projects. Secondly, it is important to ensure that the work of the project team is acknowledged and that the lessons to be learned from the project are formally investigated and recorded for use on the next project.

Avoiding drift

The tendency for projects to run on into the sand must be avoided. It leaves everyone feeling disatisfied and unrewarded for the work (often extra work) that they have done. Often, nobody checks that all the projectís objectives have been completed or exceeded. They may notice that the project is under spent and spend the budget on something else or the project may just drift into over expenditure and then be considered an unsuccessful project.

By carefully monitoring and maintaining the Project Definition and the Project Plan the project will not only be under control but may be officially closed at the end. It is at the end of a project that we see the benefits of tight control. The time and effort spent ensuring that any extra work was specified, budgeted, resourced and fully authorised will be rewarded by an Ďon time-on budgetí project report. Similarly, the voices of dissatisfaction can be dispelled (or at least reduced to silence) when the project report reveals that the project delivered all that it was defined to do, but not those elements that were authorised to be removed from the project so that it could deliver its product/service/result by a defined date.

Have a closing event

Always have a closing event to formally round off the project. A party, a dinner, a night in the pub, an outing to the theatre or Disneyland. Some kind of reward for work well done. Ensure some money is put into the budget for this event.

Even if the project was unsuccessful, over-ran and brought shame to those who were responsible for it (rare, on your projects, Iím sure) it should be formally closed and the team, who worked hard for its success, rewarded with a wake for the projectís passing. Why reward failure? Because you are not rewarding failure, you are rewarding effort. There is no universal cure for cancer but there are many excellent drugs that resulted from projects to find a cure. What scientists strive to do is learn the lessons for the next project Ė for the next step forward. That is what we must do as organisations, as project teams and as people.

Learning the lessons

The last formal piece of work the project team should undertake is the Project Review. This event should be a formal review of what went well with the project and what went less well. It should include all aspects of the project; objectives review, performance criteria, financial criteria, resource utilisation, slips and gains of time, quality of work, adherence to the project definition and plan. Every aspect you can think of and the ones that will only arise from a group discussion.

Allow the team time to reflect on and prepare for the review. And ensure there is plenty of time for group discussion. Keep the meeting positive, donít overly dwell on negatives but ensure that the positive lessons are brought out from each negative event. Doing better next time is the theme of the review rather than delving into the minute detailed reasons for each perceived failure. Start with what we did right and were pleased with and them move on to what went less well (or was a total unmitigated disaster).

Circulate a Project Review questionnaire before the meeting to focus the teamís thoughts on the subject. An example of a Project Review questionnaire is available here.

The outcomes from the Project Review should be incorporated in a Project Report. Unless your organisation demands otherwise, keep this short and succinct. Ensure it provides the measures of the relative success (time, budget, performance, delivery) but also very clearly the lessons learnt. It is best to deal with unpleasant truths with care. For example, if the project team had little or no management support (assuming they positively asked for it Ė their own fault if they did not) then it may be best to report that with the benefit of hindsight it would be better to have had a formal management review of the project at its key stages. It always is anyway, but in some organisations you may have to push hard to get them.

The last thing to do is to ensure that a memo is sent to the finance department to ensure that they are aware that the project is closed. This so that they do not continue booking invoices to the projectís account in order to avoid, "But we always book invoices from that supplier to that project. You did not tell us it was closed". Even if you invite them to the closing event you cannot assume they will close the account. You should always invite the project accountant and invoice clerk to the closing event because they are always left out (unless itís a new accounting system project) and you will need their support for the next project. They also serve who only count the beans. Creative accountancy is a bonus.