Delivering 3-year projects in three months: value streams and flow efficiency

· business-agility, meetup, flow-efficiency

Delivering 3-Year Projects in Three Months: Value Streams, Flow Efficiency, and the Real Bottleneck

Darryl Wright presenting at the Melbourne Business Agility Meetup

At the March 2026 Melbourne Business Agility Meetup, Darryl Wright ran a session with a provocative promise: “Delivering 3-year projects in three months.” Not by cutting 11/12ths of scope, and not by “getting AI to do all the work” — but by addressing the thing most organisations barely measure, and rarely manage: waiting.

This talk was recorded!

Start with the value stream, not the org chart

Value stream mapping exercise

Meetup discussion on value streams

Darryl anchored the talk in a practical definition of a value stream: it begins with a customer (broadly defined — internal, external, regulators, downstream teams), is triggered by a real event, moves through a set of steps, and ends with a value exchange.

The emphasis here matters: value streams must be mapped end-to-end, not as a convenient slice in the middle where “delivery” happens. It’s the difference between optimising a local workflow and improving what the customer actually experiences.

The customer only cares about lead time — and your lead time is mostly waiting

Flow efficiency: work time versus wait time in a value stream slice

Darryl offered a simple way to think about what “healthy” looks like: from the customer’s perspective, the dominant measure is lead time — the time from trigger to outcome.

Then came the core concept for the night: flow efficiency.

Flow efficiency = (time spent doing value-creating work) ÷ (total lead time)

He walked through a deliberately simplified example where one day of actual work took seven weeks end-to-end — yielding a flow efficiency around 2%.

The kicker wasn’t the made-up example. It was the claim that in real organisations, 2% is common, sometimes lower, and rarely above 5% without deliberate design.

This reframes how we think about getting work done:

We ran the numbers — and the room proved the point

Darryl then had the room break into groups and map a real value stream from their own contexts: trigger → steps → outcome, with rough work time and wait time estimates, then total lead time and flow efficiency.

A few examples reported back:

That spread was useful. It showed two things at once:

  1. Most knowledge-work value streams are dominated by waiting.
  2. When an organisation truly competes on speed (pizza, logistics, highly optimised fulfilment), they build a system that collapses waiting — and the efficiency jumps dramatically.

The improvement trap: speeding up work doesn’t fix lead time

This is the sharpest “recalibration” driven by the talk.

Darryl illustrated a familiar pattern: organisations invest heavily in making work steps faster (more output, more utilisation, “developer productivity”), but the lead time barely moves because the lead time is mostly waiting.

He demonstrated that halving work time can barely shift lead time, and can even make flow efficiency look worse if waiting dominates. Halving waiting, however, radically reduces lead time.

His rule of thumb: focus improvement effort in proportion to your flow efficiency. If work is active 2% of the time, then 98% of your improvement attention belongs on waiting.

Real examples: Westpac and Barclays

Westpac and Barclays examples: targeting waiting in the value stream

Two stories made the theory feel concrete.

Westpac small business overdraft The product took 44 days from application to money in account — a mismatch for customers operating on ~30-day payment cycles. Teams were “green” on dashboards, but the value stream had a hidden delay: a 15-day queue before a banker even picked up the application — and that wait time wasn’t counted because the clock “started” later.

A simple intervention (cross-functional, immediate handoff) reduced that step from 15 days to ~2 hours, pulling total lead time down to 29 days — enough to move the product from “unviable” towards “works, now iterate.”

Barclays: the 3-year to 3-month shift Barclays reportedly mapped value streams across the bank over several years, aggressively targeted waiting, and reduced average project completion from 36 months to ~10–12 weeks, without simply shrinking the work into tiny fragments. The described mechanism was consistent: assemble the needed skills and authority, remove the gates, and design for “never have to wait.”

“The business” isn’t over there

One of the more pointed moments was Darryl calling out how language encodes structure. When we talk about “the business” as though it’s separate from “tech,” we normalise the very handoffs and waiting that slow everything down. The alternative he described is aligning people (business, tech, design, compliance, risk) to the flow of value, not to functional silos.

That naturally raised questions about governance and risk compliance (GRC). Darryl’s framing was pragmatic: GRC isn’t “the brakes” in the sense of constraint; it’s the system that enables safe speed and it has to be inside the value stream, not a distant approval board.

So what about AI?

Darryl pushes us to reposition AI.

If AI makes a work step faster, but your value stream is mostly waiting, then the lead time barely changes. The constraint isn’t how quickly people type; it’s how long work sits in queues. Emerging research is already showing that while the core “doing/building” work is accelerated, work is queing up in discovery and elaboration, then in review.

Darryl’s argument is that the highest ROI for AI (especially agentic patterns) is in collapsing waiting: accelerating information flow, clarifying context, reducing back-and-forth, and making the state of work visible without requiring meetings and status chasing.

A practical suggestion was to deliberately split workflow steps into an “AI does” and “human checks/decides” pattern, which aligns neatly with long-standing management ideas about build/check cycles.

Alignment to the Domains of Business Agility

Business Agility domains linked to flow efficiency

Business agility, flow efficiency, and the value stream

The session connects neatly to the Business Agility Institute’s Domains of Business Agility. The most obvious link is to Value-based Delivery, where organizations focus on optimizing end-to-end value streams rather than local team efficiency.

The implications reach further as reducing waiting also improves:

Flow efficiency becomes a practical lens for exploring agility across multiple domains, not just delivery practices.

Take Aways

Three core ideas:

  1. Flow efficiency is a mirror. It reveals the uncomfortable truth about how little time value is actually being created and how much time is organisational delay.
  2. Most “productivity” programs target the wrong thing. If you want better customer outcomes, target the waiting first.
  3. Structure follows value. If we want speed and control, we have to align skills, authority, governance, and information around value streams and not around functions or reporting lines. This is the non-trivial highes reward change.

Darryl closed with a simple set of takeaways: map your value streams end-to-end, optimise the whole, focus on waiting, and use AI to sensibly support that shift.

If you’re leading change in an organisation that is “agile in the middle” but slow end-to-end, this is one of those lenses that can reframe the conversation fast, especially when you can put real numbers on the waiting.

Thanks

← All articles