Chapter 6: Deliver (Operationalising Value)

Five months into the Design4 process, Marcus was feeling cautiously optimistic. Lakeshore had a clear purpose. The strategic choices were made and communicated. The capability architecture was designed, with Phase 1 already underway as Tom's team mentored Skilled Trades faculty on employer partnership processes. The labour market intelligence prototype was producing its third monthly "Labour Market Pulse" report, and program leaders were starting to ask for it before it arrived.

Then Aisha, the Student Association President, said something that stopped him cold.

Marcus had invited her to review the capability development plan, wanting student perspective on the career navigation redesign. She listened carefully, nodded at the right places, and then said: "This is impressive. You've mapped what Lakeshore needs to be good at. You've figured out what's missing. You've got a plan to build it. But I have a question: have you asked students what the experience of being at Lakeshore should actually feel like?"

Marcus paused. "We've mapped the student value stream. We know the stages."

"You've mapped what the institution does to students," Aisha said. "The stages of your process. I'm asking about the experience from our side. What does it feel like to be a student here? Because right now, it feels like being processed. You apply to one department. You get financial aid from another. You register through a system that doesn't talk to either of them. You get assigned an advisor who changes every semester. You take courses from faculty who don't know what the career services office is doing, and career services doesn't know what your program is doing. Nobody is rude. Nobody is incompetent. But nobody is connected, either. You're a file moving through systems, not a person on a journey."

She paused. "You've redesigned the engine. Have you redesigned the experience of being a passenger?"

Marcus looked at Diane, who was sitting in on the session. She raised an eyebrow. "She's right, you know."

That evening, Marcus wrote a note to himself: "We built the capability architecture from the inside out. We mapped what we need to be great at. But we never designed the delivery from the stakeholder's perspective. We never asked them what 'done well' should look like."

He had just encountered the gap between Develop and Deliver. Having the right capabilities and delivering the right experience are two different things. And Deliver is where that difference becomes visible.

Aisha's distinction is worth keeping straight. A value stream, as Chapter 5 used it, shows the stages of value the institution creates and the capabilities each stage needs. A customer journey shows the same stages as the student lives them, moment by moment. And a Lean value stream map, a different tool despite the name, times the process steps. Develop works from the first. Deliver designs from the second.

In physics, potential energy is stored energy: a boulder sitting at the top of a hill. Kinetic energy is energy in motion: the boulder rolling. The Develop phase built your organisation's potential energy: capabilities designed, value streams mapped, gaps identified, development plans in place. The Deliver phase is where that potential becomes kinetic, where capabilities turn into actual value in the lives of actual stakeholders.

This distinction matters because organisations frequently confuse having capabilities with stakeholders actually being better off. They invest in technology platforms, redesign processes, train teams, and build organisational structures (all the work of Develop) and then assume that stakeholders will benefit. It doesn't. Capabilities are necessary but not sufficient. The question isn't "Do we have the capability?" It's "Is the stakeholder actually better off?"

The Deliver phase's governance question makes this concrete: Are we getting them done well? Not Are we doing the right things? (Define) or Are we doing them the right way? (Develop). Deliver asks whether the operations, the day-to-day systems through which the organisation touches stakeholders, are reliably producing what those stakeholders need. What Deliver produces are results: its services' outputs, counted where they meet the stakeholder and read for how well they were produced. Whether stakeholders end up better off is a question for the end of this chapter.

This requires a mindset shift that many organisations find uncomfortable. Peter Drucker captured it precisely: "Efficiency is doing things right; effectiveness is doing the right things." Most operational management is about efficiency: reducing cost, increasing speed, improving throughput. These matter. But they're secondary to effectiveness, ensuring that what the organisation does efficiently is actually what stakeholders need. An operation that processes applications in record time is impressive. An operation that processes applications in record time but leaves applicants confused about their status, uncertain about next steps, and unable to reach a human when something goes wrong is efficiently failing.

Deliver insists that operations be effective first (producing outputs that actually leave stakeholders better off) and efficient second. This is the outside-in perspective that runs through the entire Design4 framework, and it reaches its most practical expression in this phase.