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

Starting up a Project

Prepare the Project Brief

A Project Brief is used to provide a full and firm foundation for the initiation of the project. Later, in the Initiating a Project process, the Project Manager extends and refines the contents of the Project Brief to create the Project Initiation Documentation, after which the Project Brief is no longer maintained.

The Project Manager will create the Project Brief on behalf of the Executive. Nevertheless, Project Board members are encouraged to be available for consultation and to provide guidance and support during this activity so that the completed Project Brief adequately summarizes their requirements and there are no surprises when it is submitted for approval.

The Project Brief comprises:

The Project Product Description includes:

• The overall purpose of the project’s outputs
• Its composition (i.e. the set of products it needs to comprise)
• The development skills required
• Customer’s quality expectations (see ‘The customer’s quality expectations’)
• Acceptance criteria, acceptance method and acceptance responsibilities (see ‘Acceptance criteria’)
• Project-level quality tolerances

The Project Product Description defines what the customer is expecting the project to deliver and the project approach defines the solution or method to be used by the supplier to create the Project Product.

The customer’s quality expectations are captured in discussions with the customer, to avoid misinterpretations and inaccurate assumptions about the project’s quality requirements.

The customer’s quality expectations should cover:

• The key quality requirements for the Project Product
• Any standards and processes that will need to be applied to achieve the specified quality requirements, including the extent to which the customer’s quality management system (QMS) and/or supplier’s QMS should be used
• Any measurements that may be useful to assess whether the Project Product meets the quality requirements - for example existing customer satisfaction measures

The key quality requirements will drive the choice of solution and in turn influence the time, cost, scope, risk and benefit performance goals of the project.

Examples of quality expectation

The quality expectation for a water pump in a remote village is that it is robust enough to ‘last a lifetime’, whereas because the oil pump in a racing car needs to be as light as possible, it may only need to last the duration of one race.

The customer’s quality expectations are often expressed in broad terms as a means to gain common understanding of general quality requirements.
They are then used to identify more detailed acceptance criteria, which should be specific and precise.

Where possible, the customer’s quality expectations should be prioritized as they will be used as inputs to define quality tolerances for the project’s products.

The customer’s quality expectations should be reviewed at the end of each management stage in case any factors external to the project have changed them.

The project’s acceptance criteria form a prioritized list of measurable definitions of the attributes that must apply to the set of products to be acceptable to key stakeholders.
Examples are ease of use, ease of support, ease of maintenance, appearance, major functions, development costs, running costs, capacity, availability, reliability, security, accuracy and performance.

Acceptance criteria should be prioritized as this helps if there has to be a trade-off between some criteria.
High quality, early delivery and low cost, for example, may not be compatible and one of them may need to be sacrificed in order to achieve the other two.

Example of a prioritization technique – MoSCoW

Each acceptance criterion is rated as either Must have, Should have, Could have or Won’t have for now.

All the ‘Must Have’ and ‘Should have’ acceptance criteria should be mutually achievable.

When the project can demonstrate that all the acceptance criteria have been met, the project’s obligations are fulfilled and the project can be closed.

It is important to recognize that little may be understood about the project’s products at this early stage.
Consequently, it is often the case that acceptance criteria will be refined and agreed during the Initiating a Project process and reviewed at the end of each management stage.
Once finalized in the Project Product Description, acceptance criteria are subject to change control and should only be changed with the approval of the Project Board.

In considering acceptance criteria, it is useful to select proxy measures that will be accurate and reliable indicators as to whether business benefits will be achieved subsequently.

Example of acceptance criteria

If a customer’s quality expectation for a water pump is that it ‘lasts a lifetime’, the acceptance criteria should focus on those measures that provide sufficient indication or confidence that the pump is capable of lasting a lifetime (defined as a specific number of years).
This may include complying with certain engineering standards relating to product durability.

Identifying the acceptance methods is crucial because they address the question ‘How do we prove whether and when the project product has been completed and is acceptable to the customer?’

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.