Guide §3 · PRINTED PP. 103–112
Tailoring
Tailoring is a reasoned design activity. The team adjusts its life cycle, governance, processes, deliverables, tools, and patterns of participation so the combined system can achieve the intended outcomes within its constraints. Speed, cost, value, quality, compliance, sustainability, stakeholder expectations, and adaptability can pull in different directions. Tailoring makes those trade-offs explicit instead of allowing one concern to dominate by accident.
Understand the chapter
Tailoring is a reasoned design activity. The team adjusts its life cycle, governance, processes, deliverables, tools, and patterns of participation so the combined system can achieve the intended outcomes within its constraints. Speed, cost, value, quality, compliance, sustainability, stakeholder expectations, and adaptability can pull in different directions. Tailoring makes those trade-offs explicit instead of allowing one concern to dominate by accident.
Learning objectives
- Explain why a project approach should be fitted to context rather than adopted unchanged.
- Apply a four-stage tailoring cycle from initial approach selection through continuing improvement.
- Diagnose when governance, process, engagement, or delivery practices need adjustment.
Key concepts
Fit, not procedural minimalism
Tailoring is a reasoned design activity. The team adjusts its life cycle, governance, processes, deliverables, tools, and patterns of participation so the combined system can achieve the intended outcomes within its constraints.
Balance competing demands
Speed, cost, value, quality, compliance, sustainability, stakeholder expectations, and adaptability can pull in different directions. Tailoring makes those trade-offs explicit instead of allowing one concern to dominate by accident.
Three broad tailoring targets
A team can alter the life cycle and development approach, change process elements, and redesign how people are engaged and empowered. Process elements may be introduced, changed, removed, combined, or made consistent with one another.
Four-stage cycle
Begin with a plausible predictive, adaptive, or hybrid approach; reconcile it with organizational policy; fit it to the product, team, and culture; then inspect results and improve the approach during delivery.
Diagnostics close the loop
Retrospectives, phase reviews, quality measures, delays, risks, issues, and stakeholder feedback reveal whether the chosen operating model is working. Evidence should trigger a targeted adjustment, not an automatic increase in documentation or control.
Deeper understanding
Why it matters
Tailoring is constrained optimization: formal obligations are fixed while local practices can change.
Decision questions
- When would removing a reporting step improve efficiency without weakening a required control?
- Why can a hybrid project contain teams that use only one development approach?
- What evidence would justify adding a process rather than improving team integration?
Teach it back
- Explain why a project approach should be fitted to context rather than adopted unchanged.
- Apply a four-stage tailoring cycle from initial approach selection through continuing improvement.
- Diagnose when governance, process, engagement, or delivery practices need adjustment.
Signals to notice
- Tailoring is constrained optimization: formal obligations are fixed while local practices can change.
- A hybrid label describes a project-level mix, not necessarily each team’s daily method.
- Diagnose symptoms and test the intervention; more documentation alone is not evidence of better control.
Section-by-section reading
Use the printed page references to read each section in the official publication, then explain the idea in your own words.
3.1 Overview; 3.2 Why Tailor?
Tailoring is a reasoned choice about how much structure a particular project needs, not a waiver of management discipline. The guide contrasts environments that require extensive oversight with those that benefit from local autonomy. Speed, cost, quality, compliance, stakeholder expectations, sustainability, and value compete; a useful approach balances them rather than maximizing one in isolation. Criticality, duration, team size, maturity, industry constraints, and organizational culture affect the appropriate degree of rigor. Too little control leaves gaps; needless control consumes resources. A contract or policy can limit flexibility, so the team should identify nonnegotiable constraints before proposing changes. Involving practitioners improves ownership of the resulting method.
Understand this item
Why it matters: Tailoring balances control, speed, cost, quality, compliance, sustainability, and value so the method fits the project instead of consuming effort or leaving dangerous gaps.
Decision to make: Identify nonnegotiable policy, contract, and regulatory constraints, assess project criticality and context, involve practitioners, and remove or add structure only with a stated reason.
Do not confuse it with: Tailoring is disciplined method design, not permission to ignore governance; autonomy can increase while essential controls remain intact.
Teach it back: Explain when replacing a weekly report with a live demonstration improves efficiency and which evidence would justify retaining the report.
Apply it: For a small internal dashboard, replace a weekly steering pack with a short live demonstration while retaining mandatory privacy approval.
Check yourself: When would removing a reporting step improve efficiency without weakening a required control?
3.3.1 Life Cycle and Development Approach Selection
Tailoring begins at the architecture of delivery: choose phases and a development approach appropriate to each component. The guide uses a data-center example in which building works can follow a predictive sequence while computing capabilities are explored adaptively. At the whole-project level, that combination is hybrid, although an individual team may work entirely within one approach. This distinction prevents a label from obscuring how actual work is managed. A phase boundary can create a useful review point, while an incremental component can invite feedback before its specification becomes fixed. Decisions should follow product uncertainty, technical constraints, and opportunities to inspect results, not a blanket organizational preference for one fashionable method.
Understand this item
Why it matters: Different project components can have different uncertainty and feedback needs, so one blanket delivery label can force unsuitable sequencing or delay learning.
Decision to make: Choose phases and approaches component by component using product uncertainty, technical dependencies, review points, and access to feedback, then integrate them at project level.
Do not confuse it with: Predictive work benefits from stable sequence and defined controls, adaptive work learns through increments, and a hybrid project deliberately combines them even if each team uses only one.
Teach it back: Describe a project whose construction component is predictive and digital interface is adaptive, and explain what makes the overall project hybrid.
Apply it: A hospital fixes room construction milestones while prototyping the appointment interface in short user-tested increments.
Check yourself: Why can a hybrid project contain teams that use only one development approach?
3.3.2 Processes; 3.3.3 Engagement
Process tailoring may add controls, modify inputs or outputs, remove redundant work, blend compatible practices, or align definitions across groups. Engagement tailoring asks a different but related question: who has the skills, authority, and relationships needed to perform the work? The guide names people, empowerment, and integration, including employees and contracted partners. Local decision rights should reflect competence and risk; granting autonomy without clear boundaries is not the goal. A process that is elegant on paper may fail when external suppliers use conflicting terminology or approvals. Conversely, training and shared working agreements may solve a coordination problem more effectively than another template. Evaluate both workflow and human capability together.
Understand this item
Why it matters: A technically sound workflow fails if people lack skill, authority, shared language, or working relationships, while extra templates cannot repair weak integration.
Decision to make: Examine process steps and human capability together; add, remove, blend, or redefine controls while setting decision boundaries, training needs, and partner integration arrangements.
Do not confuse it with: Process tailoring changes how work flows and what artifacts support it; engagement tailoring changes who participates, how they collaborate, and where authority resides.
Teach it back: Given conflicting supplier terminology, explain when a shared definition and empowered lead would be better than adding another approval form.
Apply it: Two suppliers share one interface log and delegate minor design decisions to a jointly authorized technical lead.
Check yourself: What evidence would justify adding a process rather than improving team integration?
3.4.1 Select Initial Development Approach
The first tailoring step selects an initial predictive, adaptive, or hybrid approach using knowledge of the product, delivery cadence, and available ways of working. The guide presents a suitability filter as a discussion aid rather than an algorithm that dictates the answer. It considers cultural conditions, team dynamics, and project characteristics alongside other decision evidence. A high-uncertainty digital feature with frequent access to users may invite incremental discovery, but the same project may have fixed regulatory components. Record the reasons for the selection so later review can test whether the assumptions still hold. Initial means revisable: the decision starts a learning cycle, not an irrevocable methodological commitment.
Understand this item
Why it matters: The starting approach shapes feedback timing, controls, and delivery cadence, but treating the choice as permanent prevents adaptation when its assumptions fail.
Decision to make: Use product, culture, team, and project evidence to select an initial predictive, adaptive, or hybrid approach, document the reasoning, and define signals for reconsideration.
Do not confuse it with: A suitability filter supports discussion; it does not calculate a mandatory method or override regulation, technical constraints, and component-level differences.
Teach it back: State two assumptions behind choosing iterative delivery and the evidence that would cause the team to revise that choice.
Apply it: A transit team chooses predictive safety certification and iterative rider-alert usability testing after evaluating feedback access.
Check yourself: What would make a suitability-filter result insufficient on its own?
3.4.2 Tailor for the Organization
An organizational methodology is a starting configuration, not necessarily the final project method. Tailoring must remain consistent with policy, governance, portfolio or program dependencies, and any shared definitions that enable reliable reporting. A PMO can review or approve changes affecting other groups and bring solutions from comparable projects; adjustments confined to the internal team may need only project-manager approval. Multiorganization projects need explicit integration across distinct governance systems rather than assuming one partner’s rules automatically dominate. The guide also frames the PMO as an evolving enabler of strategy and value, not merely a process custodian. Clarify who authorizes a change and whose operations it will affect before implementing it.
Understand this item
Why it matters: Project changes can affect shared reporting, governance, programs, partners, and operations, so local efficiency must not break organization-wide coordination.
Decision to make: Determine which policies and shared definitions apply, identify affected groups, secure approval at the correct level, and explicitly reconcile governance across organizations.
Do not confuse it with: An internal working practice may be changed by the project manager, while a cross-organization threshold or escalation route needs broader agreement because others depend on it.
Teach it back: Explain why two partner organizations should agree on change thresholds before either shortens its own review cycle.
Apply it: A city and utility jointly agree on one change threshold and escalation route before either changes its internal review cycle.
Check yourself: Why might a cross-organization tailoring decision require broader approval than an internal team practice?
3.4.3 Tailor for the Project: product, team, and culture
Project-level tailoring tests three groups of attributes. Product questions concern standards, confidentiality, technology maturity, timeframe, requirement stability, and whether partial results can be evaluated. Team questions include size, geographic distribution, experience, diversity, and practical access to customers. Culture questions examine trust, buy-in, empowerment, and compatibility between local decisions and organizational expectations. These dimensions interact: iterative delivery offers less benefit when users cannot provide timely feedback, and delegation is risky without sufficient competence or trust. Use the answers to adapt life cycle, processes, engagement, and tools rather than checking each factor in isolation. Revisit assumptions if the team composition or market changes.
Understand this item
Why it matters: Product uncertainty, team capability, customer access, trust, and organizational expectations interact, so assessing any one dimension alone can produce an unusable method.
Decision to make: Evaluate product constraints, team composition and distribution, and cultural readiness together, then adjust life cycle, engagement, tools, mentoring, and authority boundaries.
Do not confuse it with: Frequent iterations enable learning only when users can respond; broad delegation works only when competence, trust, and organizational permission support it.
Teach it back: Explain how limited customer access and a novice remote team would change an otherwise reasonable adaptive approach.
Apply it: A remote novice team keeps frequent customer demos but adds mentoring and a defined approval boundary for safety changes.
Check yourself: How does limited customer access affect a proposed adaptive approach?
3.4.4 Implement Ongoing Improvement; 3.5 Tailoring the Performance Domains
Tailoring continues during execution as learning exposes defects in the chosen way of working. Phase gates, retrospective discussions, and other review points offer occasions to adjust the process, approach, or delivery frequency. Changes should respond to evidence rather than mere frustration and should be checked for effects on outcomes and governance. The guide also makes the performance domains tailorable: principles shape practitioner behavior while the domain activities are adjusted to the project context. This is not permission to omit risk or stakeholder work; it asks what forms of that work produce useful results here. Team participation in improvement can strengthen ownership, innovation, and the quality of subsequent decisions.
Understand this item
Why it matters: The chosen method is a hypothesis about how to deliver outcomes; execution evidence is needed to refine it without abandoning essential domain responsibilities.
Decision to make: Use gates, retrospectives, measures, defects, threats, and feedback to propose an adjustment, predict governance impacts, implement it, and compare later outcomes with the prior state.
Do not confuse it with: Tailoring a performance domain changes the form and intensity of its work; it does not permit omitting stakeholder, risk, quality, or other necessary outcomes.
Teach it back: Describe how late interface defects could justify earlier supplier reviews and which later measure would test whether the change helped.
Apply it: After repeated late interface defects, add early supplier integration reviews and compare defect discovery across later releases.
Check yourself: How would you tell whether a tailoring adjustment improved a domain outcome?
3.6 Diagnostics; 3.7 Summary
Diagnostics translate symptoms into targeted adjustments. The guide’s table connects poor quality with root-cause analysis and process improvement, approval delays with delegated authority, excess work in progress with flow visualization, and disengaged stakeholders with more relevant communication. Weak progress visibility calls for agreed measures; recurring surprises suggest gaps in risk or issue handling. Adding another inspection is not automatically the cure for defective work, just as adding reports is not automatically the cure for poor engagement. Retrospectives are useful but not mandatory: quality measures, threats, issues, and stakeholder feedback can supply evidence. Verify that the modified approach remains aligned with outcomes after the intervention.
Understand this item
Why it matters: Symptoms such as delays, defects, excess work, or disengagement have different causes, and a generic addition of reports or inspections can add waste without solving them.
Decision to make: Name the symptom, gather evidence, investigate its cause, choose a targeted adjustment, and verify both improvement and continued alignment with project outcomes.
Do not confuse it with: Final inspection detects defects after creation, while root-cause and process improvement seek to prevent recurrence; more visibility is not automatically more control.
Teach it back: For slow approvals, propose a diagnostic, a bounded delegation change, and measures that reveal cycle-time improvement without increased rework.
Apply it: When approvals stall, authorize package leads to approve low-value changes, then measure cycle time and rework.
Check yourself: Which diagnostic distinguishes a quality-process weakness from a need for more final inspection?
Apply it to a project
A bank is replacing a reporting platform. Regulatory interfaces are stable and must pass formal assurance, while dashboard needs are changing as analysts see prototypes. The team is distributed and approvals take weeks. Use a hybrid design: plan regulated interfaces predictively with traceability and formal gates, while developing dashboards in short feedback cycles. Delegate low-value internal approvals within agreed thresholds, keep external compliance approvals intact, and test whether lead time and defect escape rates improve. Tailor different parts of one project differently, but preserve the controls that protect the outcome.
What to watch for
- Misconception: Tailoring means deleting controls to work faster. Correction: It may remove waste, but it may also add rigor, controls, or specialist reviews when risk and criticality require them.
- Misconception: The development approach is chosen once and cannot change. Correction: The initial choice is a starting hypothesis. Delivery evidence can justify changes in process, cadence, or the mix of approaches.
- Misconception: Every team can tailor without governance involvement. Correction: Local working practices may need little approval, while changes affecting external groups, contracts, compliance, or enterprise policy may require PMO or governance authorization.
Test your reasoning
What is the best primary basis for tailoring?
Show answer and reasoning
1 Tailoring starts with contextual fit and the results the project must achieve.
Which sequence best represents the tailoring cycle?
Show answer and reasoning
1 The approach is progressively fitted at organizational and project levels, then refined using evidence.
A team has recurring approval delays. What is the most targeted response?
Show answer and reasoning
2 The adjustment addresses the specific bottleneck while retaining boundaries and accountability.
Which factor most strongly supports iterative delivery?
Show answer and reasoning
1 Incremental assessment and timely feedback allow learning to shape later work.
What should happen after a tailored practice is introduced?
Show answer and reasoning
1 Tailoring is completed through inspection and adaptation, not by making a one-time change.
Study companion only; the official guide is available from PMI.