How to tailor: a repeatable way of making and recording decisions

Lesson 1 explained what tailoring is and what it cannot remove. This lesson is about how to do it. Good tailoring is not a matter of taste or habit. It follows a short, repeatable sequence: understand the context, decide the delivery approach, adjust each element, test every adjustment against the principles, record the decisions where people can find them, and review them as the project moves on. Organizations that do this well also build the common decisions into their own project method, so that each project manager starts from a sensible default instead of a blank page.

The running example is Ridgeline Water's project management office. After the smart metering project closed, the utility's executive team asked the office to turn the project's lessons into a tailoring guide for future projects. The guide is used throughout this course.

Start from the organization's own method

Most organizations that use PRINCE2 do not apply the manual directly. They embed it in their own project management method, with templates, approval thresholds, tools and terminology that suit them. Embedding is done once, at organizational level, by a project management office or center of excellence. Tailoring is then done for each project, within the organization's method. The two are easily confused, but they answer different questions. Embedding asks: how should this organization run projects in general? Tailoring asks: how should this particular project be run, given its context?

Ridgeline's office answered the embedding question with three tiers, based on value, risk and the number of external suppliers. Each tier has a default set of products, roles and controls. A project manager starts from the default for the project's tier and then tailors further, up or down, with the board's agreement.

Step 1: understand the context

The factors from lesson 1 are the starting point: scale, complexity, risk, delivery approach, organizational standards, commercial arrangements, regulation, team capability, sustainability and data. The project manager gathers what is known about each during starting up a project, usually from the mandate, the executive, the senior user and any previous lessons. The output is a short context statement, a few sentences that anyone can read to understand why the project will be run the way it is.

For Ridgeline's outage alert app, for example, the context statement reads: a six-month, 420 thousand project to give customers push notifications about water outages; one in-house agile team plus a small supplier for the notification service; moderate risk because outage messages affect public health advice; personal data in scope; delivery by two-week sprints. Each phrase in that statement points to a tailoring decision.

Step 2: choose the delivery approach

The delivery approach is how the specialist work will be done: predictive (plan the whole product, then build it), iterative or agile (build and release in increments, learning as you go), or a mix. The project approach, decided in starting up a project, records this choice. It affects tailoring more than any other single factor, because it changes how plans are expressed, how products are described, how progress is measured and how often the board needs information. PRINCE2 is compatible with all of these; lesson 4 shows how it fits agile delivery in detail.

Step 3: adjust each element

With the context and delivery approach known, the project manager works through the elements one at a time. A simple checklist keeps the work honest.

The most common technique for management products is merging. On a small project, the project brief and the project initiation documentation can be one document, the stage plan can live inside the project plan, and the logs and registers can sit in one workbook. Other techniques are renaming (using the organization's own terms), shortening (a one-page product description), holding products in a tool (a backlog for requirements, a dashboard for highlights) and recording verbal communications (a board decision taken in a meeting and confirmed by email). Each is fine provided the purpose is met and the record survives.

Step 4: test every adjustment against the principles

Before the tailoring is proposed, each adjustment is tested against the seven principles and the purpose of the element it changes. Project assurance is useful here, because people other than the project manager notice when a convenient shortcut has removed something essential. The test also works the other way: an element kept at full size that serves no purpose for this project is a candidate for tailoring down.

products = {   # name: (hours per use at full format, uses in project)
    "highlight report": (3.0, 12), "end stage report": (8.0, 2),
    "checkpoint report": (1.5, 24), "product descriptions": (2.0, 18),
    "registers and logs": (1.0, 26), "business case update": (6.0, 3),
}
tailored = {   # share of full effort after tailoring
    "highlight report": 0.3, "end stage report": 0.5, "checkpoint report": 0.0,
    "product descriptions": 0.4, "registers and logs": 0.6, "business case update": 0.7,
}
project_hours = 3800
full = sum(h * n for h, n in products.values())
light = sum(h * n * tailored[k] for k, (h, n) in products.items())
print(f"management product effort, full format: {full:.0f} h ({full / project_hours:.1%} of project)")
print(f"after tailoring: {light:.0f} h ({light / project_hours:.1%} of project)")
dropped = [k for k, v in tailored.items() if v == 0]
print("purposes to re-check for dropped items:", ", ".join(dropped))

management product effort, full format: 168 h (4.4% of project)
after tailoring: 61 h (1.6% of project)
purposes to re-check for dropped items: checkpoint report

The calculation shows a large saving, but it also flags something to check. Checkpoint reports have been dropped entirely. That may be fine if the team is co-located and the project manager sees progress daily in the team's board, because the purpose of checkpoint reports, keeping the project manager informed about work package progress, is met another way. The tailoring record should say so. If the team were remote, the same decision might leave the project manager blind.

Step 5: record the decisions

The tailoring decisions are recorded in the project initiation documentation, usually in a short section that describes how PRINCE2 has been tailored for the project and why. The record does not need to be long. A table that lists each significant adjustment, the reason and the purpose it still serves is usually enough. The section is approved by the board when it authorizes the project, and it becomes part of the baseline.

Records rules affect how products can be held in tools. US local governments usually follow a state records retention schedule, and state public records laws can reach project documents, including board decisions recorded only by email. The tailoring record should say where each management product lives and how long it is kept.

Step 6: review the tailoring as the project moves on

Tailoring decisions are reviewed at each stage boundary, as part of reviewing the project initiation documentation. Signs that tailoring is wrong are easy to spot once you look for them: reports that nobody reads, board meetings full of surprises, a team spending more time on administration than on products, or assurance finding the same gaps repeatedly. Each is evidence for a change, either lighter or heavier. Changes are made under change control and recorded, so that the PID always describes how the project is actually being run.

Tailoring conversations with the board

Tailoring proposals land better when they are framed around the board's own concerns rather than the method. Executives rarely care whether a document is called a highlight report; they care whether they will hear about trouble early enough to act. Ana Costa's tailoring briefing for the outage alert app's board was one page with three columns: what the board will see, how often, and what would trigger an immediate call. Board members could then judge the proposal against their own appetite for surprises. The same conversation also surfaced one adjustment Ana had not planned: the senior user asked for a short call-center impact note in each sprint dashboard, because her staff would feel the effect of a bad release first. That request went straight into the tailoring record, with the reason, and it changed the definition of done for every release to include a briefing for call-center staff.