About us
Useful Links
PRINCE2 Exam Guide
PRINCE2 Master Class
PRINCE2 Structure
Handling Issues
Management by Exception
Project Board Guidance
Tailoring PRINCE2

Management products will be mentioned in the following sections – it may be an idea to refer to these in Appendix A of the PRINCE2 manual as you read through. All Management products are shown in italic.


The first port of call in understanding PRINCE2 lies in its structure, since this dictates the sequence, iteration and nature of project management activities via the Process Model and the PRINCE2 Themes. It also allows us to see how important principles such as Management by Exception are embedded within the method.


The Process Model overall has 7 separate but highly interdependent processes. The colour coding in the picture above provides a convenient way of breaking the model down into (mentally) manageable sections.

Start-up & Initiation (SU & IP - Yellow)

The preparation phase of a PRINCE2 project. Only Management products will be created during these 2 Processes and they represent what the business, the Project Board, the PM and all other interested parties will need to know during the execution of the project. Everything that is needed to define the basic conduct of the project will at least begin to be documented here. This is done by considering the 7 PRINCE2 Themes, which are all addressed within these 2 processes:

PRINCE2 Themes addressed during Starting up a Project (SU)


Business Case (create Outline Business Case);

Risk (identify major risks);

Quality (understand Customer Quality Expectations & Acceptance Criteria);

PRINCE2 Themes addressed during Initiating a Project (IP)

Quality (agree Customer Quality Expectations & Acceptance Criteria; document within the Quality Management Strategy);

Change (define change control approach within the above and a supporting Configuration Management Strategy);

Organisation (define the Communication Management Strategy)

Plans/Progress (create Project Plan & Stage Plan, define controls);

Business Case (refine);

Risk (create Risk Management Strategy and Risk Register);

Starting up a Project

SU is triggered by the Project Mandate which should be completed by Corporate or Programme Management (note this is NOT the Project Manager’s (PM) responsibility if such a document does not exist – there will simply be more work for the PM to do to create the Project Brief ). Clearly, the presence of a Project Mandate means that the business (the organisation) has decided that this project has now become the highest priority to perform.

It may well be that a Feasibility Study was carried out (possibly months ago) to determine the way forward and that the way in which the project will be conducted was decided at that point. For example, it may have been decided to carry out all the work in-house, or to procure external sub-contractors to carry out the work, or even to buy in a ready made product. If such a decision has been made, then this reduces the amount of work required of the PM defining/selecting a viable project approach.

Of course, one of the major outputs of SU is a Project Management Team structure, possibly including a diagram of the structure and Job Descriptions for each of the roles.

In essence, SU is about assembling sufficient information for the new Project Board (PB) to make their first key decision – “Do we want to begin spending project budget to create a more detailed definition of this project”? In other words – “Shall we invest in the Project Initiation Documenation”? (PID). This decision is made when the PM presents the products of SU to the board after SU has finished, when the PB effectively perform their first sub-process of PRINCE2 - Authorise Initiation. It is a key decision in the sense that the PB are only committing to the development of a PID and not to the commencement of the project proper (ie the development of specialist products).

 Key Outputs

Team Structure; Project Brief; Project Approach; Outline Business Case; Stage Plan for Initiating a Project.

Initiating a Project

During this Process we are still essentially preparing for the project by 
refining and expanding management products of the project which we have already made a start on during SU. Amongst these are:

agree Customer Quality Expectations & Acceptance Criteria
refine the Business Case;
refine and expand the Risk Register);

However we will also need to create new products;

define Risk Management Strategy;

define Quality Management Strategy;
Change Control (define approach within Quality Management Strategy);
define Configuration Management Strategy;

define Communication Management Strategy;
create Project Plan & Stage Plan (for 1st Stage of specialist work);
define Project Controls (becomes a section of the PID).

The structure and role of the Quality Management Strategy and the linkages between this and Change Control and Configuration Management are dealt with in a separate Master Class, "Quality in PRINCE2" (see menu bar on the left).

Other than this, IP sees the first use (in anger) of the Plans Theme to develop both the Project Plan  and the first Stage Plan. Since Planning always has an impact on both the Business Case and the project risks (Risk Register), IP ensures that these 2 products are kept up to date with the latest versions of the plans. Our increased knowledge of the plan timings, deadlines and resourcing (costs) leads us to updating the costs and benefits of the project’s Business Case, whilst the same factors also potentially introduce risk into the project (or have an effect on risks we have already identified).

Any plan produced in a project needs to be delivered as planned, and therefore there needs to be a control function which can bring errant plans back onto track in the event that they begin to diverge from the planned path. The process “Set up the project controls” looks at this area and prompts us to think about how the PB and PM will exercise control over the project (not forgetting Corporate or Programme Management who set overall project tolerances, an important control from their point of view). 

In reality, control is exercised by someone making a decision which leads to change to the current plan. It would, therefore, be reasonable to assume that only (sub) processes where decisions are made can be controls (eg within Directing a Project). PRINCE2, however, considers the monitoring method which detects the deviation to also be a control. For instance, a Highlight Report is classed as a control because it contains the information on which the PB bases decisions to suggest changes.

It is important to consider controls which are available to the different levels of the project management team. For example, Stages and Stage tolerances are controls of the PB (how the PB give direction to the PM, and limits to the work being undertaken). A Work Package is a control of the PM (how the PM controls the start, execution and delivery of a completed piece of work via the Team Manager).

The Communication Management Strategy is worth a special mention in providing some aspect of control over the expectations of the stakeholders in the project.

See the Controls Masterclass for a fuller treatment of this vital area (menu bar on the left).

Finally, the sub-process “ Assemble the Project Initiation Documentation” completes the work of the first PRINCE2 Stage by gathering together the various other management products available so far, and by creating a Stage Plan for the next Stage of work. These are presented to the PB in their second sub-process “Authorise a Project” where a decision is made to continue or not

IP Key Outputs

Project Initiation Documenationt; Stage Plan

Controlled Progress (CS, MP & SB - Blue)

The day-to-day conduct of a PRINCE2 project. This area is mostly the responsibility of the PM, but with decisions to continue from Stage to Stage made by the PB.

Specialist products are now being created/delivered by Team Managers and this needs to be monitored and controlled from the PM’s perspective, whilst the overall Stage progress needs to be monitored and controlled by the PB (via Highlight Report, Exception Report, & End-Stage Report).

Controlling a Stage (CS)  

There are 3 main areas of interest within CS:

1. Authorising Team Managers to begin work (via a Work Package), controlling that work via Checkpoint Reports and exception reporting (from TM to PM) and receiving the completed, signed-off Work Package back.

2. Handling issues (largely un-planned events) as they arise.

3. Maintaining overall information on the Stage progress to date to enable Highlight Reporting (PM to PB).

 Managing Product Delivery (MP)

The first area triggers the Managing Product Delivery process MP, as the PM and TM negotiate the Work Package.

Once the TM has accepted the Work Package, it is now executed and the specified specialist product(s) is built/created/assembled. The TM must also make sure that the finished product is Quality Checked against its specification (the product’s Product Description), although this will be carried out by the resource specified on the Stage Plan (a Stage Plan which includes the Quality activities, methods and resources is now called the Stage Quality Plan). The PRINCE2 recommended quality checking method is the Quality Review technique.

During execution the TM will report back to the PM via Checkpoint Reports to keep the PM abreast of progress and problems. Any tolerance breaches at the Work Package level will be reported separately to the PM via a mechanism defined in the Work Package itself, and a decision about what to do next will be taken, in the first instance, by the PM.

Finally the TM will ensure that the finished product is now placed under Configuration Management and that the Quality Register is updated to reflect the finished status of the product(s). At this point the signed-off Work Package can be returned to the PM

MP Key Outputs

Checkpoint Report; completed Work Packages; updated Quality Register; Quality Review results; products under Configuration Management.

Controlling a Stage (CS) (1)

The PM maintains this handing out of work to the TMs according to the Stage Plan he or she is executing, ensuring that the schedule is followed as closely as possible. Note that, as far as PRINCE2 is concerned, the TM(s) can be either internal or external to the Customer organisation – it makes no difference to the way in which they should be managed.

This activity continues until all the work of the Stage is (nearly) complete. At this point, we need to get ready for the next Stage (if there is one), or project closure (if there isn’t another Stage to execute).

If another Stage exists, then a Stage Plan will be needed, and an End Stage Report must be created. The main process Managing a Stage Boundary is responsible for generating these 2 products.

Managing a Stage Boundary (SB) 

SB is responsible for enabling a smooth transition from one Stage to the next via a PB decision to continue (or terminate) taken within sub-process “Authorise a Stage or Exception Plan”. To enable this decision, the PB needs detailed information about the achievements against objectives of the previous Stage and also the next Stage Plan, to assess whether the upcoming Stage looks sensible in terms of timings/deadlines and resourcing.

Part of the content of the End Stage Report deals with a review of how the Business Case has been affected by approved changes and also how the project’s exposure to risk has been modified during the Stage.

All this information is taken into account by the PB during an End Stage Assessment. The outcome of this assessment will either be authorisation to continue to the next Stage, or instructions to proceed to Closing a Project (CP) (which therefore represents premature closure).

The same PB process also deals with the situation where a Stage has ended prematurely because of an exception condition (a potential breach of one or more of the Stage tolerances). Under these circumstances an Exception Report will have been generated by the PM and this will have been reviewed by the PB (within “Give Ad-Hoc Direction”). If the PM’s recommendations look feasible, the PB may ask the PM to create an Exception Plan. Creation of this plan follows the same general procedures as described above for the execution of SB (including updating the Business Case/Risks and producing an End Stage Report).

SB Key Outputs

Stage Plan or Exception Plan; End Stage Report; updated Business Case; updated Risk Register.

Controlling a Stage (CS) (2)

The second major area covered by CS is the handling of issues (ie largely unplanned events which have an impact on some aspect of the project and which may need to be resolved).

This area is the subject of a separate Master Class, where a more detailed view and discussion is available. See the menu bar on the left.

At this point it is sufficient to say that handling issues within a PRINCE2 project puts into practice the Change Control approach which will have been defined as part of creating the Quality Management Strategy during IP.

Controlling a Stage (CS) (3)

The third area of interest within CS is the reporting area. The PM must generate Highlight Reports to be sent to the PB at the frequency which they stipulate. The information to create this report is assembled within the sub-process “Review the stage status”. This sub-process is itself fed by another sub-process “Review Work Package status”, where all Checkpoint Reports from TMs are received. In addition to this progress information, the Highlight Report must also update the PB on the project’s exposure to risks and issues during the reporting period and must also summarise the quality activities undertaken during the period.

See also CS (2) for Exception Report.

CS Key Outputs

Highlight Report; Exception Report

Project Closure (CP - Pink)

This main process is reached either because the final Stage is nearing completion or because the project is being prematurely terminated by the PB. Note that it is NOT necessary to complete this process if the project is still within either SU or IP when the termination instruction is issued by the PB.

The main concern here is to ensure that all project objectives have been achieved, something the PB will be at great pains to have evidence of (remember the PB are ACCOUNTABLE for the successful delivery of the project). This evidence is primarily provided (by the PM) via 3 reports:

End Project Report
Lessons Learned
Follow on Action Recommendations
The End Project Report follows the same general lines as an End Stage Report, and the Lessons Learned report is self-explanatory.

The Follow on Action Recommendations report picks up on any “unfinished business” from the project. For instance, risks which remain open into the operational life of the project products will require recommendations for dealing with them in that environment. The same can be said for any issues in the Issue Register which remained unaddressed (they may have received concessions, or simply still be “pending”, or have been rejected).

It is also advisable here to create a Product Status Account (as an attachment to the End Project Report) to prove to the PB that all products are indeed “completed”. This report is nowadays usually generated by the Configuration Management software in use and simply shows that all products have actually reached the final point in their lifecycles – signed off.

Administratively, CP must also ensure that project documentation is archived and that all stakeholders are notified of the imminent closure of the project (particularly Line Managers of project personnel). A BenefitsReview Plan will also be necessary to enable the Project Executive to perform this review at an appropriate point after the project finishes.

The final decision to close the project and issue the Project Closure Notification rests with the PB and is taken in the sub-process “Authorise Project Closure” (a final major control of the PB).

CP Key Outputs

End Project Report; Lessons Learned; Follow on Action Recommendations; Benefits Review Plan

Directing a Project (DP - Beige)

These are the Project Board processes and all represent significant control points for the PB. Remember that the PB is responsible for the project, with the PM acting under its delegation.

The PB has 3 “authorising” sub-processes: 

To allow the project to progress from SU to IP  - Authorise Initiation;
To allow the project to progress from IP to CS (1st time) - Authorise the project;
To allow the project to progress from Stage to Stage - Authorise a Stage or Exception Plan.
“Authorise Project Closure” is the final act of the PB at the end of the project (whether normal or abnormal end).

Finally, the sub-process “Give ad hoc direction” is the primary communication channel between PB and PM. This sub-process is used by the PM to obtain decisions on issue and risk recommendations, for example. It is also the sub-process which receives the Highlight Report from the PM and which subsequently is used to “direct” the PM’s actions in the light of those reports.

DP Key Outputs

Authorisations; decisions; guidance and instruction (to the PM); Project Closure Notification.


The Plans Theme forms the basis for the  generation of the major plans in PRINCE2 projects (Project Plan, Stage Plan, Team Plan & Exception Plan). PRINCE2 does not seek to impose a particular type of graphical plan representation on the PM, and so leaves the door open to Gantt Charts or Activity Networks for example. What PRINCE2 does insist on, however, is that all planning thinking begins with products not activities – thus Product Based Planning is a major technique within PRINCE2.

The big advantage of this approach is that when thinking about products, we are strongly encouraged to include the quality requirements of the Customer within that thinking. As a result, we are much more likely to arrive at a final product which satisfies both the Customer’s functional requirements and quality requirements.

The mechanism for achieving this rests in the generation of the Product Breakdown Structure and associated Product Descriptions (which themselves contain the quality criteria of the individual products being documented).

When the above outputs are allied with the Product Flow Diagram, which shows the emergent dependencies (sequence) between products, it is not hard to then move from that point to the graphical representation of choice, whether Gantt or other.

The Plans Theme is heavily used within PRINCE2. Processes which make use of this Theme to produce various plans are:

SU      (creation of the Stage Plan for the Initiation Stage (IP));

IP       (creation of the Project Plan);

IP       (creation of the Stage Plan for the 1st Stage of specialist work)

MP     (creation of a Team Plan by the Team Manager);

SB      (creation of the next Stage Plan at a Stage boundary);

SB     (creation of an Exception Plan at any point within any Stage);

CP      (creation of the Benefits Review Plan).

PL Key Outputs

Various types of plan as above.