PRINCE2 Overkill

The test: PRINCE2 principles must always be applied; the practices, processes, products and role descriptions are tailored - combined, simplified, renamed or reduced - according to scale, risk and environment. If the principle survives, the paperwork can go.

Legitimately scaled:

• Combine starting up a project and initiating a project into one short activity; a short project initiation document with the business case embedded in it.
• Two management stages (delivery, then closure) rather than four.
• One person can hold project manager, team manager and project support roles; project assurance from a colleague outside the team.
• A risk log rather than a risk register meeting; review at checkpoints and stage boundaries.
• Short highlight reports; board meetings by exception plus the mandatory decision points.

Cannot be scaled away:

• A stated, reviewed business case - a cloud move holding 40,000 donors' data has real benefits and real data protection risk.
• Defined roles and accountabilities - the disengaged executive is a bigger threat here than the paperwork.
• Focus on products: product descriptions and acceptance criteria for the migrated data and cutover.
• Plans with tolerances and a route to escalate beyond them.
• Lessons and a closure step with handover and benefits review.

Who and how. The project manager proposes the tailoring approach; the project board approves it when authorising initiation, because tailoring changes the control the board is buying. It is documented in the project initiation document, kept under change control, and revisited at each stage boundary - tailoring decided once and forgotten is just a smaller waterfall.

Handling the PMO. The PMO's method is a default, not a principle. The route is not quiet non-compliance:

• Produce a one-page tailoring statement showing, product by product, what is being combined, dropped or reduced and why - scale, low technical complexity, single supplier, four-month duration.
• Show what compensating controls exist where a control is removed (e.g. no weekly risk meeting, but risk reviewed at each checkpoint and reported in the highlight report).
• If the PMO insists on full products, escalate to the project board: the board, not the PMO, is accountable for the project's governance, and a 60-page initiation document on a £90k project is a cost with no benefit.
• Record the outcome in the lessons log so the organisation's method can adapt - one of the main purposes of learning from experience.

The risk is the appearance of governance without its substance. A board that approves on trust provides no challenge to the business case, no check on risk, and no senior cover when the supplier underperforms. Under manage by exception, the tolerance mechanism depends on the board actually engaging when an exception is raised. A disengaged executive also leaves the project manager carrying accountability she does not hold.

Minimum viable involvement - four short, real engagements rather than a monthly ceremony:

1. Authorise initiation - agree the business case, the tolerances and the tailoring, including the data protection position for 40,000 donor records.
2. Authorise the project - approve the plan and the stage boundaries (with two stages this is quick).
3. Exception decisions - remain available to decide within days, not weeks; agree in advance how a decision will be taken if he is unreachable.
4. Authorise closure - confirm acceptance and benefits review, and that handover to the cloud provider is complete.

Also negotiate project assurance: with the executive disengaged, appoint someone with the time and authority to test the project, reporting to the board. Reduce frequency of board meetings, not the decision rights.