Most IT Governance Programs Slow Delivery. The Good Ones Speed It Up.

For most of my career — 30+ years of program governance across financial services, telecom, retail, and the last decade-plus at Convergent — I've watched the same dynamic play out. A retirement firm institutes a governance framework after an audit finding or a production incident. The framework works for a year. Then it ossifies. Approvals start to take longer than the work they're approving. Risk reviews become CYA exercises. Eventually a senior leader looks at the queue and asks why a portal copy change took six weeks to ship.

The instinct from the team is to argue that governance is the problem. It usually isn't. The problem is that the governance program was designed to control risk and was never tuned for velocity. Once you accept that controls and speed have to coexist, the work becomes manageable.

What governance is actually for

The right framing for governance in a retirement environment isn't "preventing bad changes." It's "making the change record defensible to a regulator, an auditor, and the next team that has to operate the system." Those are different problems with different solutions.

Defensibility doesn't require slowness. It requires:

• A documented decision trail
• An assignable owner at each step
• A repeatable approval criterion
• A traceable link from intent → change → outcome

A governance program that delivers those four things in 48 hours is just as defensible as one that takes six weeks. The difference is how the workflow is structured, not how strict the rules are.

Where the time actually goes

In every governance audit I've run, the time cost breaks down predictably:

Approver queue depth. Reviews sit in inboxes for days because the approvers have other work and no SLA. This is the single biggest contributor to cycle time and the easiest to fix.

Repeated context-setting. Each approver has to re-read the change from scratch. The submitter spends more time explaining the change than building it. A standardized one-page change summary with clear risk classification eliminates most of this.

Decisions that aren't really decisions. Many "approvals" are rubber-stamps that nobody is empowered to deny. They exist because someone in 2019 said they should. Removing them entirely is usually safe; replacing them with a notification is almost always safe.

Risk reviews that don't differentiate. A copy change on a participant statement and a batch processing modification both go through the same risk review template. The template is calibrated for the batch change, which means the copy change has to answer questions that don't apply. Tier the reviews. Most changes are low risk and should be processed accordingly.

Documentation that gets recreated for each step. Same information, restructured for each approver. Build it once, in a structured form, and route it. Nobody should be retyping their change description three times.

The five moves that consistently speed things up

When we go into a governance environment that's slowing delivery, these are the changes we look for first.

Risk-tier the change pipeline. Three tiers usually works: routine (low risk, repeatable, light review), standard (moderate risk, normal review), and major (high risk, full review with formal approval). The ratio in healthy retirement environments is roughly 80 / 15 / 5. If the actual ratio is closer to 30 / 50 / 20, the framework is over-classifying and slowing everything down.

Pre-approve patterns, not just changes. Many changes are instances of patterns the firm has already approved. Pre-approving the pattern means new changes that match it can ship with a notification rather than a full review. Configuration changes within an approved template are the most common example.

Set hard SLAs on every queue. Approvers get the change within their queue for X hours. After X+Y hours, it escalates. After X+2Y, it auto-approves at the next tier down (with notification). Most queues compress dramatically when this is in place because the work no longer disappears into inboxes.

Move the security and compliance reviews to the design phase. Don't review at the gate. Review at the start. By the time the change is built, the design has already been validated and the gate review is a confirmation, not an inquisition. This single change typically takes weeks off cycle time on regulated changes.

Build evidence as a byproduct, not a workflow. The audit evidence the governance program needs should be generated automatically by the workflow tools — tickets, code reviews, deployment logs — not assembled retroactively by humans. If the evidence is being created after the fact, it's both slower and less defensible.

What "good" looks like

A well-tuned governance environment in retirement operations has these properties:

• Routine changes ship in days, not weeks
• Major changes still get the full treatment, and that treatment is faster than it used to be
• Approvers actually approve (they're empowered) or formally escalate (they have a path)
• Auditors can reconstruct any change in minutes from existing tooling
• The team that ships the work isn't spending more time on documentation than on the work itself

Getting there from a slow governance environment is a 90-180 day program in most organizations. It requires CTO/COO sponsorship, because some approvers will lose the ability to gate-keep. It also requires honest measurement — the time-in-queue numbers usually surprise the people who built the framework.

What we tell clients in the first meeting

If governance is genuinely slowing down delivery in your environment, the path forward is not to fight it. Bypassing controls produces audit findings and incidents. Fighting controls produces internal warfare and bad blood. Tuning controls produces faster delivery and a defensible record.

The governance is staying. The question is whether it's a productivity tax or a productivity asset. The good ones are an asset. Getting there is engineering, not politics.