The 7 Principles of PRINCE2

PRINCE2 Principles

PRINCE2’s principles are guiding doctrines which must be followed by all projects.  They are like a project constitution of sorts.  All projects must abide by these philosophies.

The seven principles are:

  1. Continued Business Justification
  2. Learn from Experience
  3. Defined Roles and Responsibilities
  4. Manage by Stages
  5. Manage by Exception
  6. Focus on Products
  7. Tailor to Suit the Project

Principle 1: Continued Business Justification

PRINCE2 projects must have a well defined, and continuously validated, business case. 

A surprising number of projects suffer from unclear goals, misalignment with the organizational strategy, or duplication with other projects.

An organization initiates a project in order to realize some sort of business goal.  It can be a new business line (increased profitability), a cost reduction project, or driven by compliance with legislation or regulations.  This business case must be explicitly stated, and continuously managed throughout the project.

In PRINCE2, projects are said to realize certain benefits to the parent organization.  These benefits must be well known to everyone on the project team.  They need to be continuously managed throughout the project.

Some projects are driven by compliance to legislation or regulations.  In this case, they must be supported by a business justification that demonstrates robust value for money.

Principle 2: Learn from Experience

mistakeIt is a requirement of PRINCE2 projects to learn from past mistakes and successes.

Since a project is by definition temporary, with a finite beginning and end, there is an element of uniqueness that requires knowledge transfer from the parent organization, or other projects, or wherever it can be found.

Learning from experience takes place at any time throughout the project life cycle:

  • At the beginning, during project planning the impact of experience from other projects is the greatest and the easiest to incorporate.  It takes little time but cannot be missed in the crucial early steps.
  • Throughout the project the lessons learned might include things from the project itself.  PRINCE2 projects must be continuously looking back and assessing what worked, what didn’t work, and how things can be improved.
  • At the end, the lessons learned must be compiled for use on future projects for the organization.  If project experiences do not invoke change, they are not lessons learned.

Principle 3: Defined Roles and Responsibilities

Roles and responsibilitiesPRINCE2 projects have clearly defined roles and responsibilities.

There are three general categories of project stakeholders:

  1. Business
    These are stakeholders who have a business interest in the project.  For example, executives from the parent organization, investors, and the project management team itself.  Business stakeholders in this category are supporters of the project, that is, they wish to see it succeed, although each for different reasons.  They are on the “business side” of the project.
  2. Users
    These stakeholders use the project’s deliverables to improve their lives in some way.  Some projects have many users, and some have just one, for example a road paving project has many vehicles that use the final product.  Regardless of how many users there are, they are the reason that the project is undertaken as the demand for the project’s end result supports the business case for the project.
  3. Suppliers
    This category contains all of the people and organizations that carry out the project.  They can be external contractors or internal project teams.  They can be organizations from which equipment or tools are purchased.  The project team itself is considered a supplier.  People in this category want to be fairly compensated for their work, receive accolades, references, and career advancement.  They want to position themselves for the next project.

Principle 4: Manage by Stages

phases 1, 2, and 3PRINCE2 divides projects into management stages.  A management stage is similar to a project phase.  At the end of each management stage, the project must be assessed for progress to date, the state of the project plan, project risks, and compliance with the business justification of the project.

All projects must have a minimum of two management stages, one for the project initiation and one for project execution.  Small projects will cover the project planning in this first initiation stage, then reassess the project and decide whether to proceed to the execution stage.

At the interface between management stages, the project board must reassess the project to determine alignment with the business goals of the project.  Then, they delegate the authority of the day to day management of the stage to the project manager.

The determination of where stage boundaries occur is usually dependent on the natural phase changes of the project, as these are the natural decision points when the project needs to be reassessed.  Points where the type of work changes, or team members change, a deliverable is produced, or the like, are ideal management stage boundaries.

Principle 5: Manage by Exception

graphIn a PRINCE2 project, the project board establishes the tolerances that the project manager must work within, and any time the project breaches those tolerances, an exception report must be produced which gives the project board the opportunity to make decisions regarding the ongoing viability of the project.

These tolerances must be established for the following six factors:

  1. Cost
    The project budget is usually a major factor in project success.  The allowable tolerances must be established by the project board, and deviation out of those defined tolerances requires a decision to proceed by the project board.
  2. Time
    The completion date of the project, or any significant milestone, must be determined together with allowable tolerances at the project initiation.  If the actual completion date of the project, or milestone, is outside of those tolerances, the project board must once again reassess the project via an exception report.
  3. Quality
    The quality specifications of the project’s deliverables are established at the project initiation together with their allowable tolerances.  For example, things like number of defects, production time, strength, maintenance requirements, paint thickness or any other factor.  The quality specifications can be determined in house or specifications obtained from external sources such as ISO, ASTM, etc.
  4. Scope
    Project scope issues are the number one reason for project failure.  It is remarkably easy to let small, unauthorized work creep into the project, driving up the cost and creating missed deadlines with little to show for it – this is called scope creep.  Hence, the scope of the project must be well defined, and its tolerances must be determined by the project board.
  5. Benefits
    All projects are initiated with some form of benefits to the parent organization in mind.  These can be for the increase of future profit, reduction of costs, or compliance with regulations.  The benefits must be specified and monitored throughout the project and at each management stage boundary.
  6. Risk
    Unexpected things can happen that jeopardize the benefits the project is attempting to create for the parent organization.  These risks must be itemized, and prioritized.  Their tolerances must be established, and any deviations from those boundaries requires a reassessment.

Principle 6: Focus on Products

PRINCE2 projects are focused on the end products.

All projects produce some form of product.  They can also produce a service, for example, a project to deliver a course to a group of people has the finished course as the final deliverable – it is not a tangible product.

It is remarkably easy, however, to lose sight of the end product in favor of the processes required to get there.  PRINCE2 contains many project management products, for example, the Project Initiation Document (PID), Risk Management Approach, and Project Controls.  But these should never get in the way of focusing on the final project deliverables, and delivering them to the client/customer.  Hence, the only work that should ever take place is work that contributes to the delivery of a product.

Because of the potential confusion between the two uses of the word product, PRINCE2 defines them this way:

  1. Management products are project management documents that support the project’s completion.  They are not delivered to the client/customer.  For example, the risk register, issue log, and PID are management products.
  2. Specialist products are those that are produced by the project and delivered to the client/customer.  For example, if a project is for the completion of a software product, the software is a specialist product.

Principle 7: Tailor to Suit the Project

toolsSince projects come in all shapes and sizes, and PRINCE2 is a universal project management system that applies to any project, it must be adjusted to suit the project environment, size, complexity, team capability, and risk.

Decisions must be made by the project manager and/or project board regarding the application of PRINCE2 to each project.

The Project Initiation Document (PID) should describe how PRINCE2 has been tailored to the project.

Learn More

One Reply to “The 7 Principles of PRINCE2”

Leave a Reply

Your email address will not be published. Required fields are marked *

*