Introduction
PRINCE2 is founded upon 7 principles (made explicit in the 2009 refresh) that underpin best practice in project management. These principles are therefore fundamental to PRINCE2, and should be used as a guide to applying of the PRINCE2 methodology. A project cannot be said to be a PRINCE2 project if any of these principles is neglected. They provide the basis for decision making throughout the project’s life-cycle.
The 7 Principles (JERSEPT)
- Continued business justification
- Learn from experience
- Defined roles and responsibilities
- Manage by stages
- Manage by exception
- Focus on products
- Tailor to suit the project environment
Continued Business Justification (2.1)
There should be a clear ROI (return on investment) for any project, both at the start and throughout its life-cycle. Even compulsory (legislated) projects require justification of the approach taken to solve them. The justification may change as the project progresses, but it should remain valid. If a project becomes unjustified it should be stopped.
The justification is documented in the Business Case, which includes the resources required and the expected benefits for the project. The business case should, of course, be aligned with corporate strategy.
Learn from Experience (2.2)
Throughout the project, all participants should seek out and document learning opportunities. A lesson that doesn’t result in change is not a lesson learned!
At the start of a project, the project team should:
- Consider seeking external expertise
- Review similar past projects
As the project progresses, they should:
- Include lessons learned in all reviews
And at the close:
- Pass on learning at the end of the project
Defined Roles and Responsibilities (2.3)
For a project to be successful, it is essential that:
1. the right people are involved in the project
2. these people know what is expected of them
3. what they can expect from others
The project must have a clearly defined management team who represent the interests of:
- The business – to ensure that the project is justified in terms of ROI
- The users – to ensure that the project produces the intended benefits
- Suppliers – to ensure that the project is feasible from a resourcing perspective
Manage by Stages (2.4)
Every project has a “Planning Horizon”, which is the limit beyond which meaningful planning cannot be undertaken.
To tackle problems associated with this, PRINCE2 divides work into discrete Management Stages. Detailed planning can be undertaken for current stage, whereas plans for the whole project can remain in outline. A significant advantage of this approach is that learning from earlier stages can be carried forward into later stages.
Between each stage are control points where senior management (i.e. the Project Board) undertakes to:
- assess the previous stage
- verify Business Case
- review plans for next stage
- decides whether or not to continue with the project
Longer stages therefore provide less control management control, whereas shorter stages require more work from management.
A PRINCE2 project as a minimum of two stages:
1. The Initiation Stage
2. One additional Management Stage, which includes project closure.
Manage by Exception (2.5)
It is essential that decisions are made at the right level in the organisation, and that each level of authority:
- Has delegated authority to manage at that level
- Is accountable to higher levels of authority
- Can delegate to lower levels in order to use time effectively.
To achieve this, PRINCE2 projects define tolerances at each management level for:
- Time
- Cost
- Quality
- Scope
- Risk
- Benefit
Changes inside tolerance are dealt with at that management level without bothering higher levels. Issues outside tolerance are Exceptions, and are reported to level above. For example, the Project Board normally only hears from the Project Manager in regular reports, unless there is an Exception in which case they are alerted immediately.
Focus on Products (2.6)
A project should focus on outcomes rather than activities. Without clearly defined outcomes, there are no shared expectations. As a result, the project risks:
- rework
- scope creep
- acceptance disputes
- customer dissatisfaction
To mitigate these risks, PRINCE2 Product Descriptions detail outcomes (esp. for quality) and acceptance criteria. Product Descriptions should define such things as the product’s purpose, composition, derivation, format, quality criteria and quality method.
Product Descriptions define the scope of project, and provide the basis for planning resource requirements, dependencies and schedules.
Tailor to Suit the Project Environment (2.7)
PRINCE2 is applicable to all project types, but approach and effort must be tailored as appropriate the project’s needs: environment (e.g.. existing management structure), size, complexity, importance, capability and risk (e.g.. reporting frequency, emphasis on risk).
The Project’s Project Initiation Document (PID) should describe how PRINCE2 will be tailored for that project.