How do you stop a project from derailing into chaos, missed deadlines, and a budget that's been spent twice over? The seven PRINCE2 principles are the core beliefs that make any project – from building a mobile app to organising a music festival – consistently successful. For the PRINCE2F exam, you must not only name these principles but also understand how each one acts as a 'health check' to keep a project alive, focused, and under control.
Jump to a section
Ever tried to renovate a kitchen with a friend and ended up arguing about paint colours, buying the wrong sink, and running out of budget halfway through? What if, instead, you had a clear set of rules that every kitchen renovation followed, ensuring you stayed on budget, learned from past mistakes, and knew exactly who was responsible for choosing the tiles?
That set of rules is what PRINCE2 principles are for project management. The 'continued business justification' principle means you constantly ask, 'Is this new oven still worth the cost?' before every major purchase. 'Learn from experience' means you check your neighbour's renovation diary to avoid their mistake of ordering a fridge that didn't fit. 'Defined roles and responsibilities' means one person chooses the worktop, another handles the plumber, and everyone knows who does what. 'Manage by stages' breaks the renovation into chunks: first demo, then electrics, then fitting. 'Manage by exception' lets you spend small amounts freely but requires boss approval if you want to knock down a load-bearing wall. 'Focus on products' means you describe exactly what the finished kitchen looks like – right down to the handle style – before you start. 'Tailor to suit the project environment' lets you simplify these rules for a tiny bathroom redo, but enforce them strictly for a full-house renovation. Together, these seven principles turn chaotic DIY into a predictable, controlled process.
The seven PRINCE2 principles are the foundation of the entire methodology. Think of them as the non-negotiable rules that every PRINCE2 project must follow. If a project ignores even one principle, it is not a PRINCE2 project. These principles are universal, meaning they apply to any project, whether it's installing new software in a bank, building a bridge, or launching a marketing campaign. They are empowering, giving the project manager and team the authority to make decisions. They are enabling, providing the framework for success, not rigid bureaucracy. And they are based on proven practices from thousands of real projects over decades.
The first principle is 'continued business justification'. This means a project must always have a valid reason to exist. Before the project starts, you create a 'business case' – a document that explains why the project is needed, what benefits it will bring, and how much it will cost. But you don't just file it away. Throughout the project, at the end of every stage, you revisit the business case. If the costs have skyrocketed or the benefits are no longer relevant, the project should be stopped. For example, imagine a company deciding to build a new mobile app for ordering office supplies. Halfway through, a competitor releases a similar app for free. The business case now shows the project is no longer profitable. The principle demands you stop the project, not throw good money after bad.
The second principle is 'learn from experience'. PRINCE2 insists that you actively look for lessons from previous projects. At the start of your project, you review a 'lessons log' from similar past projects. What went wrong? What went well? You then apply that knowledge. Throughout your project, you continuously record new lessons. At the end, you update the lessons log so future teams can learn from you. This prevents the same mistakes from being repeated endlessly. A real-world example: a previous construction project discovered that a certain type of concrete took too long to dry in cold weather. The new project, using the lessons log, schedules concrete pouring for warmer months, saving weeks of delay.
The third principle is 'defined roles and responsibilities'. This principle ensures everyone involved in the project knows exactly what they are supposed to do. PRINCE2 defines three primary interests: the business interest, the user interest, and the supplier interest. Each interest is represented by specific roles. For example, the 'Executive' role represents the business and is ultimately accountable for the project's success. The 'Senior User' represents the people who will use the project's product. The 'Senior Supplier' represents the team building the product. This prevents confusion, where one person thinks another is handling a task. It eliminates the common problem of 'I thought you were doing that'.
The fourth principle is 'manage by stages'. A PRINCE2 project is divided into discrete 'management stages'. You plan the current stage in detail, and the next stage in less detail. You only plan the next stage in full once the current stage is complete and the business case is still valid. This breaks a large, risky project into smaller, more manageable chunks. At the end of each stage, the project board (the senior decision-makers) reviews progress and decides whether to proceed. For example, a software development project might have stages: Initiation, Design, Build, Test, and Deployment. At the end of the Build stage, the board checks if the budget is still on track before authorising the Test stage.
The fifth principle is 'manage by exception'. This principle sets tolerances for time, cost, quality, scope, risk, and benefits. The project manager is allowed to manage the project as long as the project stays within these tolerances. If a tolerance is forecast to be exceeded (for example, the project will be two weeks late), the project manager must 'escalate' the issue to the project board for a decision. This prevents micro-management from senior managers while still keeping them informed of significant problems. It's like giving a child a budget for a school trip. They can spend freely on snacks, but if they want to buy a new phone, they must ask permission.
The sixth principle is 'focus on products'. This principle states that a project's primary focus should be on defining and delivering its products (the outputs), not on the activities needed to create them. Before any work begins, every product must be described in a 'Product Description'. This description defines the product's purpose, composition, quality criteria, and format. The project is considered successful only when all products have been delivered and meet their quality criteria. For example, before building a website, you describe the 'Homepage' product in detail: it must have a company logo, a search bar, three featured products, and load in under two seconds. You build to that specification, not just 'build a homepage somehow'.
The seventh principle is 'tailor to suit the project environment'. PRINCE2 is not a one-size-fits-all approach. It must be 'tailored' to fit the specific project's size, complexity, importance, capability, and risk. A small, low-risk project with a experienced team can use a simplified version of PRINCE2, with fewer documents and shorter meetings. A large, high-risk project will use the full, detailed framework. Tailoring ensures PRINCE2 is never too heavy or too light. It is not 'dumbing down' the method; it is making it appropriate. For example, a project to rearrange office furniture might skip the detailed 'Risk Register' and just have a simple list of risks, while a nuclear power plant project would need a comprehensive risk management process.
Establish the Business Case
Before any project work starts, you create a business case that justifies the project. This document outlines the reasons, benefits, costs, and risks. This step ensures the project is worthwhile before committing resources.
Review Past Lessons
At the very beginning, the project manager reviews the lessons log from previous, similar projects. This step applies the 'learn from experience' principle and prevents repeating past mistakes. The project team also records any lessons learned as the project progresses.
Define Roles and Responsibilities
The project board is formed, including the Executive, Senior User, and Senior Supplier. Each role's responsibilities are clearly documented. This step ensures everyone knows what they are accountable for, eliminating confusion.
Plan and Approve a Management Stage
The project is divided into management stages. The project manager creates a detailed plan for the first stage and an outline plan for the next. The project board reviews the business case and the stage plan, then authorises the stage to proceed. This step applies both 'manage by stages' and 'continued business justification'.
Set Tolerances and Manage by Exception
At the start of the project, the project board sets tolerances for time, cost, quality, scope, risk, and benefits. The project manager manages the stage within these tolerances. If a tolerance is about to be exceeded, the project manager escalates the issue to the project board. This step applies the 'manage by exception' principle.
Define and Deliver Products
Each product is defined in a product description before work begins. The team builds the product to meet the quality criteria in the description. The project is considered successful only when all products are delivered and accepted. This step applies the 'focus on products' principle.
Tailor the Method to the Project
Throughout the project, the project manager tailors the PRINCE2 processes, themes, and documentation to fit the project's size, complexity, and risk. For example, a small project may use a simplified risk register. The principles themselves are never changed, only their application.
An IT professional, let's call them Priya, is a project manager for a mid-sized retail company. The company wants to launch a new customer loyalty mobile app. Priya is using PRINCE2. How do the seven principles guide her daily work?
First, 'continued business justification'. Before the project is even approved, Priya works with the business analysts to create a business case. They calculate that the app will increase customer retention by 15% and generate an extra £500,000 in revenue per year, costing £200,000 to build. The project is approved. Six months into development, a major competitor launches a similar app with better features. Priya's team re-forecasts the benefits; they are now only 5% retention increase. Priya presents this to the project board. They review the business case and decide to restructure the app to offer unique features, maintaining the justification. If the justification had disappeared, they would have closed the project.
Second, 'learn from experience'. Priya's company previously built a desktop website that failed because the checkout process was too complicated. The lessons log from that project explicitly says: 'Keep checkout to three steps maximum, and test with users early.' Priya ensures the mobile app's checkout is designed with exactly three steps. Later, during development, a developer discovers that a third-party payment system causes a critical bug. They record this in the current project's lessons log. At the end, this lesson helps future projects avoid that vendor.
Third, 'defined roles and responsibilities'. The project board consists of the Executive (the Chief Marketing Officer), the Senior User (the Head of Customer Loyalty), and the Senior Supplier (the IT Director). They don't code; they make strategic decisions. The project manager, Priya, manages the day-to-day work. The team lead manages the developers. Everyone knows who to go to for budget, for user requirements, and for technical solutions. No one is confused.
Fourth, 'manage by stages'. Priya divides the project into four stages: Initiation, Design & Prototype, Build & Test, and Launch. After the Initiation stage, the board reviews the detailed plan and budget for the Design & Prototype stage. They approve it. At the end of the Design stage, the board sees the prototype. They decide the design is good and authorise the Build stage. This stage-by-stage control prevents the project from racing ahead without oversight.
Fifth, 'manage by exception'. The project board sets tolerances: the project must be completed within 12 months plus or minus one month, and the cost cannot exceed £220,000. For months, the project runs smoothly within these tolerances. Then, a key developer quits. Priya recalculates the timeline; the project will now finish two months late, exceeding the one-month tolerance. She must escalate this to the project board immediately. They decide to hire a contractor, which costs £10,000 extra but gets the timeline back within tolerance. Priya doesn't need permission for every small hire, only when the tolerances are exceeded.
Sixth, 'focus on products'. Before writing any code, the team defines every product of the project. One product is the 'User Profile Screen'. Its product description specifies it must show the user's name, points balance, and recent purchases, and it must work on both iOS and Android. The team builds exactly to that specification. The quality check passes only when the screen meets all those criteria. This prevents the common problem of 'we built what we thought you wanted, not what you actually wanted'.
Seventh, 'tailor to suit the project environment'. Because this is a small-to-medium app with a core team of five developers, Priya tailors the PRINCE2 processes. She does not create a 50-page risk register; she uses a single spreadsheet. She shortens the weekly highlight report to a single page. She skips the formal 'End Project Report' and instead presents a summary at a board meeting. This keeps the method lightweight and useful, not bureaucratic.
The PRINCE2F exam tests your ability to identify and describe the seven principles. This is a straightforward but high-volume area. Expect approximately 10–15% of your exam questions to directly relate to these principles. The exam focuses on recall, application, and differentiation.
First, you must be able to name all seven principles from memory. The exam will often ask a direct question like: 'Which PRINCE2 principle is being applied when a project checks the business case at the end of each stage?' The answer is 'continued business justification'. You need to know each principle by its exact name. Common trap: the exam might phrase 'manage by exception' as 'management by exception' – both are correct, but the official name is 'manage by exception'.
Second, you must be able to distinguish between the principles and the themes or processes. Many questions will describe a scenario and ask you to identify which principle is being used. For example: 'A project manager reviews the lessons log from a previous project to avoid past mistakes. Which principle is this?' The answer is 'learn from experience'. A common trap is confusing 'learn from experience' with 'manage by stages' because both involve review points. But 'learn from experience' is specifically about using past knowledge, while 'manage by stages' is about dividing time into chunks.
Third, you must understand the key characteristics of each principle. For example, 'manage by exception' always involves tolerances and escalation. 'Focus on products' always involves product descriptions. 'Tailor to suit the project environment' always involves adapting the method to the project's size and risk.
Fourth, the exam loves to test the 'four characteristics' of the principles. Remember the acronym 'JUEP' (Universal, Empowering, Enabling, Proven). A question might ask: 'Which of the following is NOT a characteristic of the PRINCE2 principles?' and list options like 'Universal', 'Confidential', 'Enabling', 'Proven'. The answer is 'Confidential'.
Fifth, be careful with 'manage by stages' versus 'manage by exception'. 'Manage by stages' is about breaking the project into sequential steps with decision points between them. 'Manage by exception' is about setting tolerances and escalating only when they are breached. They are two different principles, but they work together.
Sixth, the principle 'continued business justification' is often tested in the context of the business case. Remember that the business case must be reviewed at the end of each stage, not just at the start. A trap question might say: 'The business case is created at the start of the project and never revisited.' This is false; it must be revisited regularly.
Seventh, 'focus on products' is frequently confused with 'focus on activities'. A trap question describes a project that lists all the activities (coding, testing, meeting) but not the actual outputs. This violates the 'focus on products' principle. The correct approach is to first define what you are building (the products), then plan the activities to build them.
Finally, memorise the seven principles as an ordered list: 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 environment. Using a mnemonic like 'CLM MFT' (first letters: C, L, D, M, M, F, T) can help. Or create a phrase like 'Cats Love Dark March Months For Treats'. Practice identifying which principle is being applied in a given sentence. You can expect at least one question that gives you a scenario and asks you to pick the correct principle from a list of four options.
The seven PRINCE2 principles are mandatory, not optional, for any project to be considered a PRINCE2 project.
The principle of 'continued business justification' requires the business case to be reviewed at the end of every management stage, not just at the start.
'Learn from experience' actively uses a lessons log to capture and apply knowledge from past projects throughout the current project's lifecycle.
'Manage by stages' breaks the project into discrete stages with detailed planning only for the current stage and outline planning for the next.
'Manage by exception' sets tolerances for cost, time, quality, scope, risk, and benefits, and requires escalation only when these tolerances are forecast to be breached.
'Focus on products' means defining and describing every project output (product) in detail before any work begins, to ensure the customer gets exactly what they want.
The four characteristics of PRINCE2 principles are: Universal, Empowering, Enabling, and Proven (mnemonic: JUEP).
These come up on the exam all the time. Here's how to tell them apart.
Manage by Stages
Breaks the project into sequential time blocks (stages).
Requires detailed planning for the current stage only.
The project board makes a go/no-go decision at the end of each stage.
Manage by Exception
Sets tolerances for cost, time, quality, scope, risk, and benefits.
Allows the project manager to work within those tolerances without interference.
Requires escalation to the project board only when tolerances are forecast to be exceeded.
Focus on Products
Defines the project's outputs (products) in detail before work starts.
Uses product descriptions to specify quality criteria.
Success is measured by delivering all products meeting their quality criteria.
Focus on Activities
Plans and lists activities (tasks) first, without defining outputs.
Often leads to delivering something different from what the customer wanted.
Success is measured by completing all activities on time, not necessarily delivering the right outputs.
PRINCE2 Principle
A fundamental, mandatory rule that governs the entire project.
Must always be applied – cannot be ignored or omitted.
Examples: 'continued business justification', 'learn from experience'.
PRINCE2 Theme
A specific area of project management that needs to be addressed.
Can be tailored in how it is applied, but must be addressed.
Examples: 'business case theme', 'risk theme', 'quality theme'.
Project Manager Role (Manage by Exception)
Manages the project day-to-day within agreed tolerances.
Escalates issues to the board only when tolerances are breached.
Responsible for monitoring progress against tolerances.
Project Board Role (Manage by Exception)
Sets the tolerances at the start of the project and each stage.
Makes decisions only when escalated exceptions occur.
Provides direction and control without daily interference.
Mistake
PRINCE2 principles are optional guidelines that can be ignored if the project manager disagrees.
Correct
PRINCE2 principles are mandatory for a project to be called a PRINCE2 project. If you ignore one, you are not using PRINCE2.
People often confuse principles with 'best practice' suggestions. They think they can pick and choose, but PRINCE2 defines principles as non-negotiable.
Mistake
'Manage by stages' means you plan the entire project in detail from start to finish at the beginning.
Correct
'Manage by stages' means you only plan the current stage in detail and the next stage in outline. Detailed planning is done incrementally, stage by stage.
Many project management methods require a detailed upfront plan. Beginners assume PRINCE2 is the same, but the principle actively prevents this.
Mistake
'Manage by exception' means the project manager can make all decisions without any oversight.
Correct
The project manager manages within agreed tolerances. If a tolerance is forecast to be exceeded, the project manager must escalate to the project board.
The word 'exception' sounds like 'exemption'. Beginners think it means the manager is exempt from control, but it actually means the manager's control is limited to normal parameters.
Mistake
'Focus on products' means the project must deliver physical products like software or hardware; services are not considered products.
Correct
In PRINCE2, a 'product' is any output – physical, digital, or even a service. A training course or a consulting report is a product.
The everyday use of 'product' often implies a physical good. Beginners fail to realise PRINCE2's broader definition includes any deliverable.
Mistake
'Tailor to suit the project environment' means you can change the PRINCE2 principles themselves for a small project.
Correct
You cannot change the principles. You can tailor how you apply the themes and processes, but every principle must still be followed in some form.
Beginners think 'tailor' means 'ignore'. They assume a small project doesn't need 'learn from experience', but tailoring means adapting the method, not discarding principles.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, they are mandatory. Even for a small project, you must apply all seven principles in a way that is appropriate for the project's size. You can tailor how you apply them, but you cannot ignore any principle.
A principle is a fundamental rule or belief that guides the project, while a theme is a specific area of project management that must be addressed, like risk or quality. Principles are 'what you must believe', themes are 'what you must manage'.
At the start, you review the lessons log from past projects. During the project, you record new lessons in the current project's log. At the end, you update the organisational lessons log so future projects can benefit from your experience.
It means the project manager has a budget and a deadline (tolerances). They can make decisions freely as long as they stay within those limits. If they go over the limit, they need permission from the project board. It prevents micro-management.
No. 'Continued business justification' requires a business case. Without it, you cannot justify the project's existence, and you are not following the PRINCE2 methodology.
No. Tailoring means making the method appropriate for the project. For a simple project, you might use fewer documents. For a complex project, you might need more detail. It's about effectiveness, not laziness.
Use a mnemonic like 'CLM MFT' for the first letters: Continued business justification, Learn from experience, Defined roles, Manage by stages, Manage by exception, Focus on products, Tailor to suit. Or create a phrase like 'Cats Love Dark March Months For Treats'.
You've finished PRINCE2 Principles Overview. Continue through the PRINCE2F study guide to build a complete picture of the exam.
Done with this chapter?