PRINCE2 Foundation (PRINCE2): A Merger Project Where Nobody Owns the Users

Four distinct failures, each with a PRINCE2 hook:

1. Role not being performed. The senior user is accountable for specifying user needs and confirming that benefits are realised. Five missed workshops means the user community is unrepresented and requirements are being guessed - a failure of defined roles and responsibilities, not a personality clash.
2. Communication is one-way. A weekly RAG report is status broadcast, not engagement. The communication management approach should identify stakeholders, what they need, when, in what format and - critically - who owns the relationship. There is no two-way channel for the two legacy teams or the offshore architect.
3. Team development stage ignored. Two groups with different vocabulary and history are in a storming phase. They need shared definitions, agreed working norms and joint problem-solving, not a weekly league table of blame.
4. Estimation treated as an arithmetic problem. Three consecutive 30% misses is a systemic pattern, not bad luck; the team manager and senior supplier own it, and the lessons log should already be capturing it.

The project manager's error is treating all four as communications rather than as accountability, engagement and team-development problems.

The estimates sit with the team manager under Managing Product Delivery; the project manager should not re-estimate on the supplier's behalf, because that blurs accountability and leaves the plan owned by nobody.

What to do instead:

1. Require checkpoint reports with progress against the work package plan, not just narrative updates, so the variance is visible inside the stage rather than at the end of it.
2. Agree with the team manager that the next work package estimate is produced from measured cleansing throughput from the previous one, and record the basis.
3. Update the stage plan with a realistic forecast and flag the forecasting problem to the senior supplier - it is a supplier performance issue and the senior supplier's role is to make sure the supplier's resources and commitments are credible.
4. If the revised forecast threatens stage tolerances, raise it as an issue with an exception report rather than absorbing it silently.

On the people side: challenge the estimate, not the estimator, and do it privately. Public criticism of an offshore team in a status meeting will make the next estimate defensive rather than accurate.

It solves attendance but not representation, which is the wrong fix.

The senior user role exists so that the people who will use and benefit from the product specify their needs and later confirm the product meets them. A finance director may be an excellent executive - owning the business case and holding the board's decision-making - but unless he genuinely represents the tenant-services community, appointing him as senior user leaves that accountability uncovered while appearing to cover it.

A defensible approach:

1. Keep accountability explicit: name a senior user drawn from operations with real authority over requirements and acceptance, with a named deputy to cover absence.
2. Consider whether the finance director should sit as executive or as an additional board member, rather than displacing the user voice.
3. Record the arrangement in the role descriptions and in the organizing section of the project initiation documentation, so acceptance decisions later cannot be disputed.

PRINCE2 allows roles to be combined or shared where the project is small enough - but the accountability itself cannot be quietly dropped, and 'keen and turns up' is not a criterion for it.