Governance is supposed to help. In most change programs, it does the opposite. It creates layers of approval that slow decisions down, forums where the same issues are discussed repeatedly without resolution, and reporting that consumes more effort than the work it describes. The problem is not too much governance or too little. It is governance designed for the wrong purpose: oversight instead of decision-making, control instead of clarity. This guide covers two connected challenges. First, how to design governance that actually enables decisions. Second, how to make ownership of the change genuinely clear so that the right people are making the right calls at the right time.
Most governance structures are designed by asking “what do we need to oversee?” The better question is “what decisions does this program need to make, and what is the fastest, clearest way to make them well?” The five principles below describe what governance looks like when it is designed for decision-making rather than for control.
Rate your current governance against five criteria. For each one, score from 1 (strongly obstructing) to 5 (fully enabling). Be honest: the value of this assessment depends on accuracy, not optimism.
How quickly does your governance enable decisions to be made once the relevant information is available?
Decisions are made within days. Clear authority means the right person decides without waiting for a committee cycle. Urgent decisions have an explicit fast-track route.
Decisions wait for the next scheduled board. Multiple layers of approval are required even for low-risk items. People hold off deciding because they are unsure whether it is their call.
Does every person involved in the program know exactly what decisions they can and cannot make?
Decision rights are documented and communicated. People can name who owns each type of decision. There are no grey areas between the program and the business.
People escalate decisions they could make themselves because they are unsure of their authority. The same decision gets discussed in multiple forums. Ownership is assumed but never confirmed.
When issues are escalated, do they get resolved quickly and clearly, or do they enter a loop?
Escalation paths are defined and short. Escalated issues get a decision within one meeting cycle. The person who escalates is told the outcome and the rationale.
Escalated issues bounce between forums. The steering committee defers decisions back to the working group. Issues are marked as escalated but nobody tracks whether they were actually resolved.
Does your governance generate more value than it costs in time, effort, and delay?
Reporting is proportionate to risk. Low-risk workstreams have lighter governance. People see governance as a support mechanism, not a bureaucratic hurdle. Meetings are short, focused, and decisive.
The program team spends more time preparing for governance meetings than doing the work. Reports are produced that nobody reads. Governance requirements are the same regardless of the size or risk of the decision.
Do senior stakeholders trust the governance to surface problems early and make sound decisions?
Sponsors get honest, concise updates. Bad news travels fast because the governance rewards transparency. Stakeholders defend the program when challenged because they trust the information they receive.
Reports are optimistic by default. Problems are hidden until they become crises. Sponsors are surprised by issues that the program team knew about weeks ago. Trust is low and micro-management increases.
Governance structures are only as effective as the ownership beneath them. If it is not clear who owns what, governance becomes a forum for discussion rather than a mechanism for decision. Below are the five critical ownership roles in any change program, what each one owns, and where the boundaries are. Click any role to see the detail.
Defining roles is necessary but not sufficient. Ownership only becomes real when it is specific, personal, tested, and regularly reviewed. These five principles turn theoretical ownership into practical accountability.
Most programs track project risks meticulously and change risks not at all. A project risk is a system delay or a budget overrun. A change risk is a sponsor who has quietly disengaged, a workforce that is developing workarounds instead of adopting, or a culture that is hardening against the new way of working. These risks do not appear in RAID logs because they are difficult to quantify, uncomfortable to name, and politically sensitive to escalate. But they are the risks that determine whether the change actually lands. The following framework identifies the five change-specific risks that every program should be actively tracking, with guidance on how to spot them early and what to do when they emerge.
Use this checklist to assess whether your governance and ownership model is built for decisions or built for oversight. Each item represents a characteristic of programs where governance enables delivery rather than obstructing it.
0 of 10 complete
This topic is part of Execution, the fourth pillar of the TCA Change Model.
Explore the Full Model