Project Assurance must not report to the project manager. Phoenix is the proof

Every project reporting line in the world has the same structural weakness. The person who tells the board how the project is going is the person whose performance the board is judging.

PRINCE2 has a specific answer to this, and it is one of the least implemented parts of the method. Project Assurance is an accountability held by the project board — not by the project manager — covering business, user and supplier assurance. It exists so that the board has a source of information about the project that does not pass through the project manager.

In the eleven roles of PRINCE2 Agile Version 2, Project Assurance is still there, listed alongside Project Executive, Chief Product Owner, Senior Supplier, Agile Coach, Project Manager, Project Support, Product Owner, Team Coach, Developer and Tester. The method has kept it.

Most organisations have not. In the majority of project structures I have reviewed, “assurance” means either a quality function that reports through the programme director, or an internal audit engagement scheduled for after go-live. Both report, ultimately, to somebody with an interest in the answer.

There is one audit report that makes this case better than any argument I could construct.

Phoenix

In February and April 2016, the Government of Canada moved federal pay administration onto a single PeopleSoft-based system called Phoenix, together with a centralised pay centre, replacing forty-year-old systems across roughly 101 departments and agencies.

The Auditor General of Canada reported on it in spring 2018. What follows is from that report.

The budget drove the functionality

The approved software budget was $155 million. IBM had estimated the true cost of the work at $274 million.

Phoenix executives closed that gap by removing or deferring over 100 critical pay processing functions.

Read that again, because the sequence matters. The budget was fixed first. The scope was then cut to fit it — not by the sponsor, not by the board, but inside the project, in order to stay within an approved number.

That is a rational response to an impossible constraint, and it is exactly what a governance framework exists to prevent. In PRINCE2 terms, a forecast breach of cost tolerance on that scale is an exception. The project manager’s obligation is to raise it to the project board, which then decides whether to grant more tolerance, reduce scope with its eyes open, or stop. Deciding inside the project which hundred functions to remove is not managing by exception. It is managing the appearance of an exception.

Testing was not allowed to change anything

The pilot was cancelled in June 2015 because of major defects. No comprehensive system-wide testing was performed before go-live.

Twenty per cent of reviewed functions failed testing and were not retested.

The Auditor General’s characterisation is that executives prioritised schedule and budget over functionality and security, and proceeded with known critical defects.

A test that cannot stop a go-live is not a control. It is a measurement, and measurements that nobody is obliged to act on are how organisations acquire a documented history of having known.

And nobody outside could see it

Here is the finding, and I would engrave it above the door of every programme office:

“There were no oversight bodies independent of the project management structure.”

Only Phoenix executives briefed the Deputy Minister on status.

Internal audit did not audit Phoenix, despite identified risks. The Deputy Minister received no independent advice from the Treasury Board Secretariat or from other departments.

So the accountable official’s entire picture of the programme came from the people delivering it. Not because anyone lied — the report does not need to allege that — but because a single reporting channel filters by construction. Everything that reached the Deputy Minister had passed through people with a professional interest in the programme continuing.

What it cost

The original total budget was $310 million, of which $155 million was for the software.

At 19 April 2017, 51 per cent of employees had a pay error. There were over 494,500 outstanding pay requests. Outstanding pay errors at 30 June 2017 exceeded $520 million.

Later remediation and replacement figures reported in Canadian national media run into the billions; those are media-reported numbers rather than audit findings, and I would check them against the Auditor General or Public Services and Procurement Canada before putting them in a board pack.

The Auditor General located accountability with the Deputy Minister of PSPC and three named Phoenix executive roles. No public dismissals have been confirmed.

What independent assurance actually looks like

The PRINCE2 answer is structural rather than procedural, and it costs less than people expect.

Project Assurance is a board accountability, delegated to named people who do not report to the project manager. It splits three ways:

• Business assurance — is the business case still valid? Are the costs and benefits real? This should sit with someone from finance or strategy, appointed by the Executive.
• User assurance — will the users be able to use this, and does it do what they need? Appointed by the Senior User, and it should be somebody who does the actual job, not their director.
• Supplier assurance — is what is being built technically sound and deliverable? Appointed by the Senior Supplier.

The three of them attend the same stage boundary as the project manager and give their own opinion. Not a countersignature on the project manager’s report. Their own opinion, in their own words, on the record.

That is it. It is not a function, it does not need a budget line, and it does not require anyone to be full time. What it requires is that three people are named, that they have a reporting line to the board that does not route through the project manager, and that they are asked to speak at every stage boundary whether or not they have anything alarming to say.

The moment assurance speaks only when concerned, its silence becomes ambiguous — and ambiguous silence is indistinguishable from a controlled programme.

Six tests for your own structure

Who tells the board that the project is in trouble? If the honest answer is “the project manager,” you have Phoenix’s structure. It does not mean you will get Phoenix’s outcome. It means nothing in your structure prevents it.

Has anyone outside the programme watched the product being used? Not a demo prepared for the board. A real user, doing a real task, watched by someone with the authority to stop the go-live.

What happened to the last test failure? Trace one. Was it fixed, retested and closed, or was it accepted, deferred, or reclassified? Twenty per cent of Phoenix’s reviewed functions failed and were not retested; TSB carried 4,424 open defects into a big-bang migration. The pattern is identical and it is visible in advance if anyone looks.

Was scope ever reduced to fit a budget, and who approved it? If scope has moved and the budget has not, someone made a trade-off. Find out whether the board made it or was told about it.

Does internal audit have this programme on its plan? Phoenix’s did not. This is a question the audit committee can ask in thirty seconds and it is one of the highest-value questions available to a non-executive.

Is the assurance opinion recorded separately from the project manager’s report? Two documents, not one with a signature block. If they always agree, that is fine and worth knowing. If they have never disagreed in two years, your assurance is not independent, whatever the organisation chart says.

Why this is a board matter, not a PMO matter

I spend a fair amount of my time now in and around board and committee work, and the pattern I see is consistent: directors receive project reporting that is accurate, well presented, and entirely derived from the project.

Committees ask good questions about the numbers in front of them. Very few ask where the numbers came from, and almost none ask whether anybody independent has seen the thing working.

The Phoenix finding — “there were no oversight bodies independent of the project management structure” — is not a Canadian problem or a public sector problem. It is the default state of most project governance everywhere, because independent assurance costs something today to prevent something that might not happen, and because the people best placed to insist on it are the people it exists to check.

PRINCE2 has had the answer in the method for thirty years. It is three named people and one extra page at each stage boundary.

The alternative is a system that pays half a million people incorrectly and an audit report that explains, very politely, that nobody outside the project was ever in a position to notice.

Appointing assurance when you are not a government department

The usual objection to independent assurance is that it is a luxury for organisations with more people than yours. I do not accept this, and here is the version that works in a mid-sized company.

Business assurance goes to somebody in finance who is not on the project. A finance business partner is ideal. Their obligation is narrow: at each stage boundary, confirm in writing whether the business case still holds at current forecast cost, and whether the benefits are still owned by a named person in the business who agrees they are achievable. That is perhaps two hours a quarter.

User assurance goes to somebody who does the job the system will change — a branch manager, a shift supervisor, a claims handler. Not their director. The obligation is to have personally watched a real user attempt a real task on the actual product since the last stage boundary, and to say what happened. If they have not been able to, that is the report.

Supplier assurance is the hard one when the supplier is external, because you are asking somebody to opine on technical quality they may not be able to judge. Two options work. Use an internal technical person from a different part of the organisation, or buy a small independent technical review — a few days, not a programme. What does not work is accepting the supplier’s own quality reporting as assurance, which is what most organisations do.

Total cost: perhaps five person-days a quarter on a substantial programme. Against Phoenix’s $520 million of outstanding pay errors, or Birmingham’s move from a £19.965 million budget to £170 million, that is not a difficult business case — provided somebody makes it before rather than after.

One rule matters more than the structure. Assurance must report at every stage boundary, in writing, whether or not it has concerns. The moment assurance speaks only when worried, its silence becomes evidence of health, and silence is a very poor evidence base. I would rather read twelve consecutive assurance reports saying “nothing material to raise” and know what that phrase costs to write, than receive one alarming report after two years of nothing.

Three questions for an audit committee

I sit on the other side of this now often enough to know what a committee can realistically ask in the time available. Three questions, none of which requires technical knowledge:

“Who, other than the programme, has told us how this programme is going — and when?” If the answer names only people inside the programme, you have the Phoenix structure.

“Is this programme on internal audit’s plan? If not, why not?” Phoenix’s was not, despite identified risks. This question takes thirty seconds and has a disproportionate effect, because the answer is a matter of record.

“Has scope been reduced since approval, and did we approve the reduction?” Over 100 critical pay functions were removed inside Phoenix to fit a budget. Whoever approved the budget should have been the one to approve the consequence.

Why this keeps happening

It is worth asking why a control this cheap is this rare, because the answer is not ignorance.

Independent assurance imposes a cost today against a benefit that is invisible if it works. Nobody is ever thanked for the catastrophe that did not occur. The programme director experiences it as friction, the project manager experiences it as a second reporting burden, and the sponsor experiences it as a slower answer to a question they wanted answered quickly.

And the people best placed to insist on it are, structurally, the people it exists to check. A programme director asked to appoint someone who can go over their head to the board is being asked to reduce their own control in exchange for organisational safety. Some do it. Most do not, and it would be strange to expect otherwise.

Which is why it has to be a board requirement rather than a programme choice. The Executive appoints Project Assurance. Not the programme. That single line in PRINCE2 is the whole design, and the number of organisations that quietly invert it is the reason the Phoenix finding keeps being written in different countries with different systems and the same sentence.

Sources

• Office of the Auditor General of Canada, Report 1 — Building and Implementing the Phoenix Pay System, Spring 2018 — oag-bvg.gc.ca
• PeopleCert, PRINCE2 Agile Foundation (Version 2) syllabus, v2.0 (May 2025) — the eleven roles including Project Assurance — peoplecert.jp
• Slaughter and May, Independent Review of the 2018 TSB Migration (2019) — open defects at go-live, cited for comparison