Why Processes Came Back in PMBOK 8
The Seventh Edition set the process-and-input-output apparatus aside, replaced it with principles and performance domains, and moved the detailed how-to material onto a separate online platform. That left practitioners to supply the missing half from their own experience. For a project manager with twenty years behind them it was a fair trade and arguably overdue. For everybody else it left a question the book had stopped answering: what does this work actually consist of?
The Eighth Edition carries forty processes again, sitting inside the performance domains and explicitly nonprescriptive. What the return addresses is visible in what the absence produced, and that is worth understanding, because it governs how the returned material should be used. The way to get it wrong is to read forty descriptions as forty obligations.
What the removal actually cost
Three things showed up in organisations across the years the detail sat outside the book.
Project frameworks lost a common reference. A framework has to say what a stage contains, and a PMO writing one from principles alone ends up inventing the content. The invention is often good work, and it means two organisations in the same sector running the same kind of project produce two frameworks with nothing in common and no way to compare them. The shared vocabulary that made a project manager's experience portable between employers got noticeably thinner.
People new to the work had less to learn from. Principles are written for judgement, and judgement is the thing a project manager in their first year has least of. Focus on value is sound advice and gives a new project manager nothing to do on Monday morning. A described process, even one nobody is required to follow, tells them what the work contains, and that is where a craft starts.
Practice inside organisations drifted. With no common description, one team's idea of validating scope means a customer signing a document and another's means a demonstration in a room, and the difference surfaces during an escalation. Teams can disagree about how to do something and get somewhere; disagreeing about what the something consists of wastes a fortnight.
What a nonprescriptive process is good for
Section 1.3 of the PMBOK® Guide Eighth Edition sets out the return, and the wording around it is careful. The processes are there to be drawn on, scaled and left out, and no project performs all forty. That leaves a reasonable question about what an optional process is for, and the answer has two parts.
A name is a coordination device. "We will run a scope validation with the customer before handover, in the second week of March" is a sentence eight people can act on. "We will be principled about scope" is a sentence nobody can act on, however true it happens to be. Naming a piece of work lets it be scheduled, resourced, assigned and argued about, and a team with no name for something tends not to do it.
A description is a starting point for tailoring. Deciding how much of something a project needs is far easier when the full shape of it is visible and you can cut down from there, and considerably harder from an empty page where you cannot tell what you have left out. The tailoring guidance sits inside each domain rather than in a chapter of its own so that the cutting-down decision gets taken with the description in front of you.
Validating scope on a ward
A hospital trust was replacing infusion pumps across four wards, around three hundred devices, with a change to the drug library configuration at the same time. The project team and the clinical team had agreed the scope, and both sides believed the agreement was clear.
It came apart at the first ward. The project team understood acceptance to mean the devices were installed, configured and tested against the specification, which they were. The clinical team understood acceptance to mean the ward could use them, which required a competency sign-off for every nurse on the rota, running to about three weeks per ward. Nobody had scheduled it, because nobody had named it.
Untangling it was not difficult once both views were in one room, and it cost seven weeks across the four wards. What would have prevented it is an ordinary named step with a stated meaning: a scope validation with the clinical lead, settling what acceptance required, held before the first installation. The step existed in nobody's plan, because the plan came from a framework that named its stages and left what they contained to the team.
For a PMP® candidate, the returned processes are best read as vocabulary rather than as procedure. Knowing what validating scope involves, and how it differs from checking quality, matters because a situation can hinge on the distinction. Knowing a list of inputs and outputs by heart does not. What helps is to learn what each process is for and what it produces, and to treat the question of whether a given project would run it as a separate, tailoring question. Situations where the right answer is to do less of something are among those a structured PMP exam preparation course works through.
Spend half an hour with whichever domain your current phase sits in, reading the named processes and putting two questions to each. Do we do this? And do we have a name for it that everybody uses? Most teams turn up one or two things they do without a name, which is where they are inconsistent, and one or two things they have named and do not actually do.
Interested in going further?
With forty processes available, the skill is picking the few this project needs and saying so where the team can hear it. Omega's PMP® Exam Preparation works through situations where naming the work, and then scaling it, is the decision.
The returned processes sit inside the performance domains of the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A081: Tailoring Processes Without Losing Discipline
A003: PMBOK 7 vs PMBOK 8: What Actually Changed?
A138: Stakeholder Mapping Is Only the Start
A018: Policies, Processes and Procedures: When Each Matters
A009: PMBOK 8 for Experienced Project Managers: What You Need to Relearn
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
