- Processes – describing who is responsible for doing what and when
- Themes – areas of project management which need to be continuously addressed throughout the project
- Principles – the building blocks upon which the themes and processes have been based
- Tailoring PRINCE2 to suit the needs of the project
The articles have not been written as an in depth guide to PRINCE2 however. For that, it’s much better to read the official manual – Managing successful projects with PRINCE2®.
In this series of article we’re going to focus on those elements which are most frequently examined on the PRINCE2 Foundation exam. As such, the 3 articles form very useful PRINCE2 Foundation exam study guides. Those items highlighted in bold are the ones most commonly included in questions in the PRINCE2 Foundation exam.
If you use these 3 articles to study for the PRINCE2 Foundation exam, then your chances of passing will be much greater.
The project management framework known as PRINCE2 is based upon a set of principles. These principles are the bedrock and foundations upon which everything else in the framework is based.
PRINCE2 is based upon these principles for a very simple reason. By being principles-based, it means that the framework can be applied to any shape, size or type of project. In this way, the principles can be universally applied, both to a small in-house company project based here in London, or equally to a massive international aid project spanning many borders commissioned by the United Nations.
These principles have also been proven in practice over many years to be the most effective ways of managing projects i.e. they are based upon modern best practices in project management. This means they can be applied directly on projects and the project management team does not need to "re-invent the wheel" by creating their own project management method from scratch.
The principles are also empowering to the project management team because they can give them added confidence and an ability to shape and manage their projects
So, let’s take a look at each of these principles in turn.
Continued business justification
The first principle or PRINCE2 emphasises that there must always be a viable Business Case driving the project.
The Business Case is updated throughout the project, as well as being used when starting up the project. If the factors underlying the Business Case change in such a way that the expected benefits are no longer likely to be realised, then the project should be closed prematurely.
Changes detrimental to the Business Case are often linked to the economy; for example, the recent worldwide recession led to many major building projects being brought to a halt.
This principle also applies if the project is compulsory (e.g. required to achieve compliance with new legislation) - the organization will require justification of the particular project chosen, as there may be several options available that yield different costs, benefits and risks.
The Business Case contains the reasons for running the project, with the expected benefits documented in measureable terms. In PRINCE2, the benefits expected from a project are subject to tolerances; if they drop below those tolerances, then the Business Case is no longer viable.
For example, if a project is mandated for the purpose of making a profit, then the mandate should identify the threshold of profit that determines the viability of the Business Case. If the expected profit drops below that threshold, due to changes in circumstances, the project should be stopped.
According to PRINCE2, project work should be broken down into stages, for ease of manageability. The Business Case is updated by the Project Manager at the end of a stage and the Project Board will be presented with this updated documentation when they assess the project at a stage boundary.
At a stage boundary the Board will decide if the Business Case remains viable, before authorising the plan for the next stage. If the viability of the Business Case raises concerns during a stage, a project issue can be raised to bring the matter to the attention of the Board as soon as possible, and before the end of stage assessment.
In the event of a project being closed prematurely, the organization must ensure that lessons are learned about the cause of the failure. In addition, every attempt should be made to derive maximum benefit from any outputs and outcomes that had been achieved by the project.
Learn from experience
As humans, we are inclined to repeat our mistakes. PRINCE2 addresses this tendency with its requirement for reporting the lessons which we learn from projects. So important is this requirement, it is elevated to that of a principle within the framework.
Throughout a project the project manager should remain alert to potential lessons to be learned. These lessons can be identified in the many reports generated by the project management team.
A responsibility of the project manager is to identify, document and disseminate lessons, via Lessons Reports to the Project Board. Members of the Board distribute the Lessons Reports to appropriate parties within the organisation’s various projects.
20:20 Hindsight = Lessons learned
Aside from lessons identified during the current project, PRINCE2 also emphasises the importance of lessons learned from previous projects. In PRINCE2, the very first activity the project manager performs during the Starting Up a Project process is to create a Lessons Log, in order to document previous lessons. Lessons Reports may then be generated at the end of each stage and are a required output of the Closing a Project process.
When assessing whether an organisation’s approach to project management is compliant with PRINCE2, assurance auditors may require evidence of lessons actually being ‘learned’, i.e. proof that steps have been taken to avoid repeating previous mistakes.
One potential source of evidence is an adapted quality control process if the original strategy was modified after being found wanting. For example, suppose the Quality Management Strategy for a software project called for ‘user acceptance testing’ but some users recruited for the testing were found to lack the necessary experience. In later testing procedures, a more focused category of user could be recruited, in response to the lesson learned about inappropriate users.
20:20 Foresight = Best practices
Recruiting an individual with experience in a similar project, or purchasing documentation from a previous project, can be an effective means of avoiding past mistakes. A number of high-profile project managers from the Olympic Games in Sydney, Australia, were recruited to work on the London 2012 Olympic Games project management team - they brought with them their own lessons learned.
An organization’s Project Management Office (PMO) should create a repository of Lessons Reports, ensuring that lessons are made available to future projects. Learning from experience is crucial to PRINCE2’s ‘best practice’ approach to project management.
Defined roles and responsibilities
The PRINCE2 principle ‘Defined roles and responsibilities’ emphasizes that each person involved in a project should be aware of the particular contribution that he/she is expected to make to that project.
If everyone understands what is required of them, the chances of delivering a successful project are greatly improved. Any confusion about what should be done, by whom, and when is likely to be detrimental to the project’s progress.
For example, a lack of clear leadership is a common cause of project failure. With defined roles and responsibilities in place, the risk of project failure due to inadequate leadership can be reduced.
Levels of management
The principle requires a management hierarchy - from the Project Board at the top, to the Project Manager below, and then down to the Team Manager. The hierarchy ensures that the project is managed using three clearly defined levels of management.
On a PRINCE2 project, the Project Board consists of three roles: the Executive, Senior User, and Senior Supplier. Only one person fulfils the Executive role, but any number of people may perform the other roles. If the Board members are unable to agree on a particular issue, the Executive acts as the decision maker.
For small projects, the Project Board may consist of just the Executive, who will perform all of the Board’s duties. If the project is large, the Project Board is likely to be complex, consisting of a cross-functional representation of many elements of the participating organizations. In PRINCE2, the Project Board is part of the project team, which also includes the Project Manager, Project Support and Team Managers.
Moreover, PRINCE2 identifies three stakeholder interests: Business, User and Supplier and the Project Board is designed to represent all three interests.
The Business interest (sometimes referred to as Corporate) sponsors the project, endorses its objectives, and aims to ensure that the business investment provides value for money.
The User interest refers to members of the Business who, after the project is completed, will use the project’s products to enable the organization to gain the intended benefits.
Both User and Business interests collectively represent the Customer (with the Executive being responsible for the Business element).
The Supplier interest represents those who provide the resources and expertise required by the project. They may be internal or external to the customer organization. All three stakeholder interests must be represented within the project, in order for it to succeed.
Manage by stages
According to this principle each stage of a project must be properly planned, monitored, and controlled. A PRINCE2 project requires a minimum of two stages - the first one being called the ‘Initiation’ stage (during which the project is planned), and then at least one more to cover the delivery of the project’s specialist products.
The requirement for an initiation stage ensures that a project is not started before detailed forecasts of costs and timescales have been completed. If the project skips this stage, there is a risk that it will ultimately cost considerably more than originally anticipated.
At the end of the initiation stage, the Project Board assesses the viability of the project by examining the Project Initiation Documentation (PID). In accordance with this principle, a project that is given the go ahead will be assessed again by the Board at regular intervals (known as management control points) during its lifecycle. After each assessment, the Board may decide that the project should continue as planned, alter its scope, or prematurely close it if it is no longer viable.
It is a general rule of planning that every plan should be made only to a manageable and foreseeable level of detail (called a planning horizon). PRINCE2 recommends three levels of plan - the Project Plan, Stage Plans and optional Team Plans; each is appropriate for the particular level of management that uses it.
The Project Board uses an updated version of the Project Plan as its working document throughout the project. The Project Manager, who is responsible for the day-to-day management of the project, will use the current Stage Plan. The Team Manager(s) will write Team Plans to an appropriate level of detail.
Each management stage in PRINCE2 acts as a “go/no go” decision point for the Project Board. It’s where it decides whether the project is still viable and if so, can commit to the next stage by approving the plan for the next stage.
If the decision is “go” then effectively this gives permission for the Project Manager to spend the money authorized by the Board for the next stage and is thus a less risky approach to taking investment decisions when compared with one big decision taken at the beginning of the project.
If the decision is “no go” then the project is no longer viable, then the project should be prematurely closed.
Stage boundaries therefore enable the Project Board to control the project on a stage-by-stage basis, whilst delegating day to day management of the stage to the Project Manager.
Manage by exception
On a PRINCE2 project, tolerances are established for each project objective. Limits of delegated authority are also defined, so that it is clear who should make a decision about corrective action if tolerances are exceeded. The activities associated with directing, managing, and delivering the project must be performed within agreed tolerance levels.
On a PRINCE2 project, regular Highlight Reports keep the Project Board informed about progress. This leaves the Board members free to carry on with their own activities, beyond those required for the directing of the project. Only if a tolerance level is forecast to be exceeded (known as an ‘exception’ in PRINCE2), does the Board need to address the issue through the assessment of an Exception Report.
The 6 performance targets for which tolerances are set on a PRINCE2 project are: time, cost, quality, scope, benefits, and risk. Accepted tolerances are agreed for each of these elements at the project level by members of corporate management, when the project is mandated. Changes to these project-level tolerances can only be made at corporate level too.
Once an exception to a project-level tolerance occurs, the Project Board must escalate the problem to corporate level for a decision to be made.
Stage tolerances are calculated by the Project Manager when planning each Stage. They are then confirmed by the Project Board when it approves a Stage Plan. Similarly, Work Package tolerances are set by the Project Manager when a Team Plan is authorised.
If a Team Manager raises an issue, indicating a deviation from Work Package tolerances, the Project Manager must assess the issue and take corrective action, unless the Stage tolerances will be affected. If the issue will affect the Stage tolerances, the Project Manager must create an Exception Report, and escalate the matter to the Board.
Benefits of "managing by exception"
By working in this way, the Project Board "manages by exception" i.e. only gets involved when key decisions need to be taken (when an issue exceeds agreed tolerances) and hence is a very efficient use of senior management time.
Focus on products
PRINCE2 recognises the importance of delivering products that meet their agreed quality criteria, hence the 'focus on products' principle.
When products are successfully delivered, they lead to project benefits, and so it is extremely important that they are planned and executed effectively. If the stakeholders' expectations are to be fulfilled in accordance with the business justification, everyone involved with the project must agree on and fully understand the nature of its products. Otherwise the aim of the project will be open to interpretation - and considerable confusion is likely to ensue, impeding the project’s progress.
Whereas some project management methods focus on activity planning, planning in PRINCE2 starts with identifying products. Product-based planning is a crucial aspect of the PRINCE2 approach to managing projects; in particular, it helps the project team to reduce the risk of scope creep, as well as making issues such as acceptance disputes and user dissatisfaction less likely to occur and potentially less damaging.
As part of PRINCE2’s product-based approach, Product Descriptions are developed and agreed, and these effectively describe what is to be delivered by the project. They help to ensure that everyone involved in the project is aware of each product’s purpose, composition, quality criteria, etc. They also enable the project team to estimate how much work will be involved in bringing each product to fruition, what resources will be required, what activities must be performed, and so on. The agreed products define the project’s scope, as well as providing a foundation for planning and control activities.
Tailor to suit the project environment
The final principle 'Tailor to suit the project environment' highlights a key advantage of using PRINCE2 - its adaptability.
The verb to "tailor" refers to the appropriate use of PRINCE2 so that it matches the needs of a particular project. PRINCE2 recognises that all projects are different in terms of their cultural context, geographical location, level of complexity and scale. Tailoring to suit the project environment allows you to adapt the PRINCE2 methodology to suit the needs of your project - and still comply with the PRINCE2 approach to project management.
For example, one element of PRINCE2 that is routinely tailored is the schedule for Project Board meetings. Such meetings are not a requirement of the PRINCE2 methodology; regular Highlight Reports are considered sufficient. In many organizations, however, regular meetings are part of the corporate culture. They can be accommodated by PRINCE2, thanks to the tailoring principle.
If your organisation tailors PRINCE2, you should document the changes made to the method and describe these in the Project Initiation Documentation (PID). In this way, the changes can be audited and provide evidence of compliance with PRINCE2 and corporate standards.
Tailoring whilst remaining compliant
When you are tailoring PRINCE2, you must bear in mind that no part of the method should be ignored or removed. Even on a small project, you will need to address risk, quality and configuration management. If the method is changed too much, you will be in danger of running a ‘PINO’ (that’s ‘PRINCE2 In Name Only’) project.
Organizations can address the PINO problem by referring to the PRINCE2 Maturity Model1. Organizations can use the model to establish their level of compliance with PRINCE22.
The goal of the tailoring principle is to adapt the PRINCE2 method to the needs of your project environment, in order to avoid creating a ‘template-driven’ project management method in which everything is done unquestioningly. Remember that PRINCE2 focuses on information and decisions, rather than just documents and meetings.
Hopefully you’ve learned something about the PRINCE2 principles after reading this eBook. As a PRINCE2 trainer, I often hear my students refer to their employer as being one which manages their projects according to PRINCE2. After delving a little deeper, it becomes apparent that these organizations are not managing their projects according to PRINCE2.
There is only one simple test of whether a project is a PRINCE2 project and it’s nothing to do with how many documents are written by the project management team. Nor is it to do with whether all of the guidance in the PRINCE2 manual3 is being followed. The test is simply whether the project is applying all of the 7 PRINCE2 principles.
In this way, PRINCE2 is not a rigid and ancient text written down on tablets of stone which is unable to be challenged and changed. On the contrary, it’s a workable set of best practices which can be applied to any project, no matter what scale, type of level of complexity.
It’s by applying these principles sensibly on your project that you will gain the greatest benefit of the world’s most popular project management framework.
PRINCE2® is a registered trade mark of the AXELOS Limited
1Office of Government Commerce (OGC). (2010). PRINCE2 Maturity Model (P2MM) . Available: http://www.p3m3-officialsite.com/nmsruntime/saveasdialog.aspx?lID=462&sID=210. Last accessed 2nd July 2013.
2Office of Government Commerce (OGC). (2010). PRINCE2 Maturity Model (P2MM) Self-Assessment. Available: http://www.p3m3-officialsite.com/nmsruntime/saveasdialog.aspx?lID=469&sID=210. Last accessed 2nd July 2013.
3Office of Government Commerce (OGC) (2009). Managing Successful Projects with PRINCE2. London: Stationery Office Books. 342.
Enjoyed this post? Why not download and share the PRINCE2 principles e-book and themes e-book below and explore other great e-books that we have?