The programme was not failing because of the software.
The platform was stable. The architecture was sound. The engineering team knew what it was doing. Automated tests were in place. Security controls existed. The product backlog was credible.
Yet delivery had stalled.
A routine change could require 14 separate approvals before it reached production.
Fourteen.
By the time the final sign-off arrived, the business requirement had often changed, the release window had closed, or the team had moved on to another priority.
This is a familiar enterprise problem. Leaders call it a technology delivery issue because the symptoms appear in the technology team. But the root cause is often elsewhere.
The operating model is broken.
The situation: healthy technology inside an unhealthy system
This was an anonymised enterprise software programme involving multiple business, technology, security and operational teams.
The organization had invested heavily in the platform. It had also invested in governance.
Perhaps too heavily.
The delivery process had evolved through years of risk events, audit findings, reorganizations and new stakeholder demands. Every incident had produced another control. Every control had acquired an owner. Every owner had requested a formal approval point.
Eventually, the delivery path looked like this:
- Product owner approval
- Business process owner approval
- Business analyst confirmation
- Development lead approval
- Architecture review
- Data owner approval
- Security review
- Privacy review
- Test manager sign-off
- Operations readiness approval
- Infrastructure approval
- Release manager approval
- Change Advisory Board approval
- Executive or delegated business approval
Each layer had a rational explanation.
The combined process was irrational.
The organization had confused more approvals with more control.
It had created a system where accountability was distributed across 14 checkpoints but ownership of the outcome was unclear.
The problem: approval queues had become the critical path
The engineering team could complete a change in days.
The approval chain could take weeks.
That difference created several predictable effects:
- Release dates became difficult to forecast.
- Engineers bundled small changes into large releases.
- Risk increased because more changes were deployed together.
- Approvers reviewed documentation rather than working software.
- Teams began scheduling around committee calendars.
- Business stakeholders lost confidence in the programme.
- Delivery leaders reported activity instead of progress.
The organization had built a modern software platform and placed it inside an industrial-era decision process.
That is the uncomfortable truth.
Many enterprises are not held back by their technology stack. They are held back by the number of people who must say yes before the technology can create value.
DORA’s research has repeatedly connected delivery performance with capabilities such as continuous delivery, deployment automation, fast feedback and streamlined change approval. Its research archive specifically identifies heavyweight change approval processes as a negative influence on performance.
The lesson is not that governance is unnecessary.
The lesson is that governance must be designed around risk and evidence, not ceremony.
The challenge: simplify without weakening control
The initial response from several stakeholders was predictable:
“We cannot remove approvals. We operate in a regulated environment.”
That was not the real proposal.
The real proposal was to separate three questions that had been mixed together:
- Is the change technically safe?
- Is the change operationally ready?
- Is the change sufficiently important or risky to require a human decision?
The old model treated every change as if it carried the same level of risk.
A minor configuration change followed almost the same path as a major data migration.
That was the first design failure.
The second was that the process had no clear distinction between:
- A control that prevents risk.
- A control that records risk.
- A control that simply repeats an earlier review.
The third was that approvals were often based on manually assembled documents. Evidence existed, but it was scattered across emails, spreadsheets, tickets, test tools and meeting minutes.
Approvers were not making faster decisions because they lacked confidence.
They were making slower decisions because the evidence was difficult to find.
The approach: redesign the operating model before changing the platform
The recovery did not begin with a new tool.
It began with a delivery diagnostic.
We mapped the journey of a change from approved requirement to production deployment. For each step, we recorded:
- Who performed the activity.
- Who approved the activity.
- What evidence was produced.
- How long the change waited.
- Whether the control prevented a measurable risk.
- Whether another control already covered the same risk.
- Whether the step was mandatory for every change or only for specific risk classes.
The results were clear.
Several approval points were duplicates. Some had no defined decision criteria. Others existed because “that is how the process had always worked.” A few were designed for large, infrequent releases but were being applied to small, routine changes.
We then introduced a risk-based approval model.
Low-risk changes
Routine, reversible and well-tested changes could move through automated controls when they met predefined conditions:
- Code review completed.
- Automated tests passed.
- Security and dependency scans passed.
- Required documentation linked to the change.
- Rollback or recovery action available.
- No critical production incident or policy exception open.
These changes did not require 14 human approvals.
They required evidence.
Medium-risk changes
Changes affecting multiple teams, important business processes or shared services required targeted human review.
The key word was targeted.
The product owner, technical owner and operational owner reviewed the change together. They did not each run separate, sequential approval processes.
High-risk changes
Major data migrations, regulatory changes, significant infrastructure changes and releases with material operational impact retained additional governance.
But even here, the model used one consolidated decision point supported by evidence rather than a chain of disconnected sign-offs.
The number of controls was not the primary measure.
The quality, relevance and traceability of the controls were.
The technology: use the existing tools properly
The platform itself did not need to be replaced.
The organization already had the building blocks:
- Version control.
- Pull-request review.
- Automated testing.
- Vulnerability scanning.
- Continuous integration and deployment tooling.
- Service management records.
- Monitoring and alerting.
- Environment controls.
- Audit logs.
The problem was that these tools operated as separate islands.
Governance sat outside the delivery flow. Evidence had to be copied manually from one system to another. Approval decisions were made in meetings instead of within a traceable delivery record.
The redesigned model connected the evidence.
A change record could now show:
- The requirement being addressed.
- The code and pull request.
- Test results.
- Security scan results.
- Infrastructure changes.
- Risk classification.
- Deployment plan.
- Rollback plan.
- Approver identity.
- Deployment outcome.
- Post-release telemetry.
This is what modern platform modernization should achieve. Not simply a newer platform. A more effective relationship between technology, process and accountability.
The execution: governance had to change in practice
A process redesign on paper would have achieved nothing.
The teams needed to work differently.
We introduced the new model in controlled stages:
1. Establish one accountable delivery owner
The programme needed a clear owner for the end-to-end flow.
Not one person responsible for every decision. One person responsible for ensuring that the decision system worked.
That distinction matters.
2. Define approval rights by risk
Each role received a clear decision right.
A security lead did not approve business readiness. A business owner did not approve technical integrity. An architecture board did not re-review a change already governed by approved standards.
The model made these boundaries explicit.
3. Replace serial approvals with concurrent review
Where multiple disciplines genuinely needed to review a change, they reviewed it in parallel.
Waiting for one approval before starting the next was creating artificial delay.
4. Automate evidence collection
The delivery pipeline became the primary source of truth.
Test results, security checks and deployment records were attached automatically. Engineers stopped preparing approval packs manually for routine changes.
5. Introduce exception governance
Not every change required a meeting.
But every exception required a clear reason, owner, expiry date and review path.
This prevented “temporary” workarounds from becoming permanent process.
6. Measure the queue, not just the work
The programme began tracking:
- Time spent waiting for approval.
- Time spent actively developing and testing.
- Number of approvals per change type.
- Deployment frequency.
- Change failure percentage.
- Failed deployment recovery time.
- Number of emergency changes.
- Percentage of changes passing through automated controls.
These metrics exposed the real constraint.
The programme did not have an engineering capacity problem.
It had a decision-flow problem.
The outcome: delivery became a management system, not a committee schedule
The most important outcome was not a new dashboard or a revised policy document.
It was a change in the operating rhythm.
Routine work could move at the speed of the automated controls. Higher-risk work received senior attention where it was actually needed. Approvers saw evidence earlier and in one place. Delivery leaders could identify bottlenecks instead of debating anecdotes.
The programme regained predictability.
Teams stopped batching changes simply to survive the approval process. Smaller releases reduced the size of each deployment decision. Accountability became clearer because each approval had a defined purpose.
The software had not changed.
The path to value had changed.
That is the point many transformation programmes miss. Technology creates potential. Operating models determine whether that potential reaches the business.
The lesson for CIOs and programme directors
If your programme is slow, do not immediately assume the platform is the problem.
Ask better questions:
- How many approvals does a routine change require?
- How much of the release timeline is active work versus waiting?
- Which approvals are based on evidence?
- Which approvals duplicate another control?
- Are high-risk and low-risk changes governed differently?
- Can the delivery team explain who owns the final decision?
- Are your governance meetings making decisions or simply reviewing status?
- Are you measuring delivery performance after each process change?
A PMO that reports delay without measuring approval queues is missing part of the diagnosis.
A steering committee that adds another approval layer without removing an old one is increasing risk, not reducing it.
And a technology leader who responds to an operating-model failure with another platform purchase is treating the symptom.
A practical recommendation
Run a two-week approval-flow review.
Select a representative sample of recent changes. Map every handoff, approval, queue and evidence requirement. Then classify each control:
- Keep and automate.
- Keep and consolidate.
- Retain only for high-risk changes.
- Remove.
- Redesign and measure.
Do not begin by asking, “Who can we remove from the process?”
Ask:
“What risk is this step controlling, and what evidence proves that the risk is controlled?”
That question changes the conversation.
If your technology works but delivery remains stuck, request a transformation review. The objective is not to produce another governance deck. It is to identify where strategy, technology, execution and adoption are breaking apart: and create a practical path to measurable improvement.
Key takeaway
The 14 layers of approval were intended to protect the organization.
In practice, they protected the process from making a decision.
Good governance does not mean more gates. It means the right control, applied to the right risk, supported by the right evidence, with a named person accountable for the outcome.
The software was ready.
The operating model was not.
Frequently Asked Questions
Does reducing approval layers increase delivery risk?
Not when approvals are replaced with stronger automated controls, clear risk classification, traceable evidence and targeted human review. The objective is not less governance. It is more relevant governance.
Should regulated enterprises eliminate Change Advisory Boards?
Not automatically. A CAB may remain useful for high-risk, cross-organization or regulatory changes. The problem is applying the same board process to every routine deployment.
What should be automated first?
Start with evidence collection and repeatable controls: automated testing, security scanning, policy checks, change classification, deployment records and rollback validation. These create faster, more consistent decisions.
How can a PMO identify whether approvals are causing delay?
Measure active work time separately from queue time. Track approval wait time by change type, approver group and environment. Compare the data with deployment frequency, change failure percentage and recovery time.
What is the first step in fixing a delivery operating model?
Map the current change journey end to end. Identify every decision, handoff, evidence requirement and waiting period. Then redesign the model around risk, accountability and business outcomes.
SEO Publishing Details
- SEO title: Software Worked. Why Approval Layers Stalled Delivery
- Meta description: The software was sound, but 14 approval layers stopped delivery. Learn how risk-based governance restored speed, control and accountability.
- Suggested URL slug:
software-delivery-approval-layers-governance-case-study - Focus keyword: software delivery governance
- Related keywords: approval bottlenecks, delivery operating model, risk-based governance, change approval process, programme governance
- Search intent: Informational with commercial investigation
- Image alt text: Enterprise software delivery team reviewing approval bottlenecks in a modern governance control room
- Internal linking suggestions: Services, Platform modernization, Shadow IT and delivery models, Modern delivery governance
- External authoritative source: DORA Research Program
- Recommended schema: Article Schema and FAQ Schema
About the Author
Kunal Patel : CEO & Founder, Dark Consultancy
Kunal Patel founded Dark Consultancy after two decades leading technology and transformation programmes across the public sector, financial services, defence, and energy industries. He has directly managed programme recovery engagements for government agencies, development finance institutions, and regulated enterprises across the US, Middle East, South Asia, and Southeast Asia ; ranging from $5M platform migrations to $200M+ enterprise transformation portfolios. Kunal is a recognised practitioner in delivery governance for regulated environments and holds PMP and PRINCE2 Practitioner certifications. He leads every new client engagement personally and remains accountable throughout the programme lifecycle. Connect with Kunal on LinkedIn