Tailoring these practices: agile, small projects, digital and data

PRIN-110 described tailoring as a principle: PRINCE2 is adapted to suit the project's environment, size, complexity, importance, capability and risk. Tailoring the control practices does not mean dropping them. A small project still needs to know what good looks like, what might go wrong, how changes are decided and whether it is on track. What changes is formality, frequency and the tools used. This lesson looks at tailoring quality, risk, issues and progress for small projects, agile delivery, projects within programs, commercial relationships and data-rich digital environments. PRIN-150 covers tailoring in depth and PRINCE2 Agile in particular.

What must stay, whatever the tailoring

Some elements of each practice are essential even on the smallest project, because without them the practice simply does not exist. Others can be scaled down or combined. The table below is our summary of a sensible minimum; the official manual sets out the minimum requirements for applying each practice.

Small projects

On a small project, such as replacing a community center's booking system over three months, the four practices can share a single page of approach and a single log. Quality might be a short list of acceptance criteria agreed with the center manager and a test checklist. Risks, issues and lessons can sit in one spreadsheet with a type column. The project manager might report weekly in a five-line email to the executive, with tolerances of two weeks and ten percent. These are real practices, just proportionate ones.

Agile delivery

Many projects now deliver at least some products using agile methods. The control practices map onto agile practices naturally, but the emphasis shifts. In agile delivery, time and cost are usually fixed by timeboxes, while scope is the main area of flexibility. Quality is built in through acceptance criteria on each user story and a team definition of done, rather than inspected at the end. Risks are surfaced in daily stand-ups and retrospectives. Most changes are handled by reprioritizing the backlog within the agreed scope tolerance, with only changes beyond that tolerance going to the board.

The code below shows a typical agile progress forecast. Ridgeline Water's customer portal is built in two-week sprints with a fixed end date. The must-have features total 180 story points, and the scope tolerance allows should-have and could-have features to be dropped, but not must-haves. From the velocity of the sprints so far, the code forecasts how many points will be delivered by the end date and whether the must-haves are at risk.

import statistics
velocities = [22, 26, 19, 24, 25]            # points per sprint so far
sprints_total, sprints_done = 12, len(velocities)
done = sum(velocities)
backlog = {"must": 180, "should": 60, "could": 40}
remaining_sprints = sprints_total - sprints_done
v_mean = statistics.mean(velocities)
v_low = min(velocities)
fc_mean = done + v_mean * remaining_sprints
fc_low = done + v_low * remaining_sprints
print(f"delivered so far {done} points; mean velocity {v_mean:.1f}")
print(f"forecast by end date: {fc_mean:.0f} points (mean), {fc_low:.0f} points (lowest velocity)")
cum = 0
for level, pts in backlog.items():
    cum += pts
    status = "safe" if fc_low >= cum else "at risk" if fc_mean >= cum else "unlikely"
    print(f"up to {level:6} {cum:3} points: {status}")

delivered so far 116 points; mean velocity 23.2
forecast by end date: 278 points (mean), 249 points (lowest velocity)
up to must   180 points: safe
up to should 240 points: safe
up to could  280 points: unlikely

Five sprints have delivered 116 points, a mean velocity of 23.2. At that rate the team will deliver about 278 points by the end date, and even at its lowest velocity about 249. The must-haves and should-haves are safe even at the lowest velocity, but the full set of could-haves, which would need 280 points, is unlikely: even the mean forecast falls just short. In PRINCE2 terms, the project is within scope tolerance: the board's tolerance allows could-haves to be dropped. The product owner will decide which could-haves to keep, and no exception is needed. If the forecast showed must-haves at risk, scope tolerance would be threatened and the board would need to decide.

Projects within programs and commercial relationships

When a project is part of a program, the program usually sets some of the controls. Its risk management approach may define the scales the project must use; its change control may decide changes that affect other projects; and its reporting may require project highlight reports in a standard format. The project's approaches should refer to the program's rather than duplicating them. In a commercial relationship, the contract shapes the control practices: quality criteria may be contractual acceptance tests, transfer of risk is achieved through contract clauses, changes to scope are contract variations with their own procedure, and progress reports may be contractual deliverables. PRINCE2 7's commercial management approach is where these arrangements are described, and PRIN-120 discussed the customer–supplier relationship that underlies them.

Digital and data

PRINCE2 7 places more emphasis than earlier editions on the use of data and digital technology in project management. In practice this means that registers live in shared tools rather than documents, reports can be generated from live data rather than written, dashboards can show tolerance used in real time, and analysis such as Monte Carlo forecasting is within reach of ordinary projects. It also brings new responsibilities: data quality, version control of plans held in tools, access control, retention of project records and protection of any personal data in registers, such as names in issue logs or customer details in quality records. The digital and data management approach is where a project records how it will handle these.

Personal information in project records may be subject to privacy law. In the United States there is no single general federal privacy law; obligations come from sector laws, state consumer privacy laws such as California's, and public records and privacy rules for government bodies. A municipal utility, for example, must follow its state's public records and privacy requirements, which may also make some project records open to public request. Project registers that name customers or staff should follow the organization's rules on access and retention.

Recording tailoring decisions

Tailoring is a decision, and like any decision it should be recorded and approved. PRINCE2 expects the project initiation documentation to explain how the method has been tailored, so that the board, assurance and any auditor can see what the project has chosen to do and why. A short tailoring record is usually enough. It lists each practice, what has been simplified or adapted, the reason, and any compensating control. Recording tailoring has two benefits: it prevents tailoring from becoming an excuse for skipping work, and it gives the next similar project a starting point.

Tailoring should also be revisited. A practice that was simplified at the start of the project may need more formality when the project grows, when an external supplier joins, or when a near-miss shows that a control was too light. Stage boundaries are the natural point to review the tailoring record alongside the next stage plan.