A steering committee that meets is not the same as one that resolves anything. We assign decision rights explicitly, before Build starts, not after the first stalemate.
Most project governance breaks down because nobody wrote down, in advance, who has the authority to end a disagreement. We assign that explicitly before Build starts, not after the first stalemate.
Agreed during Design, in writing, before it's ever needed.
The steering committee, made up of your sponsor, your process owners, and our engagement lead, meets on a fixed cadence agreed at kickoff, typically every two weeks for a mid-sized implementation. Between meetings, anything that needs a faster answer gets an out-of-cycle session rather than sitting in a queue until the next scheduled slot.
Every steering meeting works from the same written agenda: open decisions awaiting sign-off, budget and timeline status against plan, and any risk that's moved since the last meeting. Nothing gets raised for the first time verbally in the room; it's on the agenda in advance so people can actually think about it beforehand.
On any project with more than one stakeholder, two people will eventually want different things from the same decision. Because the table above already says who owns that category of decision, the resolution path is usually clear before the disagreement even starts.
Where the table itself is ambiguous, the default escalates one level: an unresolved design disagreement goes to the steering committee rather than staying stuck between two process owners indefinitely. We'd rather over-escalate occasionally than let a decision quietly stall for weeks.
Your project sponsor, the process owners most affected by the current stage, and our engagement lead. Additional specialists join when a specific topic needs them, but the core group stays small on purpose.
We'll say so during Design, before it becomes a problem, and help you assign one. An unassigned decision right is one of the most common causes of a project stalling mid-stream.
Yes, if your organisation changes who's actually available or empowered to decide. Any change to it is itself logged and communicated, the same as a scope change.
A sponsor is one person. Most projects have five or more distinct categories of decision that don't all belong to the same person, and treating them as if they do is exactly what causes bottlenecks.
The sponsor holds the tie-break vote. That's agreed and written down at kickoff, specifically so it's never negotiated in the moment a real deadlock happens.
Tell us how your organisation currently makes ERP decisions. We'll tell you honestly where the gaps in that model usually show up.
With someone who has run this before.
The six stages this page fits into, end to end.