PRINCE2 is designed so that it can be applied to any type of project, no matter its scale, organization, geography or culture.
The principles are designed to contribute to the success of a project without burdening it with bureaucracy. The themes, processes and product descriptions describe what should be done but, in general, not how.
PRINCE2 is principle-based rather than prescriptive; the principles are:
Universal: They apply to every project
Self-validating: They have been proven in practice over many years
Empowering: They give practitioners of the method added confidence and ability to influence and shape how the project will be managed
Continued business justification
PRINCE2 requires that for all projects:
there must be a justifiable reason for why you are doing the project – before you start any work on a project
justification needs to be recorded and approved in some form of business case
the justification must remain valid and must be revalidated throughout the life of the project
The business justification drives decision-making. This is to make sure that the project is always aligned with the benefits being sought, and these benefits must be aligned to the strategic or business objectives.
If an organization does not carefully consider what its business justification is, it may find that projects go ahead even when:
there are few real benefits of doing the project
the project is not aligned with an organization’s strategic direction
Poor alignment with corporate, programme management or customer strategies can result in organizations having a portfolio of projects that have mutually inconsistent or duplicated objectives.
Even compulsory projects should be supported by a business justification to demonstrate that the option that was chosen, represents the best value for money.
The business case
In most organizations, the business justification is usually documented in some form of business case. Some organizations may use business plans or something similar as the business justification during the early stages of the project. Organizations with mature project management will often have annual business plans, with an entry in the business plan constituting the initial business justification for the project. Typically, a detailed business case would only be developed when the project has been fully scoped.
The format and formality of the business case might vary, depending on organizational standards, needs and circumstances. It might even be in the form of just a few presentation slides!
What happens to a project if business justification changes?
Although the justification should remain valid, it may change. It is therefore important that the project and evolving justification remain consistent. If the justification changes, consider the following:
If the project changes but must continue, it must be aligned to the new business case
If a project can no longer be justified, then it should be stopped by the project board
Stopping a project in these circumstances is a positive contribution to an organization as its funds and resources can be reinvested in other more worthwhile projects
When stopping a project, funds should be returned to corporate, programme management or the customer
Learn from experience
Learning from experience takes place throughout PRINCE2:
When starting a project: Previous or similar projects should be reviewed to see if lessons could be applied. If the project is a ‘first’ for the people within the organization, then it is even more important to learn from others and the project should consider seeking external experience
As the project progresses: The project should continue to learn. Lessons should be included in relevant reports and reviews. The goal is to seek opportunities to implement improvements during the life of the project
As the project closes: The project should pass on lessons. Unless lessons provoke change, they are only lessons identified (not learned)
It is the responsibility of everyone involved with the project to look for lessons rather than wait for someone else to provide them.
The ‘lean from experience principle’ is applied to a project to enable the project to repeat successes from previous projects
A lesson is considered to be learnt by a project when it facilitates a change within a project
Defined roles and responsibilities
Projects involve people and are typically cross-functional. Projects may involve more than one function or organization and may involve a mix of full-time and part-time resources.
A PRINCE2 project has defined and agreed roles and responsibilities within an organization structure that engages the business, user and supplier stakeholder interests.
The 3 stakeholder interests
All projects have the following stakeholders:
‘business’ sponsors who endorse the objectives and ensure that the business investment provides value for money
represented by the executive on the project board
‘users’ who, after the project is completed, will use the products to enable the organization to gain the expected benefits
represented by the senior user(s) on the project board
‘suppliers’ who provide the resources and expertise required by the project (these may be internal or external)
resented by the senior supplier(s) on the project board
Therefore, all three stakeholder interests need to be represented effectively in the project management team; two out of three is not enough!
The three stakeholder interests are represented on the project board.
If the project costs outweigh the benefits, the project will be seen as a failure. Equally, if the outcome of the project does not meet the users’ or operational needs, or cannot feasibly be delivered by the suppliers, failure is inevitable.
The project management team structure
The defined project management team structure (or project organization) unites the various parties in the common aims of the project. For all those people involved, a defined project management team structure provides the answer to the questions:
What is expected of me?
What do I expect of others?
The benefit gained from applying the ‘defined roles and responsibilities’ principle, is that clear accountability is established for all members of the project team.
More informationRefer to the 'organization' theme for more information on the project management team structure.
Manage by stages
A PRINCE2 project is planned, monitored and controlled on a stage-by-stage basis. PRINCE2 breaks the project down into discrete, sequential sections, called management stages.
MANAGEMENT STAGES are the sequential sections of a project that the project manager is managing on behalf of the project board one stage at a time. At the end of each stage, the project board reviews the following to decide whether to continue with the project:
progress to date (documented in an end stage report)
the state of the project plan
the business case and risks
the next stage plan
Minimum number of stages
In PRINCE2, a project must have at least two management stages:
an initiation stage
at least one further management stage
How many stages in a project or how long should be?
The choice of appropriate management stages for a project will depend on a number of factors, including:
the amount of risk in the project
the riskier a project, the more management stages may be required
the size and complexity of the project
shorter management stages offer more control
longer management stages reduce the burden on senior management
significant decisions and control points required during the project’s lifecycle; these will often be linked to:
key investment
business decisions
technical decisions
organizational policies and standards
The planning horizon
The ‘manage by stages’ principle reflects that it is usually not possible to plan the whole project from the outset. A time period over which it is possible to plan with reasonable accuracy is called the ‘planning horizon’ and it is seldom possible to plan with any degree of accuracy beyond the planning horizon.
PRINCE2 addresses the planning horizon issue by requiring that both high-level and detailed plans are created and maintained at the same time, reflecting the relative certainty and uncertainty on either side of the planning horizon:
A project plan is created for the project as a whole. This will usually be a high-level plan, providing indicative timescales, milestones, cost and resource requirements based on estimates.
A detailed stage plan is created for each management stage that aligns with the overall project plan timescales. Stage plans are produced before the start of that stage, and must not extend beyond the planning horizon.
An example is shown hereafter of a project lifecycle that has four management stages: an initiation stage, two subsequent stage(s) and the final delivery stage. Note that on a simple project, there may only be two stages: an initiation stage and one delivery stage (the final stage).
Your project may use a method of grouping work by the set of techniques used or the products created, which results in a delivery approach covering elements such as design, build and implementation, which are included in the plan as work packages or activities described as delivery steps.
Delivery steps are a separate concept from the management stages as the work comprising of delivery steps is always included within a management stage. Delivery steps often overlap but management stages are sequential sections that do not overlap. Delivery steps are typified by the use of a particular set of specialist skills.
Management stages equate to the commitment of resources and authority to spend.
Manage by exception
A PRINCE2 project has defined tolerances for each of the six project objectives to establish limits of delegated authority. PRINCE2 enables appropriate governance by defining distinct responsibilities for directing, managing and delivering the project and clearly defining accountability at each level.
Accountability is established by:
delegating authority from one management level to the next
by setting tolerances against six aspects of performance for the respective level of the plan
Delegating authority from one management level to the next
PRINCE2 provides control through delegating authority from one level of management to the level below it:
This implementation of ‘manage by exception’ provides for very efficient use of senior management time as it reduces senior managers’ time burden without removing their control, by decisions that are made at the right level in the organization.
Tolerances are set against the six performance targets
Tolerances are set against the six aspects of project performance, for the respective level of the plan (the project plan and the stage plan):
More informationRefer to the 'progress' theme for more information.
Focus on products
Projects that focus on what the project needs to produce are generally more successful than projects whose primary focus is the work activity. This is because the purpose of a project is to fulfil stakeholder expectations in accordance with the business justification, and to do this there must be a common understanding of the products required and the quality expectations for them.
The purpose of a project can be interpreted in many different ways unless there is an explicit understanding of the products to be produced and the quality criteria against which they will be individually approved.
This focus on products:
ensures that the project only carries out work that directly contributes to the delivery of a product; that is, the project does no more work than it needs to deliver its agreed products
helps manage uncontrolled change (‘scope creep’) by ensuring that all changes are agreed in terms of how they will impact project products and the business justification project
reduces the risk of user dissatisfaction and acceptance disputes by agreeing, at the start, what will be produced by the project
Product-based planning
The philosophy behind the focus on products principle is that what needs to be delivered (the products) must be identified before deciding what activities, dependencies and resources are required to deliver those products. This approach is called product-based planning, which is one of the key PRINCE2 planning techniques.
More informationProcuct-based planning is one of the key PRINCE2 planning techniques that will be discussed during your course. However, a brief introduction is provided under 'plans' in the 'themes' session.
A PRINCE2 project uses product descriptions to provide clarity about the products by defining each product’s purpose, composition, derivation, format, quality criteria and method by which quality will be checked. They provide the means to determine effort estimates, resource requirements, dependencies, and activities.
Under the principle of focus on products, PRINCE2 requires projects to be output oriented rather than work oriented. PRINCE2 calls these outputs ‘products’. The definition of a product in PRINCE2 is: “An input or output, whether tangible or intangible, that can be described in advance, created and tested.”
PRINCE2 categorizes all industry-specific or type-specific aspects of project work as ‘specialist products’ in contrast to ‘management products’, which relate to those required to manage the project. This means that the specialist products concerned need to be identified and included within the project scope and plans.
Therefore, PRINCE2 has two types of products: management products and specialist products.
Management products
Management products are all the information that is required during the project that is required to govern the project. For example a business case, plans, reports or any other control mechanisms.
Think of it as project documentation, data sources or ‘paperwork’ that is created to manage the project
Management products are defined within the PRINCE2 project management method and are archived and cease to exist after project closure
Management products comprise information that supports decision-making
Specialist products
Specialist products are the deliverables specific to an individual project, which is handed over to the user. For example the walls for a house that forms part of the final project product – the house.
Think of specialist products as product description / specifications of what the customer wants
Specialist products may be intermediate components of a product or the final product itself that will be delivered to an operational or business as usual (BAU) environment
Specialist products are delivered by people with specific specialists skills
Tailor to suit the project
The value of PRINCE2 is that it is a universal project management method that can be applied to take account of the project’s environment, size, complexity, importance, team capability and risk, and can be used for any project type, geography or culture.
It can be used on any project because the method is designed to be tailored to suit each project’s specific needs and context. The purpose of tailoring is to ensure that:
the project management method used is appropriate to the project (e.g. aligning the method to the business processes that may govern and support the project, such as human resources, finance and procurement)
project controls are appropriate to the project’s scale, complexity, importance, team capability and risk (e.g. the frequency and formality of reports and reviews)
Tailoring requires the project board and the project manager to make proactive choices and decisions on how PRINCE2 will be applied. When tailoring PRINCE2, it is important to remember that effective project management requires information (not necessarily documents) and decisions (not necessarily meetings).
Tailoring is MANDATORY!
If PRINCE2 is not tailored, it is unlikely that the project management effort and approach would be appropriate for the needs of the project. If the ‘tailor to suit the project’ principle is applied, it is likely to avoid unnecessary management effort.
If the project is not tailored, it can lead to:
‘mechanistic’ project management at one extreme (a method is followed without question)
‘heroic’ project management at the other extreme (a method is not followed at all).
What can be tailored?
Processes may be combined or adapted
Themes can be applied using techniques that are appropriate to the project
Roles may be combined or split, provided that accountability is maintained and there are no conflicts of interest
Management products may be combined or split into any number of documents or data sources
They may be formal documents, but can equally be slide decks, wall charts or data held on IT systems
Terminology may be changed
Benefits of tailoring
The benefit of tailoring PRINCE2 is that project management becomes less bureaucratic.
Who is responsible for tailoring?
The PROJECT MANAGER is responsible for identifying and documenting the level of tailoring for the project.
Where is tailoring documented?
The PID (project initiation documentation) should describe how PRINCE2 has been tailored for that particular project so that all those involved in the project understand how PRINCE2 is to be used and how to carry out their particular responsibilities.
Note:
The team manager may make some suggestions to the project manager about any tailoring that would improve their management of the work packages more effectively
Project assurance may provide advice and guidance on how PRINCE2 should be tailored to suit the project’s situation
In most organizations, the business justification is usually documented in some form of business case. Some organizations may use business plans or something similar as the business justification during the 
