So, PRINCE2 Is Too Heavy, Not Agile and Only for Huge Projects. Really?

So, PRINCE2 Is Too Heavy, Not Agile and Only for Huge Projects. Really?

Let me be upfront: I am slightly biased towards PRINCE2 and protective of it. So, when I recently read a blog post repeating several age-old misconceptions, I have to reply.

I have taught PRINCE2, applied it and seen it work well across very different project environments. I have also seen organisations turn it into an oversized collection of templates, meetings and approval points.

That frustration is real and some criticism is deserved.

However, what people are usually describing is PRINCE2 applied without proper understanding or tailoring. They are describing how an organisation has implemented the method, not what PRINCE2 requires.

Three criticisms keep returning:

• PRINCE2 is too heavy on governance.

• PRINCE2 is not aligned with Agile.

• PRINCE2 is only suitable for major government or commercial projects.

Each criticism contains a small element of truth. Each becomes misleading when tailoring is left out of the conversation.

A short history of PRINCE2

PRINCE2 has evolved in four broad stages:

• PROMPT II: (Mid 70s) A private sector method created to improve management of information technology projects.

• PRINCE 1989: A UK government standard for information systems projects.

• PRINCE2 1996 to 2005: A broader, generic project management method that could be used outside information technology.

• PRINCE2 2009 to 2023: A modernised method with stronger focus on principles, tailoring, practical application, people, sustainability, digital, data and artificial intelligence.

The rest of this discussion comes back to two common problems: ignoring the principles and failing to tailor the method. The table at the end of this article provides a little more detail on different editions of PRINCE2

PRINCE2 governance does not have to mean bureaucracy

PRINCE2 includes governance. I make no apology for that. It’s good and necessary, when applied appropriately!

Projects need clarity about:

• Why the investment remains worthwhile.

• Who is accountable for the outcome.

• Who has authority to make decisions.

• What the project is expected to deliver.

• How much freedom the Project Manager has.

• When an issue needs to be escalated.

• Whether the expected benefits remain achievable.

Governance is the means through which a project is directed, authority is delegated, decisions are made and accountability is maintained.

It should not mean endless meetings, unnecessary committees or large documents that nobody reads.

One of the most useful PRINCE2 principles is manage by exception. The Project Manager works within agreed tolerances and involves senior decision-makers only when the project is expected to exceed those limits. The same principle applies to delivery teams: they are given clear authority (empowered) to act, and the Project Manager steps in only when agreed tolerances are exceeded or likely to be exceeded.

When applied properly, this reduces interference. It creates boundaries within which the Project Manager and delivery teams can make decisions.

Problems arise when organisations confuse governance with administration. They may create:

• Reports that repeat information available elsewhere.

• Approval points that add delay but no value.

• Large templates completed only because the process says so.

• Project Boards that become working groups.

• Multiple committees discussing the same decisions.

• Controls designed for a major programme and imposed on every small project.

PRINCE2 does not require every project to produce the same volume of documentation. It requires the right management information to be available to the right people. That information could be held in a dashboard, collaboration platform, existing business system or concise document.

The latest PRINCE2 guidance emphasises applying and tailoring the method to the project context rather than forcing every project through the same process. Governance should protect delivery, not obstruct it.

PRINCE2 and Agile are not opposites

The suggestion that PRINCE2 is not aligned with Agile often comes from treating Agile and governance as competing ideas.

They are not.

Agile delivery helps teams learn, respond to change and deliver value incrementally. Governance ensures that the work remains justified, accountable and connected to organisational objectives.

An Agile team still needs to understand:

• What outcome it is trying to achieve.

• Who owns the investment decision.

• Which constraints must be respected.

• Which risks need wider attention.

• When a significant issue should be escalated.

• Whether the work is still delivering enough value to continue.

PRINCE2 can provide this project-level direction without dictating how a delivery team should organise its daily work.

A delivery team might use:

• Scrum to support iterative development.

• Kanban to visualise and manage workflow.

• Backlogs to organise and prioritise work.

• Regular reviews to gather feedback.

• Retrospectives to improve how the team works.

PRINCE2 might be used alongside these approaches to support:

• Continued business justification.

• Project accountability.

• Agreed tolerances.

• Investment decisions.

• Risk and issue escalation.

• Alignment with organisational objectives.

This is not an automatic or effortless combination. Organisations must carefully align roles, planning, reporting and decision authority. Otherwise, the Project Manager, Product Owner, Scrum Master and governance group may duplicate work or work against one another.

But these are design problems, not proof that PRINCE2 and Agile are incompatible. PRINCE2 has been Agile-ready since 2009 (Version 5), and that thinking has been part of the method ever since.

PRINCE2 does not replace Scrum or Kanban

PRINCE2 and Agile delivery approaches are not trying to solve the same problem.

PRINCE2 helps an organisation direct and manage a project as a temporary organisation and business investment.

Scrum and Kanban help teams organise, prioritise and deliver work.

There is some overlap, but neither needs to replace the other.

PRINCE2 also does not replace:

• Product management.

• Business analysis.

• Organisational change management.

• Software development practices.

• Engineering or construction controls.

• Benefits management after a project closes.

A project may need several complementary methods and capabilities.

PRINCE2 7 can be tailored to projects using predictive, Agile or hybrid delivery. PRINCE2 Agile provides more specific guidance on combining PRINCE2 project management with Agile behaviours, roles and practices.

PRINCE2 Agile Version 2 covers Agile thinking, value-focused delivery, adaptive planning, stakeholder engagement, risk, progress measures and scalable Agile working. It is intended for people delivering projects in Agile environments, including Project Managers, project support staff, Product Owners and wider delivery teams.

The better question is not:

Should we use PRINCE2 or Agile?

It is:

What level of project direction and governance do we need, and which delivery approach best suits this stage of the project?

PRINCE2 is not only for huge projects

PRINCE2 works on projects of any size, risk or complexity. Tailoring the method to suit the project has been a guiding principle since 2009 (Version 5).

This does not mean every small activity should become a formal PRINCE2 project. Some work is better managed through normal operations, team leadership or a simple task board.

However, when a small initiative does need project management, PRINCE2 can be applied proportionately.

A small internal project does not automatically need:

• A large Project Board.

• A separate person for every responsibility.

• Extensive reports.

• Multiple management stages.

• Complicated change control.

• A large collection of standalone documents.

For a smaller project, an organisation might:

• Combine compatible responsibilities.

• Use a one-page business case.

• Maintain a simple delivery plan.

• Keep risks, issues and decisions in one shared register.

• Use an existing meeting for progress reviews.

• Provide a simple low-tech dashboard rather than a formal report.

• Use a task board or backlog to manage delivery.

• Escalate only when agreed tolerances are threatened.

Current guidance on adapting PRINCE2 for smaller organisations recommends simplifying management products, combining responsibilities where appropriate and scaling the processes to match the project’s size and complexity. Proportionality is the point.

A small internal training project should not be managed like a major infrastructure investment. Equally, a high-value and high-risk initiative should not depend on an informal task list and an occasional status meeting.

PRINCE2 tailoring is not optional

The real problem is often not PRINCE2. It is PRINCE2 without tailoring.

Tailoring can include adjusting:

• Roles and responsibilities.

• The number and length of management stages.

• Reporting frequency and format.

• Meeting frequency.

• The formality of decisions.

• The tools used to hold management information.

• Risk and change controls.

• The relationship with Scrum, Kanban or other delivery approaches.

However, tailoring does not mean removing every control or selecting isolated parts without understanding how they work together.

Poor tailoring can create:

• Unclear accountability.

• Weak escalation routes.

• Missing business justification.

• Inadequate risk management.

• Unreliable progress information.

• Governance that exists only in name.

Tailoring is the discipline of keeping the controls that add value and applying them at a level that matches the project’s risk, value and complexity.

PRINCE2 should fit the project. The project should never be inflated to fit someone’s oversized interpretation of PRINCE2.

Why the ‘PRINCE2 is too heavy’ misconception persists

Training is sometimes mistaken for implementation

PRINCE2 training always explains the complete method. Learners need to understand how its principles, practices, processes, roles and management products work together.

That does not mean every project needs every element applied with the same level of formality.

Knowing the complete method enables informed tailoring. It should not lead to mechanical implementation.

Large project controls become the organisational default

An organisation may create extensive controls for a major, high-risk programme. Those controls then become mandatory for every project.

Over time, people associate the organisation’s templates and approvals with PRINCE2 itself.

The method gets blamed for controls the organisation added and never reviewed.

Agile is mistaken for an absence of governance

Agile teams need freedom to make delivery decisions. They also need clear outcomes, decision authority and escalation routes.

Agility does not mean operating without accountability.

Good governance creates boundaries within which teams can adapt safely and make decisions quickly.

Governance is confused with delivery management

PRINCE2 does not need to control every activity performed by the delivery team.

Project governance should focus on investment, accountability, risk, progress and outcomes. Delivery teams should use the practices most appropriate to their work.

A simple example: proportionate PRINCE2 on a small project

Imagine a small project to introduce a new internal course booking process.

A proportionate approach might include:

• A one-page project brief describing the problem, outcome and scope.

• A short business justification approved by the sponsor.

• A named Project Manager with clear authority.

• A small team using a Kanban board.

• A prioritised backlog of process and system improvements.

• A combined risk, issue and decision log.

• A short progress update every two weeks.

• Agreed tolerances for time, cost and scope.

• A final review of outcomes, lessons and follow-up actions.

There is governance. There is accountability. There is also room for the team to test ideas, gather feedback and adapt the solution.

That is not heavy project management.

It is proportionate project management.

When PRINCE2 really does become too heavy

PRINCE2 can become bureaucratic. I have seen it happen.

It becomes burdensome when:

• Tailoring is ignored.

• Templates become more important than decisions.

• Every responsibility becomes a separate committee.

• Reports are produced without a clear audience or purpose.

• Stage boundaries become long administrative pauses.

• Agile events are duplicated by separate project meetings.

• Teams are not trusted to operate within tolerances.

• The Project Management Office measures document completion rather than project value.

• New controls are continually added but old controls are never removed.

Not every heavy control is caused by PRINCE2. Regulatory requirements, contracts, audit expectations, complex suppliers and low organisational trust can also increase the level of control required.

However, organisations should still ask whether each control supports a decision, addresses a genuine risk or improves the likelihood of success.

If it does none of these things, why is it there?

Is your PRINCE2 implementation proportionate? A checklist

Consider these questions:

• Does every report have a clear audience and purpose?

• Are decision rights understood?

• Are tolerances clearly defined and genuinely delegated?

• Do senior leaders intervene only when necessary?

• Is the level of control based on risk and complexity?

• Are management products combined where practical?

• Are Agile events and project reports duplicating one another?

• Can the team explain why each control exists?

• Can different projects use different delivery approaches?

• Is the business justification reviewed when circumstances change?

• Are outdated controls ever removed?

If the answer to several of these questions is no, the problem may not be PRINCE2.

It may be how PRINCE2 has been implemented.

Final thought

PRINCE2 is awesome, wait there’s that bias again.

However, PRINCE2 can become bureaucratic. Agile can also become rigid when its ceremonies replace learning, collaboration and value delivery.

Any method can be applied mechanically. The answer is not to reject governance. Nor is it to add more paperwork.

It is to apply enough project management for the project’s risk, value and complexity.

PRINCE2 is not inherently:

• Heavy on administration.

• Opposed to Agile.

• Limited to government.

• Reserved for major commercial projects.

• A fixed collection of templates and meetings.

It is an integrated project management method that depends on informed and deliberate tailoring.

I am protective of PRINCE2 because I have seen what it can achieve when it is understood and applied well. I am equally critical when organisations use its name to justify unnecessary bureaucracy.

Do not judge PRINCE2 by its worst implementations, just as we should not judge Agile by teams that hold daily stand-ups but never deliver meaningful value.

PRINCE2 should fit the project. A project should never be forced to fit PRINCE2.

PROMPT II, PRINCE and PRINCE2 versions: a quick reference

Assumption: This is for a simple summary, not a detailed technical change log.

Current naming note

• PRINCE2 2017 and PRINCE2 6th Edition refer to the same method content. The 6th Edition label was introduced from 01-Jan-2020 as a rename, not as a new version.

• PRINCE2 7 is the current major edition and is the version most learners should use unless their organisation or course specifically requires PRINCE2 6th Edition.

Lumify Work New Zealand, formerly Auldhouse, is an Accredited Training Organisation with Platinum Partner status for PeopleCert courses and certifications. Explore PRINCE2 7 Foundation, PRINCE2 7 Practitioner and PRINCE2 Agile, or download the PRINCE2 eBook to compare pathways. Talk to us about tailoring PRINCE2 to how your organisation actually delivers.