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

Tailoring PRINCE2

Environmental factors

Organizational maturity will have a large influence on the extent of the organizational support available when projects are set up.
At high levels of maturity, there may be established arrangements such as:

• A quality management system (QMS) with corporate responsibilities (which must be recognized in the project arrangements), and standards and processes (which must be observed by the project). If the QMS includes processes for project management, then the assumption here is that they are already based on PRINCE2® and have been tailored to the needs of the organization, e.g. with templates and Product Descriptions for key management products.
• A configuration management system which the project must employ
• A quality assurance function which will contribute to the project’s business and/or supplier assurance
• A centre of excellence (CoE) with subject matter expertise for project management and/or the specialist aspects of the project work
• Programme/project office(s) with subject matter experts for project work
• Technology support in the form of equipment (e.g. for automation) and/or software tools

Thus it can be seen that, at high levels of maturity, Project Board members and Project Managers can expect to receive a great deal of corporate support and advice on the application of PRINCE2.
A mature environment should also be flexible enough to accommodate changes, e.g. for a novel project that does not ‘fit’ well within the constraints of the current QMS, by allowing for ‘concessions’ (approved non-conformances) or process improvements.

At intermediate levels of maturity, some of these aspects of support may be present.
At the lower levels of maturity, without these advantages, a tailored management framework for the project must be established, from scratch, during project initiation.

If the project is part of a programme, some of the characteristics (above) of a mature organization are likely to be present (especially a programme office).

Additionally:

• Benefits management (including benefits review planning) is likely to be conducted at programme level - especially in an MSP® programme environment
• The Starting up a Project process is likely to be a programme-level process and, in effect, the project will start with Initiating a Project (based on a Project Brief approved at programme level) and the appointment of a project Executive
• Risk, change and progress themes at programme and project management levels will have to be carefully integrated so that impact assessment and escalation processes at the project level take into account the wider programme perspective

Projects involving multiple autonomous organizations, e.g. consortia, entail additional risk - in proportion to the number of organizations involved.
This is mainly because each of the participating organizations has its own discrete business interest and objectives.

Representing the various interests in the project management team structure needs to be carefully thought out - by analysing the business, user and supplier relationships between the participants.
In practice, each participating organization will usually implement some form of business assurance to review and safeguard its own business interests.

Another factor is that each organization may have its own QMS, so that agreement must be reached between the parties on which aspects of the various QMSs should be implemented in the joint project.

Contractual relationships between customers and suppliers also need to be carefully analysed.
Who will take the lead in the project? PRINCE2 generally assumes that the customer ‘owns’ the project - hence, that it is customer business and user representation that must feature in the project management team structure.
However, this is not always the case nowadays.
In many contracts the customers aim to safeguard their business interests and benefits in the contract terms, e.g. with payments to suppliers linked to the achievement of customer business benefits (‘sharing the risk’).
In this case, the customer often prefers that project management is undertaken by the supplier, at arm’s length.
Consequently it is the supplier that often assumes the business interest (as well as the supplier interest) and the customer is represented by the user interest in the organization.

As with scale and complexity, business priority (i.e. in relation to other projects in the organization) should have a bearing on the level of sophistication and formality in the project’s plans and controls.
Simple projects may implement PRINCE2 in a less formal manner, perhaps using bullet-point presentations and telephone conferences; whereas high-priority projects are more likely to require formal documentation and face-to-face meetings.

The experience and/or track record of the Project Manager may also be a factor here.
Clearly it is preferable to put higher-priority projects in a safe pair of hands and allow junior Project Managers to learn their trade working on lower-priority work.

Even if the corporate or programme management does not have an established QMS, there may be discrete corporate standards for documentation control, specialist project lifecycle models, approvals, or other, similar disciplines.
In addition, there are almost always industry, regulatory and/or health and safety standards which must be observed.

The application of PRINCE2 must have due regard for these constraints.

The geographical disposition of the project management team(s) may have a bearing on the project management team structure and on the level of formality required in Project Plans and controls.
If key project activities are dispersed across a number of centres, it may be worth considering whether a programme-type governance would be more suitable (other criteria for distinguishing programmes from projects are discussed in ‘Have we established the right level of governance?’ under ‘Context’ within the section ‘Authorize the project’).
Generally, more formality is required where project management and personnel are physically remote from each other.

Even weather may be a factor.
Undertaking work in a remote location and in wintry weather conditions is liable to be prone to additional delays - which should be reflected in Planning and risk management [see ‘The Complete Risk Management package’].

Wherever possible, wider cultural norms should be recognized in tailoring.
Many of these may relate to the project (matrix) organization, e.g. matching it to the local corporate hierarchies - which may be more strictly observed in Eastern countries than in the West.

‘Management by Exception’ can be difficult to implement in some management cultures where a more hands-on form of management is the norm.
This can be accommodated by arranging additional confidence-building meetings for the Project Board during the stages.
Provided that management stages and stage tolerances are implemented and observed, this is still consistent with the PRINCE2 principles.

The terms used for PRINCE2 roles and documentation are unimportant as long as the meaning of the term is understood and implemented.
It simply does not matter whether the Project Board is known as the ‘Project Steering Group’, the Project Initiation Documentation as the ‘Project Charter’, the checkpoint as a ‘progress meeting’ or the Highlight Report is a ‘Progress Report’. What matters is that the terms in use accurately equate to their respective functions and composition in PRINCE2.

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.
MSP® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries.