PRINCE2 - Controls part 6
of the Cabinet Office under delegated authority from the Controller of HMSO.
Controlled close
The Project Board controls the closure of a project by ensuring:
- All agreed products have been delivered and accepted
- Arrangements are in place, as necessary, to support the product throughout its useful life
- Any statistics or lessons learned are passed on to the relevant body
- A plan has been made that enables a check on the achievement of the benefits identified in the Business Case
Acceptance of project completion by the Project Board must be recorded, documented and filed.
Any qualifications to the above list can be added to the document.
The following information is generated at project closure which leads to control actions by the Project Board.
Project closure notification
This may proceed with the Project Manager presenting a ‘project closure recommendation’ to the Project Board for their approval.
If accepted it is then released as the ‘project closure notification’ to all interested parties.
For example, those providing resource, equipment or services to the project.
In practice, the two documents referred to here may be one and the same.
Lessons Learned Report
This derives from the Lessons Learned Log at the end of the project.
It will cover management and specialist processes, techniques and tools that either worked well or did not.
A Product Description is given in file ‘Lessons learned report.doc’ in the product package.
An intermediate report can be prepared sooner if lessons are such they would be immediately useful to other areas or projects.
Follow-on Action Recommendations
Even at the closure (approved by the Project Board) of a project there may be a number of actions not yet carried out.
In addition, there may be risks that are associated with the product in operation.
The aim of the Follow-on Action Recommendations is to identify all of these items. This will allow the Project Board to allocate a person or group to manage any actions required once the project has finished.
End Project Report
This is similar to the End Stage Report but covers the entire project.
The Product Description is given in file ‘End project report.doc’ in the product package.
It will review the achievement of the objectives laid out in the Project Initiation Document.
The report focuses on the performance of the project management team to achieve budgets and target dates.
As far as possible the benefits in the Business Case are reviewed.
Any modifications after the Project Initiation Document was agreed are identified and their impact on the Project Plan, Business Case and risks are assessed.
The report will provide statistics on Project Issues and their impact, plus statistics on the quality work carried out.
If the project is part of a programme a copy of the report will be passed upwards together with any other information needed as identified in the Communication Plan.
Copies of the End Project Report can be circulated (according to the Communication Plan) once the Project Board has approved it.
Post-Project Review Plan
It reviews the benefits achieved by the project’s products after project closure.
At the project closure a plan is agreed as to when and how these benefits will be measured.
Many benefits will not come to light until the product has been in use for a period of time.
Any corrective work identified would be carried out during product use and maintenance.
This may extend to the training of personnel and not the product itself.
The Executive must take responsibility for the implementation of the Post-Project Review Plan.
The Project Board must ensure the existence of the Post-Project Review Plan.
The Product Description is given in file ‘Post-project review plan.doc’ in the product package.
Stages
These are sections of the project with management decision points.
It is a subset of the project and is the element being managed by the Project Manager at any one time on behalf of the Project Board.
The number of stages will depend on the needs of the project but the existence of stages is mandatory for good control.
In PRINCE2® these are often described as ‘management stages’ which allows the differentiation from the use of ‘stages’ and ‘phases’ which may exist in some specific project environments.
They provide the following:
Review and decision pointsThere is a need for the Project Board to regularly review the project direction and make decisions on an ongoing basis.
These decision points are best approached by the use of stages.
They are carried out as part of the process Authorising a Stage of Exception Plan (DP3).
The project benefits are:
- There is a controlled ‘firebreak’ for the Project Board rather than letting the project run on unmanaged
- Ensures that key decisions are made prior to the implementation of detailed work. This may include commitment of resource such as capital investment, the impact of major risks or clarification of previously unknown or ill understood strategy or products
- Calculating the impact of external influence, for example, legal changes
- Reviewing a risky project when new information appears concerning those risks
‘Peer reviews’ are specific reviews of a project or any of its products where personnel from within the organisation and / or from other organisations carry out an independent assessment of the project. They can be done at any point in the project and their aim is to introduce a fresh perspective and help share information across projects.
‘Gate reviews’ are formal end stage assessments where external scrutiny is applied to the assessment of the project and recommendations are passed on to the Project Board for the continuation (or not) of the project.
Planning horizonsThe Stage Plan will be prepared with a greater level of accuracy compared to the Project Plan.
The latter will be less accurate owing to the increased future nature of events.
Stages allow extra focus on nearer events which will bring greater accuracy.
All PRINCE2 projects should have at least 2 stages.
The initiation stage is mandatory and could be extremely short.
Hence, for a very short project it might consist only of an initiation stage and a second stage containing the rest of the activities.
Most projects will require more stages to allow for the correct level of planning and control.
Management versus technical stages
One technique for introducing stages recognises the need for techniques used or the product created.
This leads to stages such as design, build and implementation. These are technical stages and are separate from the ‘management stages’.
These are typified by the need for specialist skills.
Management stagesThese are typified by the commit resources and the authority to spend.
The technical and management stage may coincide (and may not). This would occur when a management decision is waiting on the output from a technical stage, for example, awaiting design options.
There may be more than one technical stage in a management stage.
For a risky project (for example containing technical innovation) the technical stage may be divided up into more than one management stage for better control.
PRINCE2 concentrates on management stages as they form the basis of planning and control processes throughout the method.
If this is not the case, the project could be driven by specialist needs rather than that of the customer.
If technical stages run over management stages it is useful to break these down so that they coincide with the management stages.
How to define stages
This requires a balance:
- How far ahead in the project is it sensible to plan?
- Where do the key decision point in the project need to be?
- How much risk is in the project?
- Are there too many small stages versus big ones?
The Project Manager will have to reconcile any Stage Plans with relevant Team Plans.
How to use stages
They are used to make decisions concerning the continuation or not of the project.
They are managed as part of the process Managing Stage Boundaries (SB) and Authorising a Stage or Exception Plan (DP3).
Has the previous stage been completed?
This may not be easy to answer if some specialist work bridges management stages and it is unclear if the work is under control.
The product based management of PRINCE2 will help here.
Even specialist work will have identified products with timelines for their creation.
In this way the Project Manager can ascertain if all products that should be complete are indeed complete.
The stage process is a very good way of calling a halt while risks are reviewed by the Project Board for risky projects.
Managing Successful Projects with PRINCE2 - 2005 edition
Managing successful Projects with PRINCE2 – 2009 edition
Directing Projects with PRINCE2.
plus:
The Complete Project Management package.
And much more besides - at a fantastic price.