Closure process

General

The goals of this process are to:

• close a project or programme that has delivered all its outputs;
• close a project or programme that is no longer justifiable;
• review the management of the work and learn lessons.

Note that the first goal does not identify closure as being when the objectives are complete. Objectives may be described as outputs, outcomes or benefits and these are all achieved at different times. Closure is principally concerned with a temporary organisation handing over responsibility for its objectives and disbanding. Where that occurs in the life cycle will depend on how the project or programme was constituted in the first place.

For example, the realisation of benefits is usually something that is entrusted to business-as-usual and does not need the project or programme organisation to remain in place. A project or programme may be constituted to end when the final output is delivered; when the change required to realise benefits is concluded or when the benefits contained in the business case have been achieved. This is one of the choices that will have been made earlier in the life cycle.

The second reason for closure is referred to as ‘premature closure’ since it occurs earlier than intended. The obvious place for this to occur is at a boundary where the business case is updated and found to be no longer viable, achievable or desirable. That is not to say that the project or programme can only be closed at a boundary. On-going control of performance during the delivery phase may reveal serious issues which cannot be satisfactorily resolved. When the issue is escalated to the sponsor the decision may be to prematurely close the project or programme.

 

Click on the components of the diagram for more detail

 

Prepare for closure

Closing a project or programme in a controlled way can be an extensive process and needs to be planned in advance. It can be all too easy to focus purely on achieving objectives to the detriment of how they will be handed over, how the organisation will be disbanded and how the administrative loose ends will be tied up.

When closure is in sight, effort must be invested in updating delivery documentation with the closure process in mind. Are there risks specifically associated with the closure; how will stakeholders react and how should they be kept informed; what contractual matters need to be resolved; how will asset disposal be managed?

 

Back to diagram

 

Handover

Who is handing over what and to whom will depend on the context. A contractor may be handing over outputs to a client; a project may be handing over to a programme; a programme may be handing benefits realisation over to business-as-usual. In the case of a prematurely closed project or programme, outputs that can be salvaged may be handing over to a newly constituted residual project or programme.

Handover can have practical and legal aspects. First and foremost is the need for the receiving organisation to be clear what it is taking over and satisfy itself that everything being handed over is as described and fit for purpose. Conversely there is a responsibility on the delivering organisation to provide everything necessary for the hand over to take place successfully.

Hand over often constitutes a legal transfer of ownership and this brings additional factors into play ranging from ownership of a physical asset to transfer of employment contracts or other legal responsibilities.

The administrative side of hand over must not be overlooked. The project or programme organisation will have records of quality control and configuration management associated with physical assets which should be handed over as well as the assets themselves.

It is not always practical to wait until all deliverables are 100% complete before handing over and de-mobilising the project or programme organisation. Sometimes deliverables are handed over with some follow-on actions still to be done. One of the outputs of this activity will be the follow-on actions report, which lists any outstanding items.

 

Back to diagram

 

Review

The second activity in the identification process is ‘review previous lessons’, which begs the question “where do these lessons come from?”

This activity conducts a formal review of the governance and delivery of the project or programme. A key input is the lessons log which will be used to distil lessons learned that will be included in an end project report or end programme report.

 

Back to diagram

 

Demobilise

During mobilisation a project or programme infrastructure will be assembled including resources as diverse as premises, software and people. Demobilisation is simply the opposite of that activity.

Physical assets such as buildings, plant and machinery may have been purchased, rented or hired with a subsequent need to sell, redeploy or terminate agreements. Human resources may be contracted or employed. Contract employment may simply require termination of contracts but redeployment of internal staff needs greater involvement from the project or programme team.

Many projects and programmes are closed before all the benefits in the business case have been realised. This means that while the project and programme managers may have moved on to new ventures, the business change managers (BCMs) still have work to do to complete change in business units. Instead of reporting to a project or programme manager, the BCMs will report directly to the sponsor until the change is completed.

The sponsor will be the ‘last person standing’. Where the scope includes benefits, the role of the sponsor does not formally come to a conclusion until a benefits review concludes that the business case has been achieved; achieved to the best degree possible or will be achieved without further intervention.

 

Back to diagram

Projects and programmes

The principles of closure do not vary with complexity. As complexity increases there is simply more to do to hand over products, demobilise and close contracts.

 

Back to top