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. PMI expects every project to be tailored and expects the reasoning to be recorded, and the examination tests both the decision and the record.
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 the project manager. The sections below describe what gets tailored, the order the decisions run in, what cannot be tailored away and the two ways tailoring goes wrong.
The six things that are tailored
Six things are tailored, and they are usually adjusted together.
| 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 where the team is in one room, and a scheduling tool where it is not |
| 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, so the board sees only the requests above it |
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 in which tailoring decisions are made
Adjusting the six together is easier when they are taken in a fixed order, and the delivery approach comes first, 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.
What the organisation has already fixed comes next. Standards, mandated templates, an audit regime and a portfolio reporting cycle are inputs, and a project that quietly ignores them produces a second problem on top of the one it was solving.
The project itself comes third. 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.
Adjustment continues after that. 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, and no amount of adjustment reaches them.
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, and the distinction between a control and a practice 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 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, and it is held outside the project.
Under and over tailoring
Within the project's discretion, tailoring fails in two directions. 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 tailoring record
The output of tailoring is a stated decision, with reasoning, that somebody can challenge later. Whether the process ends up lighter or heavier follows from the decision.
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.