Results from comparable organisations

A large enterprise banking organisation was running multiple delivery teams across risk, compliance, and legal domains. End-to-end flow time, the time from a piece of work being started to being delivered, was running at approximately 33 days.

Leadership knew the number was too high. What they did not know was where, specifically, the time was going. The organisation had invested in delivery tooling and had experienced delivery practitioners in place. The problem was structural, not personal.

Three compounding issues were identified. A consistent handoff failure point between the risk and compliance delivery streams, work completing one stage then sitting for 3–5 days before the next team picked it up, untracked and invisible on any dashboard. A dependency structure with no formal tracking mechanism. And a governance approval step creating a consistent 4–5 day delay on every work item regardless of priority or risk level, a process that had made sense at smaller scale but had become a bottleneck as the organisation grew.

None of these three issues were unknown individually. What the diagnostic established was their combined impact on flow time and the order in which to address them.

Flow metrics were introduced and tracked weekly, cycle time, throughput, work-in-progress, and time-in-queue by stage. The handoff failure point was addressed through a structured operating rhythm change, not a technology change. Dependency tracking was formalised with clear ownership and a simple escalation path. The governance process was redesigned with a tiered approval framework, high-risk items retained the existing review, lower-risk items were fast-tracked.

An enterprise delivery environment with more than 20 teams working across multiple domains was experiencing severe coordination overhead. At the time of the diagnostic, 56% of all in-progress work had at least one active dependency on another team.

The practical consequence: more than half of the organisation's delivery capacity was, at any given moment, waiting. Teams were working, but the work couldn't progress until another team delivered something first. Because dependencies were tracked informally, if at all, nobody had a clear picture of how bad the problem was until the diagnostic quantified it.

Dependencies were managed through a combination of email threads, Slack messages, and verbal commitments in weekly meetings. Three categories of failure emerged: unrecorded dependencies where work had implicit reliance on other teams that nobody had formally captured; unescalated blockers where items sat blocked for days with no formal path to resolution; and structural over-dependency where several teams had been designed in a way that created inherent reliance on a small number of shared platform teams, every team needed something from the same two teams, creating a permanent bottleneck regardless of planning quality.

A structured dependency management practice was introduced, not a new tool, but a defined process for recording, tracking, and escalating dependencies within the existing tooling. A lightweight weekly dependency review surfaced blockers proactively rather than reactively. The structural over-dependency on shared services was addressed through a medium-term architectural change, teams were gradually given ownership of the capabilities they previously depended on.

The organisation was running quarterly delivery cycles across multiple teams. Delivery predictability, the percentage of committed work actually delivered by the committed date, was running at approximately 54%. On any given quarter, roughly half of what had been committed to was not delivered on time. The business had adapted by building in buffers and under-committing to stakeholders. But the structural cause of the unpredictability had never been formally diagnosed.

Three contributing factors emerged: inconsistent delivery practices across teams, where some had structured planning and review cycles while others were operating on instinct and tribal knowledge; leadership and team capability gaps, where delivery leads had not been equipped with tools to identify and address delivery risks early enough to course-correct before commitment deadlines; and the absence of inspect-and-adapt mechanisms, there was no structured process for reviewing what had caused missed commitments. The same root causes were repeating quarter on quarter because they had never been formally surfaced.

Structured retrospective and review processes were introduced that surfaced the root causes of missed commitments and produced specific, actionable changes. Leadership capability was uplifted through coaching and practical frameworks, delivery leads were equipped with tools to identify risks earlier and escalate through clearer paths. Delivery discipline was improved through consistent practice standards across teams, not a uniform methodology, but a shared baseline of planning, tracking, and communication.

A technology delivery team was running CI/CD build times of approximately 18 minutes. An 18-minute build time means a developer who pushes a change and discovers a problem waits nearly 20 minutes for feedback, fixes the issue, waits another 20 minutes, and so on. The cumulative impact on developer throughput, focus, and morale was substantial, engineers were context-switching while waiting for builds to complete, creating additional overhead beyond the raw time lost. Because the problem had normalised over time, the team had adapted around it rather than addressing it.

The build pipeline had accumulated inefficiency over multiple years of incremental growth without periodic review. Three specific problems were identified: redundant test execution where the full test suite ran on every build including slow integration tests only relevant to a subset of changes; unoptimised dependency resolution where installation was running from scratch on every build rather than leveraging caching; and sequential stage execution where stages that could run in parallel were running sequentially due to historical configuration choices that had never been revisited.

The CI/CD pipeline was optimised across three dimensions: test stratification (fast unit tests first, slower integration tests on a separate cadence), dependency caching implemented correctly across the pipeline, and parallel execution configured for stages that did not require sequential ordering. AI-enabled workflow automation was also introduced, specifically around backlog management, documentation, and status reporting, contributing to the broader efficiency improvement.

A large financial services organisation had a governance environment in which most decisions requiring more than one stakeholder were taking up to two weeks to resolve, including decisions that, in terms of risk and impact, should have been resolvable within hours. Teams were frequently blocked waiting. Programmes were building in extended buffers. And because the delays were framed as "governance" rather than "bottlenecks," there was significant reluctance to address them, any change to the governance process was perceived as a risk trade-off.

Three structural causes were identified: unclear decision authority, where many decisions were escalated unnecessarily because the boundary between who could decide and who needed to approve was ambiguous, people were escalating to be safe, not because the escalation was genuinely required; no escalation paths for blocked decisions, where the default when a decision sat unresolved was simply to wait for the next scheduled governance meeting; and governance design not proportionate to risk, where the same approval process was applied to decisions of vastly different risk levels creating a permanent queue.

A decision ownership framework was implemented, clear, documented authority for different decision types with explicit guidance on when escalation was required versus optional. An escalation model was created: when a decision had been pending for more than 48 hours, a defined escalation path was triggered automatically, removing the social friction from escalation and making it a structural process rather than a personal judgment call. A tiered governance process was introduced, decisions categorised by risk and impact, with streamlined approval paths for lower-risk items.

A large-scale enterprise transformation programme at one of the world's largest asset managers was running behind its committed timeline. The strategic intent was clear. The execution layer was not delivering at the pace required. The gap between strategy and execution had become invisible until it was already expensive, individual teams were working, work was progressing, but the aggregate delivery was not moving at the speed the programme plan required.

Two primary causes emerged: misalignment between strategic priorities and team-level execution, where the translation of objectives into delivery priorities was inconsistent, different teams were optimising for different things, creating conflicting dependencies and wasted effort; and coordination structures not fit for the scale of the programme, where operating rhythms and governance were creating overhead without producing the alignment they were intended to achieve. Meetings were happening; alignment was not.

A scalable Ways of Working framework was designed and implemented, aligned to business priorities at the programme level and practical at the team level. This created a shared operating language and a consistent planning and review cadence that worked across teams of different sizes and disciplines. Cross-team coordination was redesigned, the governance structures were simplified, the right forums were retained, and the ones consuming time without producing alignment were replaced with lighter-weight alternatives.

A digital investment platform had strong capability on both the product side and the delivery side. Both functions were performing well in isolation. But customer outcomes, measured through NPS and satisfaction data, were not reflecting the quality of the individual functions. The diagnosis was structural: product and delivery were not sufficiently aligned in their priorities, their cadences, or their definition of what success looked like for the customer. Each function was optimising for its own metrics. The customer experience was the gap between the two.

Three misalignments were identified: priority divergence where the product roadmap and delivery backlog were not consistently aligned; cadence mismatch where product and delivery operated on different planning rhythms, creating a lag between product decisions and delivery execution; and success metric divergence where delivery was measured primarily on output, velocity, throughput, rather than customer outcomes. The connection between delivery performance and customer experience was not formally tracked or discussed.

Alignment between product and delivery was improved through a shared planning cadence and a unified definition of success rooted in customer outcomes rather than internal metrics. The highest-priority customer-facing items were given clear delivery ownership and made visible to both functions throughout the cycle. Both functions began tracking NPS alongside their internal metrics and discussing the relationship between delivery performance and customer satisfaction.

Enterprise delivery teams were spending a significant proportion of their capacity on work that was technically necessary but operationally low-value: backlog creation and grooming, manual documentation, status reporting, and repetitive administrative overhead. The estimate from the diagnostic was that 30–40% of total delivery capacity was consumed by this category of work. It was not visible on any dashboard, it simply showed up as "slower than it should be" and had normalised over time to the point where it was no longer questioned.

The AI readiness audit identified four high-value automation opportunities: backlog and story generation, where requirements documents were being manually converted into user stories consuming 3–5 hours per team per sprint; status reporting, where delivery status was compiled manually each week producing reports days stale by the time they reached decision-makers; documentation maintenance, where technical documentation was consistently out of date because updating it competed with delivery for priority; and meeting summarisation and action tracking, where significant time was spent after each meeting transcribing notes and distributing actions.

AI-enabled delivery tooling was introduced systematically across the delivery workflow, not as a collection of individual tools, but as an integrated set of automations connected to the existing delivery stack. Backlog generation was automated using AI agents integrated into Jira. Automated reporting replaced manual weekly compilation with real-time dashboards. Documentation maintenance was addressed through an AI agent connected to the code repository. Meeting summarisation was automated using tooling integrated into the team's communication platform. The implementation was preceded by a diagnostic to confirm which automations would have the highest return.