So You Want to Run a Kitchen?

A Teaching Illustration on Principles, Practices, and Processes

I once had a delegate pull me aside at the end of day one of a PRINCE2 course and tell me, very quietly, that he'd spent eighteen years managing projects and the manual had just broken his brain.

He wasn't being dramatic. He was staring at a diagram – arrows going in every direction — and he had the look of a man who'd been handed a flat-pack wardrobe with the instructions in German.

I told him to close the manual. We were going to talk about dinner instead.

The Analogy — This Is a Teaching Illustration, Not a Cookery Class

I use this across PRINCE2, ITIL, MSP, and M_o_R, and it works every time. Three things have to come together for a great meal to leave a professional kitchen. Those three things map precisely onto how every major framework is structured.

The delegate who'd been staring at the forty-seven arrows? By the end of the session he was explaining the model to the table next to him. That's the test of a good analogy.

The Chef's Skills — The Principles

A great chef knows how to cook. Not from a laminated card on the wall — from deep, internalised understanding of heat, timing, balance, and flavour. These fundamentals guide every decision they make, especially the difficult ones, especially under pressure.

In PRINCE2 7, these are the Principles — continued business justification, learning from experience, defined roles and responsibilities, managing by stages, managing by exception, focus on products, and tailor to suit the project environment. They're not rules you consult once at kickoff and forget. They're the judgement a good project manager reaches for instinctively when the sponsor changes their mind on day three of stage four.

In ITIL, they're the Guiding Principles — focus on value, start where you are, progress iteratively with feedback, collaborate and promote visibility, think and work holistically, keep it simple and practical, optimise and automate.

In MSP 5th edition, the seven Principles — Lead with Purpose, Bring Pace and Value, Realise Measurable Benefits, Collaborate Across Boundaries, Deal with Ambiguity, Align with Priorities, and Deploy Diverse Skills — are the guiding obligations that apply from the identification to closure of every programme. They're not aspirational statements on a wall. They're the basis on which every governance decision is made.

In M_o_R 4, the eight Principles — Aligns with Objectives, Fits the Context, Engages Stakeholders, Provides Clear Guidance, Informs Decision-Making, Facilitates Continual Improvement, Creates a Supportive Culture, and Achieves Measurable Value — set the conditions under which effective risk management becomes possible. The first seven are enablers. The eighth — Achieves Measurable Value — is the outcome you get when the first seven are actually in place. That distinction matters: it stops risk management becoming a compliance ritual and keeps it focused on whether you're creating and protecting real value.

Strip these out and you don't have a framework. You have a very expensive ring binder.

The Ingredients — The Practices (and Themes)

The chef has skills. Now they need something to work with. Flour. Eggs. Fresh produce. The quality and combination of ingredients determines what's possible — and no amount of skill rescues bad ingredients.

In PRINCE2 7, these are the Practices — Business Case, Organizing, Plans, Quality, Risk, Change, Issues, and Progress. Each one is a discipline in its own right. The Business Case, in particular, is not a document you write to get approval and then file. It's a living practice that justifies the project's continued existence at every stage boundary.

In ITIL (Version 5), the 34 Management Practices — split across product and service management practices and general management practices — cover everything from incident management and change enablement to continual improvement and service level management.

In MSP, the seven Themes — Organisation, Design, Justification, Structure, Knowledge, Assurance, and Decisions — describe the essential aspects of governance required to align the programme with its principles at every stage of its lifecycle.

In M_o_R 4, risk doesn't live at one level — it applies across six Perspectives: Strategic, Portfolio, Programme, Project, Product, and Operational. Each perspective has different objectives, different risk tolerances, and different stakeholders. What counts as an acceptable risk at project level may be entirely unacceptable at strategic level. The ingredients — the risks — change depending on which kitchen you're standing in.

You can have the best chef in the world. Without the right ingredients, dinner is not happening.

This is where I see organisations cut corners most often. They implement a framework without properly setting up the practices. No real risk management — just a log someone updates before the monthly report. A business case that nobody reads after the initial sign-off. A quality approach that lives in a SharePoint folder and was a write-once document that has never been read. The skills are there. The recipe is on the table. But the ingredients are stale.

The Recipe — The Processes and Activities

Here's where it comes together. The recipe tells you what to do, in what order, with what you've got. It's not rigid — a good chef adapts. But it gives you the sequence, the method, the steps that turn raw ingredients into something a client would actually pay for.

In PRINCE2 7, these are the Processes — Starting Up, Initiating, Directing, Controlling a Stage, Managing Stage Boundaries, Managing Product Delivery, and Closing. Each process connects to the next, moving the project from an idea someone had in a boardroom to a product the business can actually use.

In ITIL (Version 5), the Value Chain Activities — Discover, Design, Acquire, Build, Transition, Operate, Deliver, and Support — provide the flow from demand to value. They're not a waterfall sequence; they're interlocking activities you apply and combine differently depending on the service and the situation, within the broader ITIL Value System.

In MSP, the Programme Lifecycle moves a programme from an articulated vision to realised benefit through seven processes — Identify the Programme, Design the Outcomes, Plan Progressive Delivery, Deliver the Capabilities, Embed the Outcomes, Evaluate New Information, and Close the Programme. Note that Evaluate New Information runs continuously alongside the others; it's not a step you reach at the end, it's the mechanism that keeps the programme honest throughout.

In M_o_R 4, the Process Cycle gives you the systematic method for managing uncertainty through eight steps — Define Context and Objectives, Identify Threats and Opportunities, Prioritise Risks, Assess Combined Risk Profile, Plan Responses, Agree Contingency, Monitor and Report Progress, and Review and Adapt. That second step is worth reading again: Identify Threats and Opportunities. M_o_R 4 is explicit that risk cuts both ways. The kitchen might run out of the signature ingredient — that's a threat. It might also discover that a supplier cancels, forcing an improvisation that becomes the most popular dish of the year — that's an upside risk, and a well-run risk process catches both.

The recipe doesn't make the chef redundant. It makes the chef's expertise applicable.

Why This Matters — Three Elements, Not Three Stages

Here's the point most people miss: these three elements don't operate in sequence. They operate simultaneously.

The chef doesn't finish learning skills, then buy ingredients, then consult the recipe. They're doing all three at once — adjusting the heat (principles), reaching for a different herb (practices), skipping a step because tonight's service demands it (process adaptation).

That constant, real-time interaction is exactly what makes a framework work in practice. And it's exactly what makes it look so intimidating on a diagram.

Warning: you might be running a dysfunctional kitchen if…

Your project's business case was approved at initiation and nobody has looked at it since

Risk management lives in a spreadsheet that only the project manager has ever opened

Lessons learned are captured after each stage, filed neatly, and never consulted again

Your incident management process has fourteen mandatory steps and takes longer to follow than the incident takes to resolve

The risk register is updated the day before the monthly report and hasn't been opened since

Risk management is treated as a threat-only exercise — nobody is asking what opportunities the uncertainty might create

The framework is described as "how we do things here" but no one on the team can name a single principle

When organisations treat frameworks as checklists, they get process without judgement. When they treat them as philosophy only, they get principles without delivery. The skill — and this is what I spend a lot of time on in the training room — is building people who can operate across all three simultaneously, fluidly, under pressure.

That's the real goal. Not the certification. The capability.

The Self-Improving Kitchen — Plan, Do, Check, Act

The best kitchens get better over time. The chef reviews what worked and what didn't. The team refines the recipe. Better suppliers get found. That feedback loop — Plan, Do, Check, Act — is what separates a kitchen that delivers consistently from one that merely survives the dinner rush.

It's the same in every project, programme, and service organisation I've worked with. The frameworks give you the structure. The Deming cycle keeps you honest about whether it's actually working.

The goal isn't a team that follows the recipe. It's a team that improves it.

This chef analogy is a teaching illustration I use in training across PRINCE2, ITIL, MSP, and M_o_R to explain how Principles, Practices, and Processes interact. If it made you hungry, I apologise. If it made frameworks feel more human — that was entirely the point.

Robert Pinnington | PDCA Consulting

Training & Consulting in Project and Service Management