For CEOs, COOs, and transformation leaders who want programs to stop drifting by turning decisions into a system, not a conversation.
Transformation slippage rarely comes from “execution.” It comes from decisions that don’t close: unclear ownership, vague thresholds, late risk input, and exceptions that quietly become permanent. The fix is a governance design that makes decisions routable and enforceable. Give every decision a single accountable owner. Define decision rights by category so issues land in the right lane. Pre-agree guardrails so teams can move without waiting. Put timeboxes (SLAs) on decisions and auto-escalate when missed. Require a single decision record so choices don’t get renegotiated. Treat escalation as a normal pathway, separate forums by altitude, and engineer exception handling with expiry and rollback. Finally, measure governance by throughput: cycle time, SLA adherence, escalation volume, and rework.
Table of contents
- The plan didn’t fail, gravity did
- What “transformation slippage” really is
- The 10 governance principles that remove slippage (by design)
- 1) One accountable owner per decision
- 2) Decision rights are explicit by category
- 3) Default to speed with pre-agreed guardrails
- 4) Decisions have an SLA
- 5) Single decision record is mandatory
- 6) Escalation is a pathway, not a punishment
- 7) Right forum, right altitude
- 8) Exception handling is designed, not improvised
- 9) Transparency beats consensus
- 10) Governance measures throughput
- The simple model: Slippage removal as a control system
- When this advice does NOT apply
- What to do this week
- Facts that matter
- FAQ
- Glossary
- Executive Takeaways
- Sugested articles
The plan didn’t fail, gravity did
You’re in a steering session reviewing milestones. The timeline still looks plausible on paper. Yet every week, delivery reports “small dependencies” that keep pushing work to the right.
- Security wants one more review.
- Finance needs more clarity on cost.
- Product changed priorities “slightly.”
- Legal asks what data is involved.
- Vendor says the contract change takes time.
Nobody is trying to block the program.
But the program keeps slipping because decisions are arriving late, half-owned, or not recorded, and teams are compensating by building assumptions.
That is transformation slippage: not one big failure, death by unresolved decisions.
The answer isn’t “more governance.”
It’s governance by design: a set of rules that makes decisions close quickly, consistently, and with consequences.
What “transformation slippage” really is
Transformation slippage is the gap between planned progress and actual progress caused by decision latency and decision ambiguity, not by the ability to build.
Slippage typically shows up as:
- repeated re-planning cycles
- delayed approvals that force rework
- scope changes without a trade-off decision
- “temporary” exceptions that become permanent
- teams waiting for direction or bypassing it
If you want less slippage, you must remove the conditions that create it.
The 10 governance principles that remove slippage (by design)
1) One accountable owner per decision
Principle: Every decision has exactly one named decision owner.
Slippage starts when accountability is diluted. If three leaders “co-own” a decision, it will drift until it becomes urgent, political, or both.
How to implement
- Add a required field: Decision owner in every agenda item and artifact.
- The decision owner can consult widely, but they are accountable for closure.
Decision rule: If no one can name the owner immediately, the item is not ready for a forum.
2) Decision rights are explicit by category
Principle: Stop governing “the transformation” as a single mass. Govern categories of decisions.
Slippage accelerates when everything is treated as equally “important,” which forces everything into the same meeting.
Minimum decision categories
- Strategy and outcomes
- Investment and prioritization
- Product and customer experience
- Platform and architecture
- Risk, compliance, and guardrails
- Execution and delivery
How to implement
- Create a Decision Taxonomy: category → owner → forum → SLA.
- Publish it as a one-page reference, not a slide deck.
Decision rule: If an item doesn’t map to a category, you’re debating a topic—not making a decision.
3) Default to speed with pre-agreed guardrails
Principle: Teams move by default inside guardrails; escalation happens only when thresholds are crossed.
Without guardrails, teams either freeze (waiting for approval) or improvise (shipping risks). Both create slippage—one by delay, the other by rework.
What guardrails look like
- thresholds (cost, risk, customer impact)
- required inputs (security, legal, privacy, data)
- explicit “no-go” constraints (non-negotiables)
How to implement
- Write guardrails as “If X, then Y” statements.
- Put guardrails in the decision template so they are used at the moment of choice.
Decision rule: Guardrails must be measurable. If you can’t measure them, people will argue them.
4) Decisions have an SLA
Principle: Every decision category has a timebox. SLA breaches trigger escalation automatically.
Slippage loves open loops. The longer a decision stays open, the more assumptions accumulate behind it.
How to implement
- Assign SLAs by category (not one SLA for all decisions).
- Include the SLA due date in the decision record and in the forum agenda.
Decision rule: If the SLA is missed, escalation occurs without debate.
5) Single decision record is mandatory
Principle: A decision is not real until it is captured in one standard record.
Most slippage is “decision amnesia.” Teams leave a meeting believing a decision was made, then discover later that stakeholders interpret it differently, or deny it entirely.
Decision record (one page)
- context + why now
- options considered
- recommendation + rationale
- risks / mitigations
- owner + approvers
- date + SLA
- follow-ups (owner + due date)
- dissent (if any)
Decision rule: No record = the program treats it as unresolved.
6) Escalation is a pathway, not a punishment
Principle: Escalation is designed into the system and triggered by objective rules.
When escalation is emotional (“you escalated me!”), teams hide problems until they become incidents. Incidents create slippage at the worst possible time.
Objective escalation triggers
- guardrail threshold exceeded
- cross-functional conflict
- ambiguity that blocks execution
- SLA breach
- enterprise impact (shared platform / customer promise / compliance exposure)
Decision rule: Escalation is a routing event, not a performance review.
7) Right forum, right altitude
Principle: Keep decisions in the right forum at the right altitude.
Slippage is often a forum design problem: executives reviewing operational details, while strategic trade-offs never get resolved.
Forum design
- Operational forum: delivery choices, sequencing within agreed scope
- Steering forum: trade-offs, priority conflicts, scope shifts
- Executive forum: enterprise risk, major investment changes
Decision rule: If a forum regularly debates topics outside its altitude, it is a slippage factory.
8) Exception handling is designed, not improvised
Principle: Exceptions are time-bound, documented, and reversible.
Exceptions are sometimes the right call. But unmanaged exceptions create two forms of slippage:
- they erode standards gradually
- they create hidden rework later when reality catches up
Exception record
- reason for exception
- expiry date
- rollback plan
- owner
- required mitigations
- next review date
Decision rule: If there is no rollback plan, it isn’t an exception, it’s a new standard being introduced informally.
9) Transparency beats consensus
Principle: Optimize for clear decisions, not universal agreement.
Consensus is often a disguised attempt to avoid downside ownership. Slippage increases when decisions are delayed until “everyone is comfortable.”
How to implement
- Allow dissent, but require it to be logged with risks and alternatives.
- Close under the accountable owner unless a guardrail triggers escalation.
Decision rule: Disagreement is data. It must be captured, not used as a brake.
10) Governance measures throughput
Principle: Governance is evaluated by flow, not ceremony.
If you don’t measure it, governance will drift into status updates and vague alignment. Slippage will return—quietly.
Core throughput metrics
- decision cycle time (by category)
- SLA adherence rate
- number of escalations (by trigger)
- rework caused by late decisions (tracked as a reason code)
Decision rule: If metrics don’t improve, redesign the governance mechanism like any broken process.
The simple model: Slippage removal as a control system
Use this as a mental checklist:
- Route decisions by category
- Assign a single accountable owner
- Bound autonomy with guardrails
- Timebox with SLAs
- Record decisions once, consistently
- Escalate through objective triggers
- Separate forums by altitude
- Contain exceptions with expiry and rollback
- Log dissent, don’t chase unanimity
- Measure throughput and redesign when flow stalls
This is “by design”: slippage is not fought case by case; it is prevented structurally.
When this advice does NOT apply
- Small, single-team efforts with minimal cross-functional impact
- Early discovery work where decisions are reversible and low-risk
- True emergencies where immediate action is required (capture the decision record afterward)
- Legally constrained approvals where timeboxes are set externally (still define owners, routing, and records)
What to do this week
- Draft a one-page Decision Taxonomy with 6–8 categories and one owner each.
- Define three guardrails that cover 80% of your current escalations.
- Set SLAs for the top three decision categories causing delay.
- Launch the one-page decision record and enforce it in every forum.
- Create an Exception Register with expiry + rollback and review it in steering cadence.
If you do only this, you’ll reduce slippage without “adding governance.” You’ll be removing ambiguity.
Facts that matter
- Clear decision roles (including a single “decider” role) are presented as a driver of decision effectiveness and speed in decision-rights frameworks. (Harvard Business Review, Jan 2006.)
- RAPID is a widely referenced approach designed to clarify roles in decision-making and improve execution. (Bain & Company, RAPID overview page; publication date varies by page version.) https://www.bain.com/insights/rapid-decision-making/
- RACI guidance commonly recommends a single “Accountable” party for clarity and to avoid confusion in ownership. (Atlassian RACI resources)
- SLAs are defined as agreements that specify expected performance/service levels and expectations; organizations often adapt similar constructs internally for responsiveness. (IBM Think)
FAQ
What creates transformation slippage most often?
Unclosed decisions: unclear owners, missing thresholds, late risk input, and informal exceptions. Teams either wait (delay) or proceed on assumptions (rework). Slippage is the compound interest of decisions that don’t close cleanly.
How many decision categories should we start with?
Six to eight is usually enough. You want categories broad enough to cover reality but specific enough to route decisions without debate. Start with funding, scope/priority, architecture, risk exceptions, vendor, and change/adoption—then refine.
Won’t decision SLAs create rushed decisions?
Only if you skip guardrails and required inputs. SLAs don’t mean “decide blindly.” They mean “decide within a timebox using pre-defined criteria.” The alternative is often worse: slow decisions followed by rushed execution and surprise escalation.
How do we stop exceptions from becoming the new normal?
Treat exceptions as engineered debt: expiry date, rollback plan, and regular review. If exceptions aren’t reviewed, they silently rewrite your standards and your risk posture, then slippage arrives later as cleanup work.
What should executives see vs what should stay in steering?
Executives should see enterprise risk shifts, major investment changes, and decisions that change customer promises. Steering should handle cross-functional trade-offs and priority conflicts. Operational forums handle delivery-level choices. Mixing these altitudes is a reliable way to create slippage.
Glossary
- Transformation slippage: Drift in timelines and outcomes caused by unresolved or late decisions.
- Decision taxonomy: A categorized map of decision types used to route ownership, forum, and SLA.
- Guardrails: Thresholds and required inputs that define autonomous decisions vs escalation.
- Decision SLA: The timebox for making a decision in a category, with automatic escalation on breach.
- Exception register: A controlled log of deviations with expiry dates and rollback plans.
Executive Takeaways
- Slippage is usually a decision system failure, not an execution failure.
- Categories + one owner per decision prevent drift and re-litigation.
- Guardrails and SLAs create speed without improvisation.
- Decision records and designed escalation make governance enforceable.
- Measure throughput—or governance becomes theater again.
Sugested articles
Michel Paquin is a Strategy and Management Senior Lead Consultant at Valtech, based in Montreal. He helps executive teams increase decision velocity by fixing the system around decision-making: governance, operating model, and the translation layer between strategy and delivery. He writes about business decision flows, transformation, and what actually makes change stick.
* Please note that I am unable to accept mandates outside of my engagement with Valtech.
Leave a Reply