From templates to transformation: Rethinking project governance in the public sector

It would be easy enough to say that project governance in the public sector has never been stronger: Virtually every major project these days has its steering committee, their charters, their performance measurement, and virtually everything else that a project checklist should need. And yet it would also be easy enough to say that public sector projects can rarely be relied upon to deliver their outcomes.
Are these contradictions? Or are the models we rely on simply illusions?

Public sector project governance is designed to serve a process, not outcomes.
Structures are built to feed information upwards, so that more senior leaders can provide scrutiny over the project activities and machinations.
But how is that scrutiny applied?
Scrutiny is often limited to checking whether committee reports are submitted on schedule, or how regularly dashboards are updated – but not whether actual progress is being made. Governance instruments and processes focus on details and neglect the big picture.
For example, one of the most common traps I’ve seen in public sector projects is the “burn rate” – how much money is being spent against the budget, and how quickly the funds are disappearing. When it comes to administration of the project – and even delivery, if everything is internal – much of the project spend is going to be on the salaries of the project employees, which should get paid every two weeks or every month – making the burn rate quite predictable. But when the project deliverables have made only half the intended progress, these tools rarely point out that the deliverables just became twice as expensive (same spend for half of the progress).
Governance is only shown the expenses and timelines of the project.
In contrast, if a contractor-based project goes off track, missed milestones and unearned payments often show up immediately. But when everything is internal, project inertia is easy to hide – especially when the governance tools are designed to track financial flow, not delivery velocity.

Unfortunately, audits rarely do much to change this narrative. Even the heaviest, most invasive audits tend to assess existence over effectiveness.
I can’t remember how many times my teams have presented preliminary audit findings to me, while basically skipping over all of the governance criteria. ‘They have an oversight committee,’ the team might say, ‘and they meet every quarter and take lengthy meeting minutes. All of their reviewed documents are stored in an archive.’ Okay, I would challenge: they’re doing everything they’re supposed to do, but is the project actually on track for success? Have we covered all of our bases while actually making no forward progress?
All too often, this question of effectiveness is rarely asked. These types of health checks that don’t ask the hard questions might make everyone feel good about the compliance, but they won’t do anything to change how the public perceives government project failures.

And to show just how pervasive this compliance approach can be, a number of years ago the Canadian federal government implemented one of the most expensive project failures in recent memory: the Phoenix project. A $300 million budget to overhaul the legacy human resources and payroll management systems was designed to save $70 million per year – but instead has cost almost $4 billion and is in the process of being completely 
replaced.
This complete and abject failure led to a number of reviews, some formal and others less so. One of the lesser-publicised reviews was the request from seniormost public officials to ask how a more robust project management policy could have prevented the Phoenix disaster.
This led to a number of teams – including the government-wide project oversight body to which I was a member – to scour the departments and agencies for advice.
A thorough investigation found that there was one department that had the most mature centralised Project Management Office, with integrated departmental policies, established governance, and built-to-purpose tools and templates that made managing projects a breeze. That department? Public Services and Procurement Canada – the department that had been in charge of the Phoenix project.
Apparently, the tools and templates were ideal – it was only the project that was the problem.

Governance cannot function as a series of org charts and process charts. Governance needs to be about leadership and accountability. Senior leaders need to demand evidence of real progress, not just paperwork. They can’t just expect a story, crafted by an inert template.
They need to demand how the project is really doing: not in some ethereal sense, but by asking the question: are we on track to deliver exactly what was expected, on time, and on budget? No qualifiers, no “additional context.” It’s these types of hard questions that governance needs to adopt – not more systems or “best practices.”
Tough questions.
Tough challenges.
Real leadership.