PRINCE 2

PRINCE (PRojects IN Controlled Environments) is a process-based project management methodology first established in 1989 by the Central Computer and Telecommunications Agency (CCTA), now known as the Office of Government Commerce (OGC). Now a de facto standard for project management, PRINCE 2 was published in 1996, and is used extensively both by the UK Government and many organisations in the private sector. Although copyright is retained by the Crown, PRINCE 2 is a public domain, non-proprietary standard that offers best practice guidance on project management. The PRINCE 2 methodology has undergone a fundamental revision, the result of which was published in June 2009 as "PRINCE2:2009". The intention of the revision appears to have been to simplify the methodology, to address known issues, to dispel some common and widely-held misconceptions, and to better meet the requirements of a rapidly changing and volatile business environment. Two manuals have been published that incorporate the changes introduced by the 2009 update. These are "Managing Successful Projects Using PRINCE2 - 2009 Edition" and "Directing Successful Projects Using PRINCE2 - 2009 Edition". Practitioner accreditation is acquired by passing both a Foundation exam and a Practitioner exam, both of which are based on material in the "Managing Successful Projects Using PRINCE2 - 2009 Edition" manual. Practitioners have to re-take the Practitioner exam every five years to maintain their accreditation.

PRINCE2 Principles

PRINCE2 embodies seven principles based on the following themes:

Business case - the business case provides the justification for undertaking a project, and is based on the cost of development weighed against the anticipated benefits. The business case should show that the proposed solution meets a valid business need, is financially viable, and can be achieved in the time allowed. It should, among other things, define the scope and objectives of the project. The level of detail provided will reflect the size and complexity of the project being undertaken, but the initial version should contain sufficient information to allow the project sponsors to make a decision as to whether or not the project is viable. For large projects involving a considerable financial investment, the business case may include a high-level cost benefit analysis of the available options. If the project goes ahead, the business case will be continuously updated to reflect actual costs incurred and any changes in project scope. The updated information will be used to assess the continued viability of the project, and will inform subsequent decision making. Once the project has been completed, it will be used to assess the degree to which the project has achieved its objectives.

Organisation - each project must have a clearly defined management structure within which roles and responsibilities are identified, and which provides the basis for project governance. The makeup of the management structure will reflect the size, complexity and cost of the project. The key roles within the management structure include:

Quality - a quality review technique ensures that the outputs from the project are of the required standard and meet all of the defined quality criteria. Quality review meetings identify problems, but do not attempt to identify solutions.

Plans - the project plan defines the project's deliverables and specifies the activities that must be undertaken in order to develop them. The activities will be organised into a logical sequence of events, taking into account any task dependencies. Estimates will be made of the duration of each activity and the resources that must be allocated to it, and a schedule of work will be produced (this usually includes the production of a Gantt chart and activity network diagrams using CPM or PERT). The plan will typically specify the pre-requisites for success, list the resources required, and identify areas of risk or uncertainty. It will also include a detailed financial budget for the project, and will identify significant project milestones.

Risk - to manage and mitigate a risk you must identify it, assess the probability of it occurring, and estimate the impact it would have on the project. Good project management controls the project's exposure to risk in order to minimise the possibility of project failure. The Project Manager should regularly review the project's exposure to risk and the measures being taken to reduce or mitigate it. The SRO and (if applicable) the Project Board should actively engage in the risk management process to ensure that risks are identified by the project team and dealt with at an appropriate level.

Change - issues often arise that may alter project parameters, and may include changes to the scope, objectives or completion date of the project. Minor changes are usually dealt with by the project manager, while more far-reaching changes may need to be dealt with at a higher level. Once a change has been requested its impact on the project must be assessed and a decision taken as to whether the change should be made. The change will be given a priority rating based upon whether it is categorised as essential, merely desirable, or cosmetic in nature. This will influence the decision whether or not to implement the change.

Progress - the project plan is a baseline against which progress can be measured. Any deviation from the plan can be identified and corrective action taken if necessary. The Project Manager will allocate work to the project team in accordance with the plan, monitor progress to ensure that deliverables meet specified requirements, and monitor costs and resource usage. The Project Manager has the authority to handle minor deviations from the project plan. For more serious deviations, the SRO and Project Board will need to be involved.

PRINCE2 Processes

PRINCE2 provides a methodology for managing projects within a clearly defined framework. It describes procedures to coordinate people and activities, how to plan and supervise the project, and what measures should be applied when things do not go as planned. PRINCE2 2009 specifies some forty separate project management activities, which are organised into seven processes. The processes represent a step-by-step progression through the project lifecycle (see the PRICE2 process model diagram below), from starting the project to terminating it. The seven processes are listed below.


The PRINCE2 Process Model

The PRINCE2 Process Model


Starting up a project - in this process the need for the project is identified and a Business Case is developed. Other activities include the appointment of a Project Manager and if appropriate setting up a Project Board. A Project Brief is prepared that outlines the purpose of the project and its terms of reference including the objectives of the project, the business benefits that will be realised, and the scope of the project. The project brief will form the basis of an agreement between the SRO and the project manager as to what the project is to achieve and how it will proceed. Once the project brief has been completed it will form the basis for the next stage, and will also inform a decision by the SRO and the Project Board as to whether to proceed to the next stage.

Directing a project - this is a process that continues for the duration of the project, and defines how the Project Board (including the SRO) will oversee and control the project. The Project Board operates on the basis of management by exception in the sense that they will not normally be involved in operational decisions unless the project has encountered problems or requires change management that is beyond the remit of the Project Manager. The board will need to authorise the transition from one stage of a project to the next, however, and must be kept informed of progress at regular intervals by means of Highlight Reports.

Initiating a project - in this process the project brief is extended to form a Project Initiation Document (PID). The PID builds on the existing business case and provides a detailed project proposal against which success can be measured, and provides a more accurate estimate of the costs and benefits of the project. It provides an updated assessment of the resources required, the risks involved, and the amount of time needed for successful project completion. The PID also outlines the procedures to be adopted for quality assurance, and defines the roles and responsibilities of each member of the project team. A project plan is created that includes an activity chart of some kind (e.g. a Gantt chart), and a Governance plan is prepared that specifies how the project will be monitored and controlled. The PID must be approved by the SRO and Project Board before the project may proceed to the next stage.

Managing a stage boundary - in order to maintain control over the project's progress, it is necessary to break it down into manageable stages and put in place a process for monitoring and managing progress and resource usage. The Project Manager will identify stage boundaries by calculating how far ahead he can realistically plan daily activities in sufficient detail to retain the required measure of control. The detailed planning for the next stage will therefore often occur towards the end of the current stage, when the information required for planning becomes available.

Controlling a stage - at all key milestones during project implementation (or more frequently should circumstances demand it), the project manager will provide the SRO and Project Board with Highlight Reports containing information about the project's current status. A high level decision will then be taken on whether to proceed to the next stage based on factors such as whether or not the deliverables produced to date are of the required quality, the need for the project has not changed, and the project is still viable. Frequent Checkpoint reports will be produced for the Project Manager by project team leaders. The reports provide updated information on progress and the use of resources, and allow the Project Manager to respond quickly to minor deviations from the project plan as well as providing information that will be used in Highlight Reports. The frequency of Checkpoint reports will vary, depending on the current level of activity. During periods of intense activity, they could be produced daily.

Managing product delivery - the purpose of this process is to make sure that deliverables are produced as specified and meet the agreed quality criteria. It requires that the work carried out by the project team is authorised and agreed, and that team members are aware of the expected cost and timescales involved. The Project Manager must be updated with progress reports at regular intervals to ensure that adequate controls are maintained.

Closing a project - closure occurs either as planned or early if the reasons for implementing the project are deemed to be no longer valid. As the project moves towards its conclusion, the Project Manager will evaluate the project against the PID and communicate his or her findings to the SRO and the Project Board in a report, to enable them to formally close the project. The SRO and the Project Board must satisfy themselves that the work is complete and in accordance with the PID, and that all of the necessary information has been passed to those responsible for the use, operation and maintenance of the deliverables. A Benefits Realisation Plan should be drawn up to facilitate a post-project review. Project management documentation will be archived for future reference, the SRO and the Project Board will confirm the closure of the project, and the project team will be disbanded.

Realising the benefits

The Benefits Realisation Plan provides the basis for a post-project review that that will evaluate project outcomes and determine to what degree the benefits have been achieved. The plan defines the anticipated benefits and identifies the benchmarks against which they will be measured. It will also identify the stakeholders who can expect to reap the benefits, and a timescale within which the benefits should be realised. The SRO accepts ownership of the Benefits Realisation Plan when the project is formally closed, and will be responsible for ensuring that it is carried out and any findings acted upon.