Directing Projects with PRINCE2

• Introduction
• Overview of PRINCE2
  • Key definitions
  • Structure of PRINCE2
  • The role of senior management in PRINCE2
  • Overview of PRINCE2
• Project Board duties and behaviours
  • Overview
  • Be accountable for the project
  • Provide unified direction
  • Delegate effectively
  • Facilitate cross functional integration
  • Commit resources
  • Ensure effective decision making
  • Support the Project Manager
  • Ensure effective communication
• Starting up a Project
  • Purpose
  • Context
  • Confirm the understanding of the project mandate
  • Appoint the Executive and Project Manager
  • Capture previous lessons
  • Design and appoint the project management team
  • Prepare the outline Business Case
  • Prepare the Project Brief
  • Prepare the Initiation Stage Plan
  • Summary
• Authorize initiation
  • Purpose
  • Context
  • Approve the Project Brief
  • Approve the Initiation Stage Plan
  • Communication
  • Suggested Project Board agenda
  • Summary
• Authorize the project
  • Purpose
  • Context part 1
  • Context part 2
  • Context part 3
  • Communication
  • Review the End Stage Report for initiation
  • Approve the Project Initiation Documentation
  • Approve the next Stage Plan
  • Suggested Project Board agenda
  • Summary
• Authorize a Stage or Exception Plan
  • Purpose
  • Context part 1
  • Context part 2
  • Review End Stage Reports
  • Approve Stage or Exception Plans
  • Assess project viability
  • Suggested Project Board agenda
  • Summary
• Give ad hoc direction
  • Purpose
  • Context
  • Respond to requests
  • Respond to reports
  • Respond to external influences
  • Focus of individual board members
  • Communication
  • Summary
• Authorize project closure
  • Purpose
  • Context
  • Confirm handover and acceptance
  • Approve the End Project Report
  • Approve the Benefits Review Plan
  • Communication
  • Suggested Project Board agenda
  • Summary
• Reviewing benefits
  • Purpose
  • Context
  • Hold benefits reviews
  • Close the Business Case
  • Communication
  • Suggested agenda for benefit reviews
  • Summary
• Tailoring PRINCE2
  • Purpose
  • Introduction
  • Environmental factors
  • Project related factors
  • What does tailoring involve?Adapting the themes

Key sections

• Introduction
• Business case
• Organization
• Quality
• Plans
• Risk
• Change
• Progress
• Introduction to processes
• Starting up a projectDirecting a project
• Initiating a project
• Controlling a stage
• Managing Product Delivery
• Managing a Stage Boundary
• Closing a Project
• Tailoring PRINCE2 to the project environment
• Directing Projects with PRINCE2

Authorize a Stage or Exception Plan

Approve Stage or Exception Plans

Project Board members should always be available for consultation during the planning activity and take opportunities to give informal or provisional approval of the Stage Plan or Exception Plan before it is formally submitted.

If Project Board members fail to communicate effectively - with each other and/or with the Project Manager and others involved in planning - delays and uncertainty can arise both during plan preparation and in approval.
On the other hand, if communication has been effective there will be no surprises when the plan is finally submitted and the Project Manager requests approval to proceed.

Note that, for simple exceptions, an Exception Plan can take the form of a simple request for change to the current Stage Plan.

For instance, if the problem is a simple delay or need for additional budget, and there are no reasons to change other aspects of the plan, then a request for change is probably the most economic way forward.
However, the request for change still effectively acts as an Exception Plan and must be treated as such, so that its effects on the tolerances and Business Case are properly managed.

If the plan being reviewed is for the final stage of the project, Project Board members must ensure that it includes provision for all necessary project closure activities, including those outlined in the Closing a Project process (see the section covering ‘Authorize project closure’ for a summary of these activities).

Project Board members should be satisfied that:

• The products are valid
• The assumptions are realistic
• The external dependencies will be satisfied
• The risks have been identified and suitable countermeasures planned
• The resourcing is adequate
• The resources are available and will be committed
• The timescales are realistic
• The quality criteria and methods proposed are appropriate
• The arrangements for monitoring, control and reporting are appropriate

Although all Project Board members should consider, and have confidence in, all aspects of the Stage Plan or Exception Plan, each member will have a specific area of focus - and there are some cases where it is essential that there is a shared understanding.
The following sections explore this in more detail.

• Do the Product Descriptions accurately reflect the scope agreed for the stage?
• Does the Stage Plan accurately reflect the approach agreed for the stage (or for the agreed recovery action)?
• Can the Project Board commit to delivering all the necessary resources?
• Are the timescales and costs for the stage broadly in line with the Project Plan?
• Have the lessons learned from the earlier work (and other, similar projects) been properly taken into account in the plan (particularly if there has been an exception)?

• Are there any significant vulnerabilities in the plan?
• Have they been identified as risks?
• Are they manageable?
• Is it clear how they are to be managed?
• Is the framework of controls appropriate?
• Is PRINCE2® being scaled and tailored sensibly?
• If there has been an exception, should the pattern of controls and tolerances be changed to reduce the likelihood of further exceptions?

• Are the planning assumptions relating to user resources and products realistic?
• Is there confidence that user-related dependencies (internal and external) will be met, e.g. customer obligations?
• Are the important risks for operational users identified accurately? Is it clear how they are to be managed?
• Will the Project Assurance arrangements adequately safeguard the interests of user stakeholders?
• Will users be adequately represented in quality control activities, e.g. as quality reviewers?
• Can the user personnel (and any other user resources) be committed to the project work as indicated in the plan?
• Is the timing of the user-related activity in the plan achievable bearing in mind business-as-usual commitments and any other parallel initiatives?
• Are the service functions and personnel who will be responsible for supporting and/or maintaining the specialist products after the project has delivered them adequately represented in the plan?
• What is the status of any benefits due to be realized at this point?

• Are the planning assumptions relating to specialist resources and products realistic?
• Is there confidence that specialist technical dependencies (internal and external) will be met, e.g. contractor and third-party supplier dependencies?
• Are appropriate technical methods, techniques, tools and standards being applied?
• Are the important technical risks identified accurately? Are they manageable? Is it clear how they will be managed?
• Will the current Project Assurance arrangements adequately safeguard the quality of the specialist technical effort?
• Will specialists be adequately represented in quality control activities, e.g. as quality reviewers?
• Will the Project Manager have sufficient technical support, e.g. for advice and guidance on specialist issues?
• Are people with the required specialist skills and experience available?
• Are the service functions and personnel who will be responsible for supporting and/or maintaining the specialist products after the project has delivered them adequately represented in the plan?
• Can the specialist personnel be committed to the project work as indicated in the plans? Can all the other specialist technical resources, such as equipment, be delivered?

If the Project Board is authorizing a stage, there are two key decisions involved:

• Is the current stage complete?
• Do we progress on the basis of the plan for the next stage?

If Project Board members are happy on both counts, then they simply grant the authorization to proceed by approving the Stage Plan.
In practice, there may be some concerns about progress - perhaps there is some work outstanding from the current stage or the Project Board is not fully confident of the plan for the next stage.

If these are just minor loose ends and the Project Board is confident they will be managed properly going forward, Project Board members may agree to grant conditional approval to proceed by either:

• Requiring the Project Manager to produce a Highlight Report, by a specific date, to confirm that the matters outstanding from the earlier stage have been resolved, or
• Requiring specific modifications to the plan for the next stage.

However, if the problems are more serious, it is an indication that the Project Manager has not fulfilled the stage contract.
Either the current stage is incomplete or the plan for the next stage is inadequate.
Project Board members need to assess the risks this may pose for project control.
It may be that the position can be recovered and it will be sufficient for the Project Board to instruct the Project Manager to take corrective action and then a short while later the board can reconsider the approval to proceed.
Alternatively, the Project Board may need to consider replacing the Project Manager.

Project Board members should use their discretion carefully in these circumstances.
An analogy is the rail industry term SPADs, meaning ‘signals passed at danger’.
This system permits the train driver to pass one danger signal, slowing down, but if the next signal is also red, the driver must stop.
In the same way, Project Board members should consider stage boundary problems as danger signals - one instance may be manageable (if the Business Case is still sound) but if the problems are not corrected it is their duty is to address the issue.

If the Project Board is approving an Exception Plan, it is already apparent that the current stage cannot be completed as planned.
Consequently there is only one decision to make: whether or not to proceed on the basis of the Exception Plan.
Effectively, the Project Board needs to consider the same risks and options (covered above) as they would for a Stage Plan.

Terminating a project is sometimes the best business option at this point.
It does not necessarily mean that the original business initiative is abandoned.
It may mean that the current project is no longer a viable means of delivering the required results - and a new project, with a revised baseline, is the best way forward.
If the decision is to abandon the business initiative, it is important that the Project Board commissions an orderly project closure, including the activity recommended in the PRINCE2 process Closing a Project (and outlined here in the section covering ‘Authorize project closure’) - the Project Board’s aim should be to commission and approve a closure Stage Plan which will salvage as much business value as possible from the premature termination.

Example of lost value

It is all too common for projects to be abandoned and the latent value created to be lost.
A case in point is the UK’s ‘tilting’ Advanced Passenger Train (APT) project.
Development started in the late 1960s and was abandoned in 1981.
Although the project did not achieve its goal, it did advance train technology enormously - but that was not fully exploited for the benefit of British Rail.
Fourteen years later, tilting trains manufactured in Italy were in service on the UK’s West Coast Main Line from London to Glasgow.

A key part of approving a Stage Plan or Exception Plan is agreeing the tolerances for the stage.
Stage tolerances underpin management by exception and should be carefully considered so that the Project Manager has a sensible amount of discretion.

If tolerances are too tight, the Project Manager will be obliged to escalate decisions to the Project Board even when there are simple variances from planned performance.
By the same token, if tolerances are too generous, the Project Manager may be encouraged to take decisions which should properly be taken by the Project Board.

Some project approaches (e.g. ‘time-boxing’) put more emphasis on scope tolerances and prioritizing the requirements which must be addressed during the stage.

If there is a high probability of customer-requested scope changes, this can be addressed by implementing a change budget.

Stage tolerances are often constrained by project level tolerances, which define the boundaries of the Project Board’s discretion.

Where an exception has occurred, the Project Board should consider whether tolerances should be tightened (if the project or business risks are critical) or relaxed (if control has been generally secure and the exception was relatively trivial).

The operation of tolerances is discussed in ‘Exceptions and escalation’ under ‘Delegate effectively’ within the section covering ‘Delegate effectively’.

All references above are in Directing Successful Projects with PRINCE2 unless stated otherwise.

PRINCE2® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries.