The Four-Step Tailoring Process Explained
Tailoring runs to four steps in the Eighth Edition, and the list is short enough to be unhelpful on its own: select an initial development approach, tailor for the organisation, tailor for the project, then implement the result and keep improving it. Set out like that it reads as a procedure. What makes it worth the time is the order, because a good deal of the tailoring that gets overturned was done in the wrong one.
Why the order is the useful part
Most teams begin at step three. They have a project, they can see which parts of the framework do not suit it, and they make sensible-looking reductions: two gates merged, a report dropped, a review made informal. Each reduction is defensible on its own terms. They get reversed at the first gate review, because nobody established which parts of the framework were the organisation's to relax and which were not.
The first two steps exist to draw an envelope. Inside it, a project team can tailor freely and say so in writing. Outside it, every decision is provisional and somebody senior will eventually say so, usually at a point where reinstating the work costs a month. The order is doing real work here: it decides whether the tailoring survives contact with the organisation.
The four steps, and what each is actually for
Section 3.4 of the PMBOK® Guide Eighth Edition lays out the sequence, and each step answers a question the next one depends on.
Selecting an initial development approach comes first, because it shapes everything after it. Predictive, adaptive or hybrid is a starting hypothesis about the work, drawn from how stable the requirements are, how fast feedback can arrive, what the regulatory position is, and what the delivery organisation is actually able to do. It is a starting point and not a commitment, and getting it roughly right matters considerably more than getting it exactly right.
Tailoring for the organisation comes second and is the step people skip. Its question is what this organisation permits, requires and already has. Which parts of the framework exist because of a regulator, an auditor, a contract or a standard, and are therefore not the project's to touch? Which exist because somebody built a template in 2019? What process assets already exist, so that the project does not invent a method somebody down the corridor has spent four years refining? The output is an envelope, plus a short list of things worth asking permission for.
Tailoring for the project comes third, and inside that envelope it is comparatively easy. The project's own characteristics, its size, duration, risk, team experience, stakeholder complexity and delivery cadence, set how much of each practice is proportionate. This is the step most articles describe, and the one that goes wrong least often, provided the second step happened at all.
Implementing and continually improving is fourth and looks optional, which is why it gets treated that way. The tailored approach has to be written down, told to people and then checked against what is actually happening, because a tailoring decision nobody implemented is a meeting. The improving half earns its place because a project learns things: the approach chosen in month one was built on what was known in month one.
The gate review that undid a fortnight
An insurer was introducing automated triage on its claims operations floor, routing incoming claims by complexity before a handler saw them. The programme team made a careful job of tailoring for the project. The framework's eight-stage structure became five. A separate benefits plan was folded into the business case. The user acceptance approach was simplified, because the users sat forty feet away and could be asked directly.
All of it was reasonable, and about a third of it did not survive. The insurer's risk function required a documented model validation for any automated decision affecting a customer outcome, with an independent reviewer and a defined evidence pack, and the programme had absorbed that into a general testing activity. The framework was not being bureaucratic here: it was carrying a regulatory obligation, and the programme team held no authority to reduce it.
Redoing the work took four days and produced a better answer than the original. The team sat down with the risk function and marked the framework up, tagging every requirement as regulatory, contractual or organisational preference. Twelve items came out regulatory and stayed. Nine were contractual, and three of those turned out to belong to a contract that had ended. The remainder were preference, and the programme cut more of them than it had dared to the first time, because it now held a written note from the risk function saying which were which.
That marked-up framework was reused by the next four programmes, which is the second step doing exactly what it is for.
For a PMP® candidate, the step worth carrying is the second one, because it changes what a situation is asking. A team frustrated by a heavy process is not automatically being invited to lighten it. The question is usually who owns each part of it and what each part is there to satisfy. What a control exists for has to be established before asking whether it can be reduced. Practising that on situations where some of the controls are genuinely immovable is among the more demanding parts of a structured PMP exam preparation course.
The four steps are a morning's work, and only the second needs somebody else in the room. Bring whoever owns the framework and go through it marking each requirement as regulatory, contractual or preference. The marking is quick, the disagreements are the informative part, and the note that comes out of it is what makes the rest of the tailoring stick.
Interested in going further?
Tailoring that gets reversed at a gate review costs more than never having tailored, and the cause is nearly always a step taken out of order. Omega's PMP® Exam Preparation works through decisions where knowing who owns a control is what settles the answer.
The tailoring process, step by step, is set out in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A077: Tailoring in Project Management: What It Actually Means
A165: Tailoring Risk Management to the Project
A017: Organisational Process Assets: What They Actually Include
A087: Tailoring Never Stops: Ongoing Improvement in Delivery
A141: Tailoring Stakeholder Engagement for Different Contexts
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
