Tailoring in Project Management: What It Actually Means

Tailoring gets used to describe two entirely different decisions. In one project it means a considered choice to run a lighter change process because the work is small, well understood and easy to reverse. In another it means a report quietly stopped being produced because nobody chased it. Both get called tailoring. Only one of them is.

At its simplest, tailoring means deliberately adapting how a project is managed so that the approach suits the project and the environment it sits in. That covers a great deal: the development approach, the life cycle, the processes and methods used, the artefacts produced, the level of governance, the roles, the controls, the reporting cadence and the way stakeholders are engaged. Almost everything about how you run a project is available to be adapted. What cannot be tailored away is accountability for the outcome.

Why the same decision can be tailoring or drift

Picture two project managers, each reducing monthly reporting to a fortnightly summary. From the outside the decision looks identical. The difference sits in what happened before it.

The first can tell you what the monthly report was doing. It gave the sponsor an early view of cost movement, it gave the PMO a consolidated position for portfolio reporting, and it forced a monthly conversation the team would otherwise have let slide. She has kept the cost view by adding two lines to the fortnightly summary, agreed with the PMO that the consolidated position now comes from the tool rather than the pack, and kept the monthly conversation as a standing item without the pack around it.

The second stopped producing the report. Nothing else changed.

That is the working test, and it is more useful than any definition. If you can say what a practice was for, and what will now do that job instead, you are tailoring. If you cannot, you are removing a control and using a professional word to describe it. The distinction matters most in organisations where nobody will notice for several months.

What actually drives the decision

Proportion comes from the project's conditions rather than from preference. A short list does most of the work:

• how much is genuinely unknown at the outset;
• the consequence of getting something wrong, and who bears it;
• how much is externally required, whether by regulation, contract, funding or audit;
• how experienced this team is with this type of work;
• how many parties have to coordinate, and how far apart they sit;
• how reversible the decisions are.

None of these produces a single right answer, and two of them will often pull in opposite directions. Work that is genuinely uncertain argues for lighter documentation and shorter cycles. Work whose failure would be expensive or public argues for stronger evidence and clearer approval points. Plenty of projects are both at once, and the resolution is usually not a compromise across the whole project but a difference between its parts.

Section 3 of the PMBOK® Guide approaches tailoring in that spirit. It sets out why an organisation would tailor, what is available to be tailored, and how a tailored approach is put into practice and improved as the project runs. It does not offer a formula, because the inputs are the project's own conditions rather than a category it can be sorted into.

Where the tailoring becomes visible differs by approach. On predictive work it usually shows in the depth of up-front planning, the number of approval points and the volume of documentary evidence produced. On adaptive work it shows in cadence, in the structure of the events the team holds, in what the team treats as done, and in how much is fixed before a cycle begins. Adaptive delivery is most often misread here, because frameworks are sometimes treated as though they arrive pre-sized for the job. They do not. Something designed around a co-located team of seven needs as much thought before it is used across four suppliers in three time zones as any predictive method would. On hybrid work the tailoring is mostly about the joins: which parts of the project need a baseline, which need a backlog, and how both report into the same governance without either being distorted to fit the other.

Proportion in practice, and who agrees it

Take a six-week piece of work inside a utilities organisation: a change to how billing queries are routed between the contact centre and a back-office team. The organisation's project standard was built for metering and network programmes running over two years or more. Applied without thought, it produces a full risk register, a monthly board pack, a formal change process and a stage-gate review, for a project with six people on it and no capital spend.

The project manager keeps the risk thinking but not the register in that form. Five risks, held as a short list, reviewed in the weekly team session and re-read whenever something material shifts. The monthly board pack goes, replaced by a standing ten minutes in the operations meeting the affected managers already attend, because that is where decisions about the contact centre are actually taken. The stage-gate review is not held, because there is no stage worth gating inside six weeks.

One thing does not move. Any change affecting how a query is categorised for the regulator goes through the full change process, unaltered, because the consequence of getting that wrong sits outside the organisation. Two projects in the same organisation, run by the same manager, can carry quite different amounts of formality without either being managed badly.

The other half of that decision is agreement. Some of it was hers: how her team runs its week, how it holds its risk conversation, what it writes down for its own use. Some of it was not. Dropping the board pack changes what the PMO can consolidate, so the PMO had to agree what it would use instead. Removing the stage gate touches the organisation's assurance model, which makes it a sponsor conversation rather than a personal preference. Tailoring that is decided quietly and discovered later tends to get reversed, and reversed at the least convenient point in the project. Working out which calls are yours and which need someone else's agreement is a habit rather than a rule, and it is one of the things PMP® Exam Preparation returns to repeatedly, because the same question sits underneath most delivery decisions.

Tailoring is a running decision

The remaining misreading is that tailoring happens once, early, in a planning session, and then holds for the duration. A project that looked straightforward in March can acquire a second supplier, a regulatory interest and a new sponsor by September, at which point an approach sized for the original project is sized for something that no longer exists. The reverse is just as common. Work that started under heavy control settles down, and the controls stay in place because revisiting them was nobody's job.

Two questions are worth putting into each review point. Is anything we produce no longer being used by anyone to decide anything? And has anything changed that would make us set this up differently if we were starting today?

For a PMP® candidate, the useful observation is that tailoring is not presented as a topic to be revised in isolation. In the 2026 PMP Examination Content Outline it sits inside ordinary delivery work. The first task of the Process domain includes assessing a project's needs, complexity and magnitude and then recommending a predictive, adaptive/agile or hybrid approach, and the task covering evaluation of project status includes identifying and tailoring the artefacts a project needs. Preparation that reduces tailoring to a definition misses the shape of that. Practising how to read a described situation for the conditions that should change the answer is closer to what the material is asking for, and it happens to be the same habit the job requires.

Away from the exam, this matters because most project managers inherit a standard rather than choose one. That standard was written for a type of project, usually the largest or riskiest the organisation runs, and it will be applied to work several sizes smaller unless somebody makes a reasoned case for something different. Being able to make that case in terms of purpose and consequence, rather than convenience or fatigue, is most of the difference between a project manager who is tailoring and one who has simply had enough of the paperwork.

Andre Malowney

Interested in going further?

Deciding what to keep, what to resize and what needs someone else's agreement is hard to learn from a standard, because standards are written to be applied rather than questioned. PMP® Exam Preparation works through that judgement across the full delivery cycle, using situations where the conditions genuinely change the sensible answer.

The PMBOK® Guide Eighth Edition sets out the reasoning behind tailoring in more depth than a single article can carry, including the full range of what is available to adapt.

Ad · Amazon affiliate link.

References

A083: The Four-Step Tailoring Process Explained
A165: Tailoring Risk Management to the Project
A141: Tailoring Stakeholder Engagement for Different Contexts
A122: Tailoring Schedule Management for Adaptive Delivery
A151: Tailoring Resource Management for Agile and Hybrid Teams

PMP and PMBOK are registered marks of the Project Management Institute, Inc.