Ask an IT team at most colleges or academy trusts how they govern their projects, and you’ll usually get one of two answers. Either there isn’t much formal governance at all, and IT simply gets on with things, or every project goes through the same process, regardless of size. That process is often borrowed from estates and capital projects, or introduced after something went badly wrong.
Both approaches have a cost. Too little governance leads to scope creep, unwelcome surprises, lack of visibility to senior leadership and projects that never quite finish. Too much leads to delay, paperwork that nobody reads and “project teams” spending more time reporting on the work than doing it. In my experience, the second problem is just as common as the first, and it is far less likely to be challenged, because it looks like good practice. I also put project teams in quotes because we all know that this often means the IT Team being asked to undertake projects alongside business as usual with no additional support.
In this piece, we look at how to match governance to the job, using a simple tiered approach that works well for organisations in these sectors no matter the size.
Why one size doesn’t fit
Most recognised project methods are clear that they should be adapted to the project. PRINCE2, for example, has tailoring built in as one of its core principles. In practice, though, the templates tend to get adopted wholesale and applied to everything.
When governance is heavier than the work needs, a few things tend to happen. Small projects take months to get approved, so the benefit arrives late or the original problem has changed. Boards meet to review projects that have nothing to decide, and so get into the habit of nodding things through, which is a real risk when a project does need a difficult decision. And, perhaps most damaging, people find workarounds. Work that should be a project gets relabelled as “business as usual” to avoid the process, and so it ends up with no governance at all.
The aim is not less governance. It is the right governance for each piece of work, so that the effort goes where the risk is.
What decides how much governance a project needs
Cost is the obvious starting point, but on its own it is a poor guide. A large, like-for-like device replacement can cost a lot while carrying very little risk. A small change to how student data flows between systems might cost almost nothing and carry a great deal.
A better approach is to consider a handful of factors together:
- Impact on teaching and learning. Could the project disrupt lessons, assessment or exams if it goes wrong?
- Reach. How many people, departments or sites are affected?
- Novelty. Has the organisation done something like this before, or is it new technology, a new supplier or a new way of working?
- Reversibility. If it goes wrong, can you easily roll back?
- Dependencies. Does it rely on suppliers, other projects or decisions outside IT’s control?
- Data and safeguarding. Does it change how personal data is processed, or affect filtering, monitoring or safeguarding systems?
- Cost and contractual commitment. Including whole-life costs and any procurement requirements.
A project that scores low on all of these needs very little formal governance. A project that scores high on several needs a lot, whatever it costs.
A simple three-tier model
For most colleges and academy trusts, three tiers are enough. More than that tends to create debate about which tier a project belongs in, rather than getting on with it.
| Light | Standard | Full | |
|---|---|---|---|
| Typical examples | Like-for-like device refresh, software upgrades, small wireless extensions | New departmental system, MFA rollout, single-site network refresh | MIS replacement, merger integration, multi-site infrastructure, new campus fit-out |
| Approval | IT lead or budget holder | Sponsor on SLT | SLT or governors, with a business case |
| Documentation | One-page brief | Short project brief, plan, risk and issue log | Business case, project initiation document, full plan, change control |
| Reporting | Tracked in the team plan | Regular highlight report to sponsor | Project board, stage reviews, reporting to governors |
| Closure | Short closing note | Closure report with lessons learnt | Formal closure, benefits review after go-live |
The tier should reflect what is changing, not just what is being bought. A laptop refresh that simply replaces old devices with new ones of the same type is a Light project. A laptop refresh that also moves the organisation to a new management platform, changes how devices are allocated to students or introduces a new operating system is a different thing entirely, and probably belongs in Standard or above. The hardware is the same, but the change, and therefore the risk, is very different.
Before we look at these in a little more detail, it is also worth considering the sister topic of how projects get into the pipeline in the first place. To determine which tier a project best suits, that project has to be approved and form part of the agreed work plan. Often projects fail because they simply crop up out of nowhere and are suddenly urgent requirements. In addition to project management tiers, there also needs to be a project pipeline process that assesses priority, risk and workloads. Perhaps a topic for another time.
The heavyweight end
At the top end, full governance is not bureaucracy. It is what protects the organisation when a project is large, complex and difficult to reverse.
As an example, the Nottingham College City Hub Project included IT elements to the tune of £2 million, and these had to be delivered alongside the master build schedule. The IT portion of the project was dealt with no differently than any other element of the programme, with regular reporting at the Capital Project Board meetings overseeing the project. This ensured that risks could be identified early (and as the project ran into Covid this became increasingly challenging) and that timescales for delivery could be aligned – parts of the project such as AV were procured as part of the IT project but installed as part of the main contractors responsibilites which required precise timing.
The point is that this level of control is worth the investment for projects like this. It simply isn’t worth the same investment for the much larger number of smaller projects that most IT teams deliver each year. Conversely, those smaller projects without any project management behind them become hard to manage and even harder for senior leaders to have confidence in.
Making it work in practice
A tiered model only helps if it is used consistently. In my experience, the following make the most difference.
Agree the tiers with senior leaders up front. The tiers, and what each requires, should be agreed with SLT and written down. That way, a Light project going ahead with a one-page brief is following an agreed process, not cutting corners.
Assign the tier at the start, and let it change. A short triage when a project is first proposed, using the factors above, is usually enough to assign a tier. Agree some simple triggers for moving a project up a tier, such as a significant increase in cost, a slip past a critical date or a change in scope. Projects can move down too, if the risk turns out to be lower than expected. I’m sure we’ve all been involved in “pilot” projects that turn into business critical during delivery and those two ends of the spectrum require different levels of project oversight.
Keep the templates short. If the Standard brief runs to ten pages, people will either avoid it or fill it with text nobody reads. A good brief for most projects fits on a couple of pages.
Report by exception. Highlight reports should focus on what has changed, what is at risk and what decisions are needed. A report that says “on track” for six months, then reports a crisis in month seven, hasn’t helped anyone. Again this needs agreement up front as to what each status means, amber doesn’t mean a total change of thinking it means we’ve identifed a risk and are managing it. Even a red status just needs an explanation and what the remediation steps are.
Don’t drop the essentials at any tier. Even the lightest project needs a clear owner, a defined scope, communication with the people affected, and a clear point at which it is finished. The tier changes how much is written down and who approves it, not whether these basics happen.
Keep a single view of everything. Light projects can be individually simple but collectively demanding. In education, many of them land in the same summer window, competing for the same people, the same suppliers and the same few weeks before enrolment and the start of term. A one-page view of every project in flight, whatever its tier, is one of the most useful tools an IT leader can have. It also gives senior leaders an honest picture of what the team is being asked to deliver.
Signs your governance is out of balance
If you’re not sure whether your current approach is working, these are some common warning signs:
- Small projects routinely take longer to approve than to deliver.
- Project boards rarely make decisions, or regularly meet with nothing to decide.
- Work is being described as “business as usual” to avoid the project process.
- Real business-as-usual activities are failing because of projects that leaders weren’t even aware of.
- Larger projects have been started with little more than an email approval.
- Nobody can easily list every project currently in progress.
- Senior leaders are unable to identify successful projects because they were never sure how long projects were meant to take or what they were meant to cost.
- Projects are rarely formally closed, and lessons learnt are not captured or used.
If several of these sound familiar, it’s probably worth revisiting how projects are governed.
Final thoughts
Good project governance should feel proportionate to the people involved in it. Senior leaders should get the right level of oversight for the risk they’re carrying, without being drawn into the detail of every small change. Project teams should spend their time delivering, not feeding a process. A simple, agreed tiered approach is one of the easiest ways to achieve both, and it tends to improve delivery at every level, not just for the largest projects.
Whether you’d like help developing a project management framework or a review of your current arrangements, or indeed help with current or future projects please get in touch.
0 Comments