Look at the last steering group pack for any programme you sponsor or lead. Count the slides. Then find the one headed "Decisions required" and note where it sits. In most packs I see it is the last content slide, reached — if it is reached — at minute fifty-two of a sixty-minute meeting, by which time the executive who needed to make the decision has started reading email under the table.
That is not a preparation failure. It is a design failure, and it is the single most common structural fault in Nordic transformation programmes. The steering group was set up as a meeting, with a cadence and an attendee list, and was never designed as a decision-making body with defined rights. The reporting expanded to fill the hour because reporting is what the PMO produces and nobody specified what else the forum was for.
I wrote earlier this year about the accountability vacuum in the middle of programmes. The steering group is where that vacuum becomes visible, because it is the forum where the deferred decisions surface — and are deferred again.
Reporting and deciding are different activities
A status report answers "where are we". A decision answers "what will we do differently". The first can be read in advance and needs no meeting. The second needs the people with authority in one place, with the options in front of them and a recommendation to react to.
Steering groups conflate the two because reporting feels like governance. A sponsor who has sat through forty slides of milestone status has a sense of having governed. But nothing changed as a result, and the programme leaves the room with the same open questions it brought in. Six of those cycles and the programme has lost a quarter to the appearance of oversight.
The fix is not a shorter pack. It is to invert the meeting: decisions first, with the status as pre-read, and a rule that anything reportable and not decision-bearing does not get airtime.
Design the decision rights before the calendar invite
Before a steering group is convened — or, for a programme already running, at the next re-baseline — three lists need to exist in writing.
What this forum decides. Scope changes above a threshold. Re-baselines of date or budget. Vendor escalations beyond the contract manager's authority. Changes to the target operating model. Go/no-go at stage gates.
What it has delegated, and to whom. Everything below the thresholds above, named to the programme lead, with the tolerances they operate inside. PRINCE2 has had a workable vocabulary for this for decades — tolerances, exceptions, escalation — and it is worth borrowing even in organisations that would never use the method by name.
What it escalates, and to whom. The decisions the steering group itself cannot make: funding beyond the approved envelope, changes that cross into another director's territory, anything that reopens the business case. If the steering group does not know where its own ceiling is, it will sit on those decisions indefinitely rather than admit it.
These three lists are the steering group's terms of reference, and most programmes either do not have them or have a version written by the PMO in the first month and never read again. Writing them takes an afternoon. Not having them costs months.
Keep a deferred-decision backlog, and age it
The most useful artefact a programme can add to its governance is a single list of the decisions that have been raised and not made, with the date each was first raised. Not a risk register — those are full of things that might happen. A list of things that need to happen and have not.
It should open every steering group. Not the status, not the highlights: the decisions the forum owes the programme, oldest first. An item that has been on the list for ninety days is a finding in itself, and the forum should have to say out loud why it is still there.
This is uncomfortable, which is the point. A steering group that sees its own decision debt every month behaves differently from one that sees a fresh pack of green milestones. The deferred-decision backlog is also the first thing an independent reviewer will reconstruct from the minutes, and it is better to have it than to have it reconstructed.
Consensus is a strength in execution and a liability in decision
Nordic organisations run on consensus, and it is a genuine advantage: once a decision is made, it is made with the people who will implement it, and it holds. The liability is in the making. In a consensus culture, hard decisions get pre-negotiated in corridors, and the forum becomes the place where the pre-negotiated outcome is ratified. If the corridor negotiation did not conclude — because the two directors who disagree have not been in the same corridor — the forum cannot decide either, and the item is deferred with everyone nodding.
The answer is not to import hierarchy. It is to make the decision explicit: options written down, a recommendation from the programme lead, a named decision-maker for that item, and a date. Explicitness does what hierarchy does in other cultures — it takes the decision out of the social realm, where naming a disagreement has a cost, and puts it in the administrative one, where the item simply has to be closed.
A steering group pack that presents a recommendation rather than a menu is doing this work. A pack that presents three options and no view is asking the forum to do the programme lead's job in public, and the forum will decline.
The steering group that cannot move money
Some steering groups are designed well and still cannot decide, because the decision requires money and the money is locked in an annual cycle. A re-prioritisation in May that needs funding moved between two cost centres waits for the budget round in October, by which time the programme has re-planned around the delay and the original decision is moot. I have written about what annual budgeting does to transformation programmes; the steering group is where the damage lands.
The practical mitigation is to give the forum a contingency it controls — a reserve within the approved envelope that the steering group can allocate without a budget round. Finance functions resist this and they are right to be cautious; the alternative is a governance body that can decide anything except the things that cost money, which is most things.
Decision records are about to become evidence
There is a regulatory reason to get this right now rather than later. The EU AI Act's obligations for high-risk systems — and Denmark's enterprises are among the fastest adopters in Europe, so more of them will be in scope than their boards assume — turn on being able to show what was decided, by whom, on what evidence. I have argued that AI Act compliance is a programme-management problem, and the steering group's decision record is where that argument becomes concrete. A forum that minutes "discussed" rather than "decided X because Y" is producing a compliance gap on top of a delivery one. The Act's text is specific about documentation; a well-run steering group produces most of it as a by-product.
What good looks like
Forty-five minutes. The deferred-decision backlog first, oldest item read aloud. Then the two or three decisions the programme brought, each with a one-page pre-read circulated forty-eight hours earlier, a recommendation, and a named decision-maker. The status as an appendix nobody presents. A record, circulated the same day, that says what was decided, why, and what it commits the organisation to.
Cadence follows the decisions, not the calendar. A programme with nothing to decide this month should cancel the meeting and say so; a programme with a vendor exit to decide should meet next week. The monthly slot is a default, not a design.
Designing this is most of what I do when I take on portfolio governance work — forums, cadence and reporting, built with the people who will sit in them and run through a first cycle before I step out. The sitting-in-them part matters. A governance design that the steering group did not help write is a governance design the steering group will politely ignore.