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

Design and appoint the project management team

Having identified an Executive and the Project Manager, the next activity is to design the wider project management team.
Factors for consideration are the project’s size and complexity and the areas that will be impacted by the project outcomes.

It is then crucial to design a project management team with appropriate business, user and supplier representation and with a suitable level of Project Support resource.

The aim of the PRINCE2® project management team structure is to get the right people in place (i.e. with the right authority, experience and knowledge), making the right decisions in a timely manner.
See the section covering ‘Overview of PRINCE2’ for an explanation of the PRINCE2 project management team structure.

Note that the PRINCE2 project management team structure is defined in terms of roles which do not equate to full-time individuals.
That is, one person may have more than one role, a role may be part-time, or a role may be shared by more than one person.
However, there are some common-sense rules that must be observed:

• There must only be one Executive and one Project Manager
• Project Board members may perform Project Assurance but they do not undertake other project roles
• Project Assurance roles must always be independent of the Project Manager, Team Manager(s) and Project Support.

One of the PRINCE2 principles is that roles and responsibilities in the project must safeguard the interests of the three stakeholder categories.
The Executive, Senior User and Senior Supplier roles make up the Project Board and represent these vital - business, user and supplier - interests, as described in the section covering ‘Overview of PRINCE2’ and the role descriptions in the folder ‘Roles and responsibilities’ as part of the product package.

The Project Board has authority and responsibility for the project within terms of reference set by corporate or programme management (initially contained in the project mandate).
The remit includes:

• Defining what is required from the project
• Authorizing the funds for the project
• Committing the resources
• Communicating with external stakeholders

Project Board members must have the requisite authority.
They are the decision makers, responsible for committing resources to the project, such as personnel, finance and equipment.
Factors such as the budget, scope and importance of the project will determine the seniority of the Project Board members in the participating organizations.

Frequently, Project Board members will be from senior management positions and their Project Board responsibilities will be in addition to their normal line responsibilities.
The concept of ‘management by exception’ provides for them to be kept regularly informed of progress by the Project Manager so that their contribution is focused on decision making at key points in the project.

Project Board members should ideally be assigned to stay with the project throughout its life, though changes may be inevitable sometimes.
A typical example would be where a major external supplier has to be selected part way through a project.
In this case, the procurement function of the business may provide a Senior Supplier initially who may be joined, later, by a representative from the selected supplier.

Where changes have to be made, minimal disruption occurs when this is undertaken at the end of a management stage.

For a major or high-profile project, being appointed to a Project Board on the expectation that this will be for the whole duration of the project may be seen as limiting career progression.
If the right people are to be encouraged to work on business-critical projects, organizations need to arrange incentives appropriately so that success is properly rewarded.

The Executive has already been appointed at this point – see ‘Select the right Executive’ under the section covering ‘Appoint the Executive and Project Manager’.

The Senior User represents the interests of the users of the project’s products, and/or those most affected by its outcome.

The Senior User is responsible for monitoring that the project will meet the users’ needs by:

• Providing user resources to the project
• Defining acceptance criteria for the project
• Ensuring the project’s products are specified in line with the users’ needs
• Maintaining business performance stability during transition from the project to ‘business as usual’
• Ensuring that the benefits of the project are realized (post-project this will be in the capacity of a functional manager rather than the Senior User as the role does not exist post-project).

See the folder ‘Roles and responsibilities’ as part of the product package for the Senior User’s responsibilities.

The Senior Supplier represents the interests of those designing, developing, procuring and/or implementing the project’s products.
The Senior Supplier is responsible for developing products that will meet the requirements of the Senior User, within the cost and time parameters for which the Executive is accountable.
This role will include providing supplier resources to the project and ensuring that proposals for designing and developing the products are feasible and realistic.

The Senior Supplier also represents the interests of those who will maintain the specialist products of the project after closure, e.g. engineering maintenance and support.
Exceptions to this do occur, e.g. when an external supplier is delivering products to a customer who will maintain them in service/operation: in this instance the operations and maintenance interests are more likely to be represented by a Senior User.
In fact, the distinction is not really important - what matters is that operations, service and support interests are represented appropriately from the outset.

Normally, the Project Manager will have been appointed at this point - see ‘Select the right Project Manager’ under the section covering ‘Appoint the Executive and Project Manager’.

Team Managers’ responsibilities are to ensure that the products allocated to them by the Project Manager are created in line with agreed Product Descriptions.
Team Managers report to, and take direction from, the Project Manager.

In the permanent line structures of the participating organization, there is often also a reporting relationship between one or more Team Managers and the Senior Supplier.
It is vital that any such links are understood and project roles are documented so that conflicts are avoided and the Project Manager’s authority is not undermined.

In appropriate circumstances - and often for simple projects - the roles of Project Manager and Team Manager may be assigned to the same person.

Project Board members are responsible for the aspects of Project Assurance aligned to their respective areas of concern - business, user or supplier.
They may conduct their own Project Assurance activities or appoint other, independent, managers or specialists to undertake specific Project Assurance roles.
For example, a corporate or programme-level quality manager may be appointed to take on a Project Assurance role.

Project Assurance is not just an independent check, however.
Personnel involved in Project Assurance are also responsible for supporting the Project Manager, by giving advice and guidance on issues such as the use of corporate standards or the correct personnel to be involved in different aspects of the project, e.g. quality inspections or reviews.

Where Project Assurance tasks are shared between Project Board members and other individuals, it is important to clarify each person’s responsibilities.
Anyone appointed to a Project Assurance role reports to the Project Board member for the interest concerned - and must be independent of the Project Manager.

Examples of Project Assurance tasks include, but are not limited to:

• Reviewing the outline Business Case (particularly for business assurance)
• Checking that the project approach is technically correct and in line with corporate or programme strategy (supplier assurance)
• Confirming that the Quality Management Strategy includes the required standards (all assurance interests)
• Ensuring all risks are identified, with suitable ownership and responses (all assurance interests)
• Checking the Product Descriptions are unambiguous (all assurance interests)
• Advising Project Board members on issues of detail (all assurance interests)
• Advising the Project Manager on suitable people to select as quality reviewers or change impact assessors (all assurance interests).
• Acting as independent, or peer, reviewers in product quality reviews (all assurance interests)

Where projects are part of a programme, the programme office (or Programme Management Office, PMO) will often supply Project Assurance resources.
However, if implemented inappropriately, this arrangement can undermine the accountability of Project Boards and Project Managers.
It must be clear that programme offices do not carry any accountability for the project, and that any authority must be exercised through the Project Board or the Project Manager.

Example of Project Assurance

The gateway reviews recommended by the UK Office of Government Commerce (OGC) are examples of the types of assurance reviews that can be conducted at programme or project level.

These involve a team of experienced people, entirely independent of the project management team, who conduct reviews at key decision points throughout the project or programme.

Though not conducted by the internal Project Assurance personnel, these are, nevertheless, a type of Project Assurance measure that may be available to the Project Board.

All projects will require some amount of administrative work.
Project Managers need to be free to lead and communicate and, if the administrative burden compromises their ability to do so, they should be able to delegate this type of activity to a Project Support resource.

Project Support can involve general administrative services or specialist support for the processes, methods and tools in use on the project, e.g. for configuration management.
Many organizations set up project offices to provide systematic support for a number of projects.

Where programmes of related projects are established, programme offices have additional scope and benefits - but, again, care must be taken not to undermine the authority of the Project Board and Project Manager.

Project Support and Project Assurance roles are separated in order to preserve the independence of Project Assurance.

It may not be necessary to make appointments for some of the roles this early in the project, e.g. Team Managers, Project Support, but there needs to be (as a minimum) a full understanding of the roles that will be required.
Also, for external appointments (e.g. suppliers) it may not be possible to allocate roles if the activity to select the supplier (e.g. through tendering) is part of the project.

Appointees should be carefully matched to roles and fully briefed, both about the project and the PRINCE2 management framework, on joining the project.
The expected time [see 'The Complete Time Management package'] commitment should also be estimated and agreed.
Ideally, role descriptions should be tailored specifically to the project in question.

In a well-run project, everybody involved in the management understands and agrees who is accountable, to whom and for what.
Also, everyone is aware and familiar with the lines of communication.

The responsibilities of the Project Board members should be defined.
The folder ‘Roles and responsibilities’ as part of the product package provides role description outlines for all the PRINCE2 roles - however, the generic role descriptions should always be tailored and specific to the particular project context.

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.