Tailoring is deciding what a particular project will actually do out of everything the method offers, and at what formality. A standard describes the full range of practice across every kind of project. No single project needs all of it, and every project needs some part of it more than the standard assumes.
The eighth edition dropped tailoring from the list of principles, which reads like a demotion and is the opposite. Tailoring stopped being one instruction among twelve and became the way all of them are applied, since a principle that holds for every project can only be followed by adapting it to the one in front of you.
What is actually being tailored
Six things, and they are usually adjusted together rather than separately.
| What | Adjusted by | A worked example |
|---|---|---|
| Life cycle | Choosing predictive, iterative, incremental, adaptive or a mixture, per component | Hardware planned to milestones while the software underneath it runs in short cycles |
| Processes | Adding, dropping, combining or resequencing | Combining risk identification into the weekly delivery meeting on a project too small to justify a separate one |
| Artefacts | Deciding what is produced, how formally, and who reads it | A one page charter on a six week project, a fifty page one on a regulated programme |
| Tools | Choosing what the work is tracked and communicated in | A wall of cards rather than a scheduling tool where the team is in one room |
| Methods | Choosing estimating, prioritisation and review techniques | Relative sizing where the team is stable and three point estimating where a contractor prices the work |
| Governance | Setting decision rights, tolerances and review points | Delegating change approval up to a value threshold rather than routing every request to a board |
The common mistake is tailoring artefacts alone. Dropping a report while leaving the process that produced it and the governance that expected it in place creates a gap somebody discovers at the review, and the usual response is to reinstate the report and conclude that tailoring does not work.
The order the decision runs in
Start from the delivery approach, because it constrains everything after it. Something released monthly cannot be governed by a board that meets quarterly, and discovering that after the fact is expensive.
Then apply what the organisation has already fixed. Standards, mandated templates, an audit regime and a portfolio reporting cycle are inputs rather than options, and a project that quietly ignores them produces a second problem on top of the one it was solving.
Then fit the project itself. Size, duration, team experience, how distributed the people are, how novel the work is and how much a mistake costs all move the formality dial. A team that has delivered this kind of work eight times needs less written down than one meeting it for the first time, and saying so out loud is more honest than pretending the difference does not exist.
Then keep adjusting. A tailoring decision made at initiation was made with the least information anybody on the project will ever have, and the natural review points are the ones already in the calendar.
What cannot be tailored away
Some things look like method and are not.
Regulatory obligations, contractual commitments and health and safety requirements sit outside the project's discretion. So does anything the organisation has designated as a control rather than a practice, and the distinction is worth establishing early, because the two are often written in the same document and look alike.
The reliable test is who is harmed by the omission. A status report that nobody reads harms nobody, and dropping it is tailoring. A design review that exists so that a second qualified person sees the work before it is built harms whoever uses the output, and dropping it is not tailoring but the removal of a control.
Where an obligation genuinely obstructs the work, the route is to have it waived by whoever owns it, with the decision recorded. That is a governance conversation rather than a project one.
Under and over tailoring
Over tailoring is the failure people expect. Ceremony is imported wholesale, a small piece of work carries a register, a board, a baseline and a change process, and the overhead consumes the effort that should have gone into the deliverable.
Under tailoring is more common and less recognised. A team drops the artefacts without replacing what they were doing, and the work loses its record of decisions, its view of dependencies and its estimate of where it stands. Somebody asks a reasonable question six weeks later and nobody can answer it.
The question that separates the two is what job the practice was doing. A practice can go when the job is not needed here, or when something lighter does the same job. A practice that goes because it was tedious leaves the job undone.
The record is the deliverable
The output of tailoring is not a lighter process. It is a stated decision, with reasoning, that somebody can challenge later.
That record is what lets a sponsor who wants the full standard applied be answered with something better than preference, and it is what lets a project manager arriving in month seven understand why the project works the way it does. A tailoring decision nobody wrote down is indistinguishable from an omission, and it will be read as one.