The Ocean Liner Problem in Transformation Governance

Estimated reading time: 10 minutes

For CEOs, COOs, CIOs, and transformation leaders who need to protect the business without letting important change die in the normal approval flow.

Regular business decision flow exists for a reason. It protects margin, compliance, service continuity, and risk exposure. Like an ocean liner, a large organization should not turn sharply every time someone sees a new wave. The problem starts when transformation work is forced through that same lane. Transformation decisions are more cross-functional, more time-sensitive, and more perishable. When they wait too long, teams reopen design choices, dependencies stack up, and implementation slows even when delivery teams are ready. This is why many transformations need a distinct decision flow with different SLAs, named owners, and clearer escalation rules. Not less governance. Better-fit governance. Keep the standard flow for business-as-usual protection. Create a transformation lane for decisions that shape change before delay becomes rework.

“Business-as-usual governance protects the present.
Transformation governance must also protect the future.“

Michel Paquin

---

I have seen this movie too many times.

A steering committee is on the calendar. The implementation partner is ready. The product team is blocked. Architecture needs an answer. Operations wants clarity. Finance has a concern. Legal has a question. Everyone agrees the transformation is important. Everyone also agrees no one can decide today.

So the issue waits.

A week later, the backlog moves around the missing decision. Two weeks later, the team creates a workaround. Three weeks later, the workaround creates a new dependency. Then someone says the project is slipping because delivery is complex.

Sometimes it is.

But often the real problem is different. The work is not blocked by execution capacity. It is blocked by governance that was designed for running the business, not changing it.

Why the regular flow is good

Regular business decision flow is the normal path an organization uses to make operational and commercial decisions while protecting performance and reducing exposure.

This flow is not stupid. It is not bureaucracy for the sake of bureaucracy. It is what allows a large company to stay stable.

That is where the ocean liner metaphor matters.

An ocean liner does not turn like a speedboat. It should not. It carries weight. It has passengers. It has fuel, route discipline, safety obligations, and consequences if it overreacts. A big company works the same way. It needs checks, sequencing, approvals, and caution.

In business-as-usual operations, that is often exactly right.

If you are changing payment terms, touching credit policy, altering inventory logic, shifting pricing, or introducing legal exposure, slower review can be healthy. Large organizations need mechanisms that protect margin, service continuity, and risk posture. Decision quality matters, and research from Bain found a clear correlation between decision effectiveness and business performance.

So the argument here is not that regular governance is bad.

It is that it was built for a different sea.

Why transformation is a different sea

Transformation decision flow is the decision process used for choices that shape change across systems, teams, roles, and operating model assumptions.

These decisions are different from normal operational choices in four ways.

1. They are more cross-functional

A transformation decision rarely belongs to one silo. A single choice can affect customer experience, operations, finance, technology, support, and reporting at the same time.

2. They expire faster

A business decision can often wait for the next monthly review. A transformation decision may be attached to sprint planning, integration sequencing, data mapping, testing windows, or vendor configuration. If it waits too long, the cost is not only delay. It is rework.

3. They create downstream design consequences

A transformation choice is not just an isolated answer. It changes what gets built, how teams prepare, what gets tested, and how adoption happens later.

4. They carry ambiguity by default

Transformation does not happen in a world of full certainty. Leaders often need to decide with partial information, explicit guardrails, and a tolerance for managed risk.

That last point matters. PMI’s 2025 Pulse of the Profession says today’s environment is characterized by rapid transformation and abrupt shifts, and that stronger business acumen helps professionals handle value, stakeholder needs, and ongoing change more effectively.

In other words, transformation is not only delivery. It is organizational navigation.

Why the regular flow does not fit transformation

This is where many organizations get trapped.

The regular flow is optimized for control. The transformation flow needs control and decision velocity.

Those are not the same thing.

A business-as-usual approval path often assumes:

• decision types are familiar
• meetings can happen on normal cadence
• more review reduces risk
• the decision can wait without major structural cost

Transformation breaks all four assumptions.

A delayed transformation decision does not sit still. It creates movement elsewhere. Teams keep working around it. Dependencies harden. Temporary choices become hidden architecture. Leaders think they are reducing risk, but they are often relocating it.

That is why normal governance can quietly become transformation drag.

I have seen agencies and implementation teams move faster than the client’s decision system can absorb. The delivery side is ready to progress, but the organization cannot close choices quickly enough. The result is not lack of effort. It is a mismatch between the speed of execution and the speed of decision closure.

McKinsey’s latest research argues that organizational health remains a strong predictor of long-term value creation and competitive advantage. One practical reading of that for transformation leaders is simple: if your organization cannot make and absorb decisions effectively during change, the delivery plan alone will not save you.

The real governance problem

The problem is usually not “too much governance.”

The problem is wrong-fit governance.

Most organizations apply one default governance model to two very different jobs:

1. protecting the current business
2. building the future business

Those jobs need different rhythms.

The first rewards caution, consistency, and broad review.

The second needs bounded speed, shorter SLAs, named owners, and tighter escalation rules.

If you force transformation through the same lane as routine operational oversight, you create a structural queue. And once the queue forms, teams compensate with side conversations, pre-meetings, shadow decisions, and workaround design.

That is when governance stops being a control system and becomes a latency system.

A simple model: two decision lanes

Here is the practical model I use.

Lane 1: Business-as-usual decision flow

Use this for decisions where operational protection is the priority.

Typical characteristics:

• known decision types
• lower urgency from a build sequence point of view
• high importance for risk, compliance, policy, or margin protection
• existing authority structure works well enough

Lane 2: Transformation decision flow

Use this for decisions that directly affect implementation flow, solution design, sequencing, adoption, or value realization.

Typical characteristics:

• cross-functional dependency
• time sensitivity
• decisions that unblock build, test, process design, or rollout
• ambiguity that can be managed with guardrails

The mistake is not having both.

What a transformation lane should include

A transformation-specific lane does not mean chaos. It means explicit design.

1. Decision SLAs by decision type

A decision SLA is the maximum acceptable time to close a decision once the right input is available.

Not every transformation decision needs the same turnaround. But some absolutely should not wait until the next monthly steering committee.

Example logic:

• delivery blocker: 48 hours
• design tradeoff with cost impact: 5 business days
• operating model decision needing VP alignment: 7 business days

2. Named decision owners

If a decision “belongs to the committee,” it usually belongs to no one.

Every high-frequency transformation decision needs a clearly named owner, even when that owner gathers input from others.

3. Clear guardrails

A guardrail is a boundary that allows faster decisions without asking for permission every time.

Examples:

• cost threshold
• risk threshold
• policy exceptions that require escalation
• customer impact rules
• architecture principles

Guardrails reduce noise. They tell teams what they can decide and what truly needs senior attention.

4. Explicit escalation rules

Escalation should be for exceptions, not for normal uncertainty.

A good escalation rule answers:

• what triggers escalation
• who joins
• what evidence is required
• when the decision must be made

5. Decision log with aging

If you cannot see how long key decisions stay open, you cannot govern transformation properly.

Track:

• open decisions
• owner
• date opened
• SLA target
• status
• reopen count

The reopen count matters more than most leaders think.

If decisions keep reopening without genuinely new information, the issue is usually not analysis quality. It is unclear ownership, weak guardrails, or fear of consequence.

When this advice does not apply

This advice is not universal.

Do not force a faster transformation lane in these cases:

• regulatory or legal decisions that require formal approval steps
• crisis or incident response situations where command-and-control is necessary
• very small changes with low dependency and low organizational impact
• environments where the real problem is poor strategic direction, not decision flow

Sometimes the right answer is not faster governance.

Sometimes the right answer is fewer moving parts.

Facts that matter

• Bain says its 10-year research program involving more than 1,000 companies found a clear correlation, at a minimum 95% confidence level, between decision effectiveness and business performance. Source: Bain & Company, “The Five Steps to Better Decisions,” published 2013.
• Prosci says projects with effective change management met or exceeded objectives 93% of the time, versus 15% for projects with poor change management. Source: Prosci, “12 Change Management Principles and Best Practices,” published October 1, 2024, updated May 22, 2025.
• Prosci also says organizations with effective change management are seven times more likely to achieve their goals. Source: Prosci, “Change Management Success,” April 9, 2026.
• PMI’s 2025 Pulse of the Profession reports that professionals with high business acumen outperform peers on meeting business goals, schedule adherence, and budget adherence, while reporting lower project failure. Source: PMI, “Pulse of the Profession 2025,” published March 25, 2025.
• McKinsey says organizational health remains a strong predictor of long-term value creation and sustainable competitive advantage. Source: McKinsey, “Organizational health is (still) the key to long-term performance,” published February 12, 2024.

What to do this week

If you are leading a transformation right now, do five things this week:

1. List the top 10 decisions currently slowing delivery.
2. Separate them into business-as-usual decisions and transformation decisions.
3. Assign an SLA to each transformation decision type.
4. Name a real owner for each open decision.
5. Review how many decisions were reopened in the last 30 days and why.

You do not need more meetings first.

You need a better-fit decision system.

FAQ

Isn’t this just a fancy way of saying “move faster”?

No. It is a way of saying “fit the decision model to the type of work.” Business-as-usual decisions and transformation decisions do not carry the same timing logic, dependency pattern, or design impact. Speed without structure is chaos. But structure without fit becomes delay.

Won’t a separate transformation lane create governance confusion?

It can, if it is vague. That is why the lane needs clear entry criteria, named owners, SLAs, guardrails, and escalation rules. The goal is not to bypass governance. The goal is to stop mixing two different decision environments into one clogged queue.

Who should own the transformation decision flow?

Usually a transformation sponsor, program lead, or senior business leader with enough authority to close tradeoffs quickly. But ownership should be distributed by decision type. One person should not become the bottleneck for every issue.

How do I know if my current governance is the real problem?

Look for signs like repeated reopening of decisions, long waits for answers despite available data, workaround design in delivery teams, and steering committees that review issues without closing them. If those patterns are present, the issue is likely governance fit, not only execution discipline.

Does every transformation need a special decision lane?

No. Smaller initiatives may work fine inside the standard flow. The stronger the cross-functional dependency, ambiguity, and time sensitivity, the more value you get from a dedicated transformation lane.

Glossary

Business-as-usual decision flow
The normal governance path used to operate and protect the current business.

Transformation decision flow
A decision path designed for change work that is cross-functional, time-sensitive, and structurally linked to delivery progress.

Decision SLA
The maximum expected time to close a decision once required inputs are available.

Guardrail
A predefined boundary that allows faster local decision-making without recurring approval.

Reopen rate
How often previously closed decisions are reopened, often signalling weak ownership or unclear decision criteria.

Executive Takeaways

• Regular governance is often good for protecting the business.
• Transformation fails when it is forced through a decision system built for operational stability.
• The answer is not less governance. It is governance designed for change.
• A transformation lane needs different SLAs, named owners, and explicit guardrails.
• If decisions wait too long, delay turns into rework, workaround design, and value leakage.

Suggestions