Home / PRINCE2 / Agile, PRINCE2 and PMBoK – How They Fit Together

Agile, PRINCE2 and PMBoK – How They Fit Together

Agile, PRINCE2 and PMI’s Project Management Body of Knowledge (PMBoK) are all complementary parts of project management. They are parts of a whole, but not THE whole.

Let me explain further.

The Whole

The whole is everything that project management embodies – the processes, the methods, the techniques, the tools, the behavioural or people skills required by the people working in a project environment. The whole is also support for the journey to a stable use of a Target Operating Model; the future state of business as usual or “just how we do it around here (now)”.

Let’s take a look at the three popular parts, starting with PRINCE2:

What is PRINCE2?

PRINCE2PRINCE2 is a control structure, a framework, a skeleton, the pipe-work through which project control information flows down and up. Down to grant authority over resources and decision-making and set targets, up to reports status and raise the need for intervention (exceptions).

PRINCE2 doesn’t tell us how to know if we are in exception but it lets us know who to tell, what information to give them and the management decisions we should all be taking when we decide we are. I think of it as the middle tier of a three layer organisation cake.

And what are Agile and PMBoK?

PMBoKThe bottom tier contains (or should contain) activity inspired by the PMBoK and/or inspired by agile procedures.

Both are collections of tools and techniques for measuring status and building baselines so we can travel to the projects destination in a coordinated whole and tell when we are in or out of exception.

Agile includes mindset and product development guidance, often with quiet rigid procedures. PMBoK is more a library of interlinked activities described via the inputs, tools and techniques and outputs. The interlinks are never obvious in the manual.


All three tiers – strategy at the top – management control in the middle and development – technical specialists at the bottom, should but rarely are, suffused with the mindset of agility and value creation.

The Agile community have shown the power of mindset and the limitations to its successful introduction. It’s easiest to introduce to those with less hierarchical structure and traditional layers of authority.

The mindset is the piece of most significance, the bit that most often trips up those rushing for the latest silver bullet. Agile is an amplifier of culture and a bad starting culture will exacerbate the stresses more than deliver solutions.


New Thinking for the21st Century?


Ford Assembly Line 1913

Agile uses insight from Complex Adaptive Systems Thinking.

Systems thinking realises that you can only know the system as a whole by looking outside it at its interactions.

Historically project management has grown from engineering. Engineering uses the approach that you understand how something works by looking at its component parts. This is the technique of decomposition. Unfortunately breaking things down removes the essential qualities of the whole system that we’d otherwise study.

PRINCE2 and PMBoK are the legacy of ‘projects are engineering’.

When we apply systems thinking to managing change the best control approach we can adopt is frequent inspection and adaptation over pre-planned in advance actions.

Approaches based on the idea of pre-plan have a long history that resulted from the work of Henry Fayol, Henry Ford, FW Taylor and others.


By Snowded (Own work) [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons

It isn’t wrong but it isn’t the whole story. How often in management circles do you hear “we need to be pro-active not reactive”? The response should be “NO; we need to understand when each approach is best and when each is actually damaging or dangerous” Here Dave Snowden’s Cynefin model offers insight.

Defined Procedures

Setting aside philosophy, mindset and values to focus on mechanics then – both agile as a set of procedures and PMBoK are descriptions of steps, tools and techniques by which we can build plans and report status.

Assumed Product Development Approach

PMBoK doesn’t insist but is written assuming that we progress through a project’s scope by gathering all the requirements before doing all the design.

Agile is at the other extreme and says ‘do all the development phases to the smallest useful subset of scope and then start again with the next subset.’

PRINCE2 delivers a structure where it can legitimately say:

“Here we don’t care which order you do development in, let’s negotiate resource needs, agree authorisation to work then report status, log configuration data from quality control activities and tell us when you need help (exceptions) and eventually that you’ve handed over the results and are done.”

Pros and Cons

One approach makes high integrity solutions more likely at the risk of complete failure through late detection of misunderstood intent while the other offers partial success, fast cycle-time feedback and graceful exit with some delivered value for money but only where the solution allows incremental delivery.

You can’t usefully deliver one wing of an airplane but watching your favourite BoxSet on NetFlix as each episode is released is much better than waiting until 8 episodes to make a whole DVD.

A 21st century project professional should not enter absolute arguments about one over the other but appreciate how to plug them together to gain the advantages of each.

Go read, adopt, sign Alistair Cockburn’s Oath of NON-Allegiance!


PMBoK is a project toolkit for building schedules and budgets and teams, for controlling procurement and risk and quality.

Most agile frameworks are half product development approaches and half project scheduling and budgeting mechanisms that overlaps PMBoK to reinvent wheels with new names.

PMBoK explains tools like Earned Value while agile uses Burn Charts and the Measurable News (page 32) give us formal mathematical proof that the two are the same save their names.

A sensible PRINCE2 practitioner should pick the best product development approach for each product or team in their project’s scope.

Use the Burn Charts or Earned-Value and call planning ‘Rolling Wave’, ‘Stages’ or ‘Release and Sprint’ depending on what keeps everyone happy.

Also focus on ‘value (agile label)’ or ‘benefits (PRINCE2 label)’.

A sensible PMBoK user and agile proponent should recognise that PRINCE2 brings useful structure to interface to the rest of the organisation’s deep-rooted constraints in hierarchy, annualised budgeting, matrix resource structures, routine reporting and dislike of change.




If you enjoyed this post, make sure you subscribe to our RSS feed!

About Simon Harris

Simon Harris
Simon is a project management veteran with 30 plus years experience of projects gained mostly within large-scale blue-chip environments across finance and banking IT, defence engineering, oil & gas, government and not for profit. Simon has set-up and run PMO for several programmes and organisations.

Simon’s passion is to improve the state-of-the-art in organisation’s ability to cope with change. His thinking rests on the observation that organisations have to balance Run the Organisation with Change the Organisation. Project management is necessary but insufficient. Organisations need a broader and deeper response to change whether discretionary, gradual, irresistible or sudden. Simon welcomes Linkedin connections and you can find out more about Simon from his own website - Logical Model

Discover the new Adaptive Strategic Execution Programme

%d bloggers like this: