By Paulius Petravicius
Sam’s supplier interface has failed its integration test. The Spotter customer portal still looks convincing in a demonstration, but customers cannot reliably retrieve their account details. The delivery forecast is slipping. On Monday, the project board asks whether the stage remains within tolerance. On Tuesday, a delivery colleague asks what has changed across scope, schedule and risk.
Sam and Spotter are fictional. The awkward conversation is familiar: two people discuss the same problem using different project management vocabularies. Sam needs a decision about the release, with clear ownership of the consequences.
PRINCE2 and the PMBOK Guide are different kinds of thing: on a live project, you usually recognise which perspective someone is using rather than choose one instead of the other. PRINCE2 supplies a method for organising and controlling the work; the Guide offers a broader reference for examining how that work is managed. Both can help Sam explain the failed interface.
Three different things
PRINCE2: A project management method, including roles, tolerances, management products and processes. This article discusses Version 7.
PMBOK Guide: PMI’s guide to the Project Management Body of Knowledge. The Eighth Edition connects principles, performance domains and Focus Areas.
PMP: PMI’s Project Management Professional certification, distinct from the Guide itself. See PMI’s definition of PMP.
Education framing: The comparisons and mapping below are InsightSpotter teaching aids, not an official crosswalk. Organisations tailor their own arrangements; a familiar label does not establish local authority.
This article does not recommend which qualification to take.
PRINCE2 vs PMBOK at a glance
| Question | PRINCE2 Version 7 | PMBOK Guide Eighth Edition |
|---|---|---|
| What is it? | A project management method. | A guide to project management knowledge and practice. |
| What does it emphasise? | An integrated method, including responsibilities, products, stages and delegated control. | Principles, management domains and adaptable guidance across approaches. |
| What question does it help answer here? | Who can authorise a response when the forecast exceeds Sam’s authority? | What management concerns must Sam examine before recommending a response? |
| Who might use the language locally? | A board, sponsor, PM or PMO working within a tailored PRINCE2 method. | PMs, delivery leads, specialists or a PMO drawing on PMI guidance. No single role owns it. |
Those last two rows describe possible organisational use, not rules assigning ownership. The emphasis is also a teaching choice: PRINCE2 covers more than escalation, and PMBOK includes governance.
Our Scrum vs sprint explanation tackles a similar category confusion. Establish the relationship before comparing labels. Here, the useful distinction is between a method and a knowledge reference, with a certification kept separate.
What PRINCE2 Version 7 brings to the conversation
PeopleCert’s Version 7 overview identifies seven principles, seven practices and seven processes, alongside roles and an explicit people element. For Sam, that structure becomes useful when it makes delegation and the next decision clear.
Consider management by exception. A tolerance defines an agreed limit within which a management level can act. If the forecast threatens that limit, the conversation moves to the authority that delegated it. PeopleCert’s discussion of project success connects delegated authority with tolerances and emphasises defined products and quality expectations.
For Spotter, this language directs attention to the promised interface, its acceptance evidence, the current stage forecast and the person authorised to approve a different course. Routine reporting continues, but an emerging exception needs timely attention. The failed test should prompt a forecast review before the promised date is actually missed.
The weakness appears when the organisation preserves the paperwork but loses the decision. A beautifully formatted report cannot compensate for an absent sponsor or unclear delegation. Sam still has to establish who can decide, what evidence they need and when delay makes the options worse.
What PMBOK 8 brings to the conversation
PMI’s PMBOK Guide page describes the Eighth Edition as combining six principles and seven performance domains, with adaptable process guidance. Its domains are Governance, Scope, Schedule, Finance, Stakeholders, Resources and Risk.
For Spotter, that breadth invites a different pass through the same incident. A supplier defect may change support staffing, launch communications, operating costs and the value of the first release. A technically credible fix can still be a poor recommendation if those consequences are missing.
The five Focus Areas are Initiating, Planning, Executing, Monitoring and Controlling, and Closing. They help organise management activity; they should not become five rigid delivery phases. A PMI presentation by Kelly Heuer, hosted by NTT DATA shows how these intersect with the domains.
Sam can therefore inspect a schedule consequence while planning a response, implementing it and checking its effect. These concerns overlap in the work. Naming a domain helps organise the analysis, but Sam must still identify the local decision owner and obtain usable evidence.
A teaching map: practices, domains and Focus Areas
This is an InsightSpotter teaching aid, not an official PRINCE2–PMBOK crosswalk. Each row suggests questions to explore on Spotter. It does not claim that the terms are equivalent or that one column fully covers another.
| PRINCE2 practice | PMBOK 8 domains to explore | Focus Areas to consider on Spotter | Useful project question |
|---|---|---|---|
| Business case | Governance; Finance | Initiating; Planning; Monitoring and Controlling | Does the revised release still justify its cost and expected value? |
| Organising | Governance; Stakeholders; Resources | Planning; Executing | Who represents users, commits people and authorises the response? |
| Plans | Scope; Schedule; Finance; Resources | Planning; Monitoring and Controlling | What changes in the forecast when the interface is repaired? |
| Quality | Governance; Scope | Planning; Executing; Monitoring and Controlling | What evidence makes the interface acceptable? |
| Risk | Risk | Planning; Executing; Monitoring and Controlling | What uncertainty remains after the repair? |
| Issues | Governance; Scope; Risk | Monitoring and Controlling | What has happened, and which proposed changes need a decision? |
| Progress | Governance; Schedule; Finance | Monitoring and Controlling; Closing | What evidence supports the forecast and eventual completion? |
Read across a row to widen a conversation, then return to the actual work. Quality, for example, does not disappear because there is no separate Quality domain in that list. Likewise, stakeholder engagement extends beyond the organising practice. The deliberately selective map leaves those overlaps visible.
Focus Areas are included for the example, not assigned permanently to a practice. Closing can reveal unresolved supplier obligations; execution can expose a need to revisit planning. Treat the table as a prompt to ask better questions, with your organisation’s approved arrangements governing the response.
Spotter: the same failed interface, framed twice
Here are the illustrative facts. Spotter’s current management stage has a target finish date and an agreed time tolerance of five working days beyond it. The team now forecasts an eight-working-day delay. The supplier’s interface fails the agreed account-retrieval test. Sam has no delegated authority to relax that acceptance requirement or commit additional supplier spend.
The technical lead offers three possibilities: repair and retest the interface, defer the affected portal feature, or investigate a temporary manual service. None is yet an approved recovery plan. The figures and arrangements belong to this fictional example; they are not recommended thresholds.
Frame it with PRINCE2: what needs authority?
Sam starts with the product and the evidence. The interface has failed a defined test. Its repair affects the stage forecast, which now exceeds the agreed time tolerance. Sam records the issue, assesses the consequences and raises an exception report to the project board. Waiting until day six of an actual overrun would hide a decision already needed today.
The request is specific: decide how to proceed, within the board’s authority, after considering the options. The board may direct Sam to prepare an exception plan. If the response would exceed the board’s own delegated authority, it needs escalation further up. A board meeting is not an unlimited permission slip.
The options must also preserve a credible business case. Removing account retrieval could protect a date while removing the reason customers would use the portal. Accepting a changed product requires the right authority and an explicit understanding of what users would receive.
Sam uses the local RAG status criteria to make the report understandable. The colour summarises the position; the forecast and tolerance establish the escalation need. A sponsor asking for amber cannot grant Sam extra authority by changing a slide.
Frame it with PMBOK 8: what consequences have we missed?
Sam’s colleague examines the same evidence across management concerns. Scope: what customer capability would disappear if the feature were deferred? Schedule: does the eight-day forecast include the supplier fix, integration testing and user acceptance? Finance: what would extra supplier effort and temporary operations cost?
Stakeholders and Resources expose a less obvious weakness. The manual service needs trained support staff, and the operations manager has not committed them. Risk adds another question: even after a repair, how confident are we that failures will not recur under realistic demand? Governance brings the analysis back to approval and accountability.
Sam records the failed interface as an issue and tracks the remaining uncertainty separately. The RAID log guide helps distinguish an existing problem from a future risk and makes ownership visible. “Supplier investigating” is too loose: Sam needs a named owner, a date and evidence that will support closure.
The Focus Areas help describe the work underway. Sam is monitoring the forecast, planning alternative responses and coordinating investigation. Those activities can happen together. The team does not have to finish all execution before it is allowed to plan again.
Bring both frames into one decision
Sam keeps one set of facts and one decision request. The exception identifies why the matter requires higher authority. The wider analysis explains what each option would mean. Neither requires a second reporting system simply to demonstrate familiarity with different terminology.
The SteerCo agenda guide suggests giving the item a clear decision purpose and checking the forum’s remit. In this example, Sam confirms that the project board has the necessary authority within project limits; a local steering committee would need its own remit checked.
The request becomes: “Choose the response to the failed account interface by Thursday. Repair requires a revised stage plan; deferral changes the release’s customer value; a manual service requires an operational commitment we do not yet have.”
After the authorised choice, Sam records the decision, conditions, owners and next review. The supplier’s repair is checked against the agreed test. The forecast is updated from evidence. If the decision is deferred, Sam records that too, including how the delay affects the available options. Two perspectives have improved one management conversation.
What a project manager should avoid
Treating one vocabulary as the only valid one. A colleague asking about resources may be exposing the missing support commitment. Another asking about tolerance may be identifying an authority problem. Translate the concern before defending the terminology.
Assuming the words are official equivalents. A PRINCE2 management product is not automatically the same as a PMBOK input or output. A local “stage gate” may mean something quite different from a management stage boundary. Ask what evidence and decision the label represents.
Inventing a hybrid language nobody authorised. Calling a meeting a “domain exception gate” adds confusion unless people understand its purpose. Use the local approved names for roles, records and decisions. Explain the connection in ordinary language when it helps.
Confusing status with authority. A red dashboard does not itself approve a change, and a green dashboard does not prove a forecast remains within delegated limits. The practical test is whether the right person received the evidence in time to act.
The practical distinction
Say “PRINCE2” when discussing how your organisation applies that method: its roles, products, management stages and controls. Say “PMBOK language” when using the Guide’s concepts to examine management concerns and the work needed to address them. Check local meanings before assuming either label explains the organisation’s arrangements.
For Sam, the useful opening question is: “Are we discussing the decision authority, the consequences of the options, or both?” That gets the failed interface back into focus. The release needs a defensible choice, an owner and evidence that the chosen response works.
For more practical project conversations like this, join the InsightSpotter newsletter.