The O3 Model

What does real project success actually look like and why do so many initiatives deliver “the thing” but fail to deliver value? In this episode of Seven Consulting’s Delivery Playbook, Seven’s Thought Leader, Rob Thomsett explores two core frameworks behind high-value program delivery: the Whole of Life perspective and the O3 Model (Objectives, Outputs, Outcomes).

 Together, they challenge the traditional view that projects end at go-live and explain why successful delivery depends on planning for support and benefits realisation from day one. Rob breaks down the critical difference between outputs and outcomes and why focusing on the “why” fundamentally changes how projects should be designed, governed, and measured.

 Using real‑world examples, including London’s Thames Tideway “Super Sewer”, this conversation shows how clarity of purpose, strong sponsorship, and outcome‑driven thinking can dramatically improve delivery results.

 If you’re responsible for projects, programs, PMOs, or change initiatives, this episode provides practical, immediately applicable insights into delivering outcomes — not just outputs.

Transcript

SPEAKER_01 0:00

Welcome to Seven Consulting's Delivery Playbook, where we share the powerful concepts that make Seven Consulting Australia's best program delivery company. In this session, we are talking with Rob Thompsett, Seven's thought leader.

SPEAKER_00 0:13

Hi Simone. We're really going to drill down into two core frameworks. These are things we use every day to optimise not just delivery, but crucially benefits realization. We'll be looking at the whole of life perspective on projects and that essential clarity framework we call the O3 model.

SPEAKER_01 0:32

O3. Okay, so that's objectives, outputs, and outcomes. And look, these aren't just, you know, academic concepts sitting on a shelf.

SPEAKER_00 0:38

Not at all. They're practical tools. We use them constantly to bring crucial clarity to planning to delivery and maybe most importantly defining how we are going to measure success.

SPEAKER_01 0:50

Making sure success isn't just about hitting a deadline, right? It's about actually realizing those intended benefits down the track.

SPEAKER_00 0:58

Precisely. That's what true success looks like. Projects are all about delivering benefits.

SPEAKER_01 1:03

Okay, so let's start with that first big idea, the whole of life perspective. It feels like a fundamental shift. If you look at most standard project management stuff, the methodologies, the tools, where does nearly all the attention seem to go?

SPEAKER_00 1:16

Yeah, it's almost entirely focused on what we call stage one, the development phase, you know, the build. We've definitely observed that standard approaches are often far too narrowly focused just on the processes a project manager directly controls during that build.

SPEAKER_01 1:34

Right. That's stage one. That's the bit everyone pictures, isn't it? The um analysis, design, coding, testing, system integration, all that complex stuff, plus the change management to get it rolled out.

SPEAKER_00 1:45

Yes, the heavy lifting of creation.

SPEAKER_01 1:48

But the point you're making is when that's done, when the system goes live, the project isn't really over.

SPEAKER_00 1:55

Absolutely not. It's a critical point, of course, but it's not the end. Successfully finishing stage one just means you've successfully produced, well, a thing, a deliverable or in our terms, a set of outputs.

SPEAKER_01 2:08

A thing. Okay.

SPEAKER_00 2:10

For that thing, those outputs to actually deliver value, it has to move into two more stages that are just as critical. We see three distinct interrelated stages in a project's life.

SPEAKER_01 2:22

Okay, so stage one was development. What comes next?

SPEAKER_00 2:25

Stage two is support. This is absolutely vital. The ongoing operation, the maintenance, keeping it running smoothly, performance tuning, fixing defects as they pop up. Too many organizations ignore both the costs, resourcing, and governance required to keep what stage one delivered operating successfully until just before going live with stage one.

SPEAKER_01 2:50

And stage three?

SPEAKER_00 2:52

Stage three is benefits realization. This isn't passive. It's the ongoing active process of measuring and then realizing the stream of benefits that stage one was supposed to enable in the first place.

SPEAKER_01 3:05

So if I'm hearing you right, the project doesn't just, you know, end up in the PMO lessons learned folder after the post-implementation review. It changes state.

SPEAKER_00 3:14

Exactly. It transitions.

SPEAKER_01 3:16

But here's maybe a question a listener might have. I'm thinking skeptically here. If a project manager's budget, their mandate, kind of wraps up when the output is delivered, how can they realistically take on this duty of care for stages two and three? It feels like someone else's problem for them.

SPEAKER_00 3:32

Yeah, that's a really fair challenge. And it's actually why this perspective is so powerful in practice. The duty of care isn't suggesting the PM is fixing support tickets a year later. Of course not.

SPEAKER_01 3:46

Okay.

SPEAKER_00 3:47

It's about accountability, but shifting it earlier, right into the planning phase. It means we as the delivery partner must force that conversation up front. We have to ensure the sponsor, the business owners are fully engaged and crucially prepared for their roles in stage two and stage three long before development even kicks off.

SPEAKER_01 4:21

Well, you've essentially built a very expensive, maybe fragile, paperweight Precisely.

SPEAKER_00 4:27

It might look good on day one, but it delivers no lasting value. That's why we talk about a project having two ends. Two ends? Yes, the first end, that's where most methodologies and project management models stop, is when the project delivers its outputs into production. You know, the go live date, the ribbon cutting.

SPEAKER_01 4:48

The traditional finish line.

SPEAKER_00 4:50

But the second end, which we argue is actually more important, often comes much later. It's when those outputs are being effectively used by the stakeholders by the business to achieve the intended outcome.

SPEAKER_01 5:03

Okay, output versus outcome.

SPEAKER_00 5:05

Yes, and shifting the focus from that first end, delivering the output to the second end. Achieving the outcome, that shift in mindset is absolutely central to how we think about successful delivery here at Seven Consulting.

SPEAKER_01 5:20

That distinction, outputs versus outcomes, it feels like that's where so many projects, well, maybe fall apart a bit. They get laser focused on delivering the thing, the output.

SPEAKER_00 5:30

Instead of enabling the change, the outcome.

SPEAKER_01 5:33

Exactly. And to really hammer this point home, there's an incredible example that just perfectly shows the power of defining the why first. I'm thinking about the Thames Tideway project in London.

SPEAKER_00 5:44

Oh yes, Simone the Supersuer, a massive undertaking. It was an 8 billion 25 kilometre tunnel network, huge infrastructure project.

SPEAKER_01 5:56

Huge, yeah, complex. The kind of thing you expect delays and budget blowouts on. And yet, almost unbelievably, for something that massive.

SPEAKER_00 6:05

Delivered on time and within budget, a rare feat.

SPEAKER_01 6:09

It really is. And the context is important too, isn't it? London's river, the Thames, had serious pollution problems, overflowing sewers. Basically, it wasn't just an environmental issue. It felt like a kind of psychological wound for the city.

SPEAKER_00 6:23

Definitely. And when Andy Mitchell came in as CEO of Thames Tideway, he obviously had a very concrete goal, literally concrete, but he refused to let that technical goal be the project's vision.

SPEAKER_01 6:36

What did he do?

SPEAKER_00 6:37

Well, he saw that the sheer scale, the technical specifications were kind of overwhelming everyone. The early talk was all, as he put it, decibels, cubic meters, and legal language. All outputs necessary but not inspiring. So he reframed the entire purpose of the project. He articulated the real mission as repairing a broken love affair between the people of London and their river.

SPEAKER_01 7:02

Wow, repairing a broken love affair. You definitely don't put that on a Gantt chart.

SPEAKER_00 7:07

No, but it immediately defines the true measure of success, doesn't it? It elevates it beyond just engineering.

SPEAKER_01 7:14

It absolutely does. And that single act, that reframing, it just perfectly illustrates the most critical job a sponsor has in defining that big aspirational why, the ultimate outcome.

SPEAKER_00 7:26

Exactly. It connects the tangible deliverables, the tunnel, the cleaner water to a massive human and societal change. And this leads directly to our core formula, the way we structure this thinking. The formula being The Why, the outcome must drive the what, the outputs, and only then does that drive the how, you know, the specific methods, tools, project management techniques we choose to use.

SPEAKER_01 7:53

So if you don't nail the why first.

SPEAKER_00 7:56

The what will almost always be slightly off-target, maybe significantly off-target, and the how might be completely inefficient.

SPEAKER_01 8:04

Okay. So outcomes aren't deliverables themselves. They're the goals, the strategic objectives, maybe the mission statements. They represent significant observable changes in the future state of an organization, or in the Tideway case, a whole city.

SPEAKER_00 8:18

That's it exactly. Outcomes are things like to be number one in customer satisfaction, or maybe to retain our high net worth clients. They are the end goals. You can't just build customer satisfaction directly. It's the result of your outputs, like a new system or service being used effectively over time.

SPEAKER_01 8:40

Which brings us nicely to the O3 model. Objectives, outputs, and outcomes. This is the framework we use to really embed that clarity, isn't it? It's like a mechanism for defining the why and the what, nailing down the scope and setting the success criteria for, well, pretty much every initiative we're involved in.

SPEAKER_00 8:58

Yes, and the way we use the O3 model is actually by working backward from that desired future state. We ask two really critical questions. And the answer to the first one fundamentally guides the second.

SPEAKER_01 9:12

Yeah.

SPEAKER_00 9:13

Okay, question number one is What specific quantifiable changes do I want to see happening in my organization? Say three to six months after the project ships? That post-implementation realized change, that's your outcome. That's the real goal, the thing that should directly feed into the corporate strategy.

SPEAKER_01 9:32

Got it? And question two?

SPEAKER_00 9:34

Question two is what deliverables or tangible changes must be physically present and observable in my organization the day the project ships the go live day?

SPEAKER_01 9:44

The day it ships, right.

SPEAKER_00 9:46

Those are your outputs. They are the concrete deliverables that the development phase, stage one, is directly responsible for producing.

SPEAKER_01 9:55

Okay, that makes sense. Outputs are the now, outcome is the later, enabled by the now. And when we structure this O3 model, you always insist on two essential links being really clear.

SPEAKER_00 10:06

Absolutely critical. First, there's the strategic alignment, which we sometimes call the vertical link. The project's defined outcome must align clearly and demonstrably with the organization's overall strategic outcomes, its mission or its vision.

SPEAKER_01 10:24

So if it doesn't link up vertically?

SPEAKER_00 10:26

Then you have to seriously question why the project is being done at all. It might not be the right investment.

SPEAKER_01 10:33

Okay, that's the vertical link. What's the second?

SPEAKER_00 10:36

The second is the horizontal link. This is about the integrity within the project definition. It's the necessary logical relationship flowing across from the objectives to the resulting outputs, connecting to the final outcome and crucially mapping the specific benefits tied to each of those components.

SPEAKER_01 10:56

It forces a kind of logical change.

SPEAKER_00 10:58

Exactly. It forces integrity and clarity in your planning, no fuzzy connections allowed.

SPEAKER_01 11:04

Right, so let's nail down those definitions again just to be crystal clear. Objectives are statements of intent. They always start with the word two, like to build X or to implement Y. They state what you plan to do.

SPEAKER_00 11:16

And outputs?

SPEAKER_01 11:18

Outputs are the individual tangible deliverables that result from successfully meeting that objective. And the rule here is quite rigid. One objective must equal one output, a one-to-one relationship.

SPEAKER_00 11:30

One objective, one output, you got it.

SPEAKER_01 11:33

And every single one of those outputs must be directly traceable, directly contributing to achieving the overall defined outcome. Okay? And the outcome, as we said, is that significant change that's enabled once those outputs are actually being used. But you often emphasize finding one primary outcome. Why just one? Couldn't a project have several positive outcomes?

SPEAKER_00 11:56

Oh, it absolutely can and often does. But a project team, especially the project manager, cannot effectively focus on and measure everything. The primary outcome is the single highest value change that truly defines success in the eyes of the sponsor.

SPEAKER_01 12:13

The one that matters most.

SPEAKER_00 12:15

Yes, this becomes the cornerstone for developing robust measurement plans and the whole benefits realization process later on. Those other positive outcomes, they're great. They're like bonus results, secondary outcomes. But the PM's core focus, the project's raison date, must remain fixed on enabling that specific primary outcome.

SPEAKER_01 12:41

Okay, I have to play the skeptic again. Maybe voice a common reaction we get. When we write an objective, let's say to build a new CRM system, then the output new CRM system is live. That can feel a bit redundant, can't it? Like stating the obvious. We often hear clients say the model feels a bit overly meticulous sometimes. Why is this level of specificity mandatory? Why not just say objective, deliver CRM?

SPEAKER_00 13:05

Yeah, look, I get that feedback sometimes that it seems obvious, but making it explicit is mandatory for two really important reasons that directly combat scope creep and frankly fuzzy thinking.

SPEAKER_01 13:18

Reason one?

SPEAKER_00 13:19

Firstly, the outputs themselves often have immediate measurable benefits associated with their delivery. Did the system launch on time? Did it meet the performance specs on day one? Did it handle the expected user load? We need to measure and realize those immediate delivery benefits to ensure stage two, the support phase, is even viable. It checks the quality of the thing we just built.

SPEAKER_01 13:45

Right, so it's a check on the quality and success of stage one itself. Makes sense. What's the second reason for separating them?

SPEAKER_00 13:52

The second reason is all about maintaining that tight accountability back to the primary outcome. By specifically isolating the output CRM system live from the objective to build, we force ourselves to articulate and verify the clear, indisputable link between that specific deliverable and the ultimate primary outcome.

SPEAKER_01 14:14

So if you can't easily draw that line.

SPEAKER_00 14:17

Exactly. If an output, something we're planning to build and spend money on, can't clearly justify its existence in terms of directly helping achieve the primary outcome, then it's probably scope creep. It doesn't belong, it gets challenged, potentially cut, it forces real precision in thinking.

SPEAKER_01 14:36

Okay, that clarity makes sense. Let's maybe run through a couple of quick examples just to show that difference between the delivered output and the enabled outcome. How about a simple personal one?

SPEAKER_00 14:46

Sure. Let's say your objective is to take a holiday.

SPEAKER_01 14:50

Okay. Objective to take a holiday. What's the output?

SPEAKER_00 14:54

The output is you are on holiday. It's the state achieved. You're physically there on the beach. That's the deliverable.

SPEAKER_01 15:01

And the outcome? The why I took the holiday?

SPEAKER_00 15:04

The outcome could be to rebuild personal energy or maybe to reconnect with family. That's the change enabled by being on holiday.

SPEAKER_01 15:13

Right. The output is being there. The outcome is feeling refreshed. Okay, a business example?

SPEAKER_00 15:18

Alright, objective to build a booking web app. Output. Output. Booking web app is live and functioning. Users can access it. The primary outcome might be to grow the customer base by 20% within 12 months, or perhaps to reduce call center volume by 30%. The app being live, output is necessary, but the growth or cost reduction outcome only happens if customers use it effectively.

SPEAKER_01 15:46

Okay, that makes it very clear. And you had one more, slightly funnier example that shows when that alignment breaks down.

SPEAKER_00 15:53

Oh yes, the cautionary tale. Let's imagine a very misguided project objective to look like Brad Pitt. Okay. Output. Output. A BradPitt look-alike is produced, maybe through surgery, makeup, whatever. The output is delivered.

SPEAKER_01 16:09

Uh-huh. And the intended outcome?

SPEAKER_00 16:11

Outcome to sell coffee machines like George Clooney.

SPEAKER_01 16:15

Right. Now obviously that project is absurd, but it perfectly illustrates the point, doesn't it?

SPEAKER_00 16:20

Exactly. The output, the look-alike, might have been delivered perfectly, met all the specs, but it completely failed to enable the desired business outcome because the underlying assumption, the link between that specific output and that outcome was fundamentally flawed.

SPEAKER_01 16:38

And the O3 model, if applied rigorously, would have flagged that faulty logic, that broken horizontal link, right at the very beginning.

SPEAKER_00 16:46

Precisely it forces you to test those assumptions. So just to quickly summarize the definitions again, a well-stated objective contains the planned output implicitly or explicitly. An output is the observable change delivered when the objective is met. And an outcome is the significant observable change enabled by the successful use of those outputs over time.

SPEAKER_01 17:12

It's powerful stuff, and we find, don't we, that the senior execs, the sponsors footing the bill for these projects, they are overwhelmingly positive about the O3 model.

SPEAKER_00 17:22

Absolutely, Simone. They really are because it just cuts through the usual project jargon, enforces that crystal clarity on exactly what they are funding and more importantly why they are funding it. What change are they actually buying?

SPEAKER_01 17:37

So we've covered two really innovative concepts today, both core to how Seven Consulting operates, both designed to shift project delivery away from just being output focused and towards being truly outcome-focused. We talked about the whole of life perspective, demanding we plan properly for stage two support and stage three benefits realization right from the start.

SPEAKER_00 17:59

And the simple yet incredibly powerful O3 model making sure the ultimate why genuinely drives the what and the how.

SPEAKER_01 18:06

We really hope walking through these ideas gives you some valuable insight into making those critical distinctions that drive real high-value project success.

SPEAKER_00 18:16

Absolutely, food for thought, hopefully.

SPEAKER_01 18:18

And look, if these concepts resonate with you, if you're thinking about your own PMO, your program delivery, your change management challenges, we really encourage you to get in touch with us here at Seven Consulting. You can find us easily via our website or on LinkedIn.

SPEAKER_00 18:32

Please do reach out. We are committed to sharing unique, innovative ideas like these, things that maybe go beyond the standard project management textbooks. We're planning to release a new podcast like this every two weeks, so please make sure you subscribe so you don't miss out.

SPEAKER_01 18:50

And our very next conversation is going to tackle a big one Agile versus traditional and the levers to get it right. Should be a good discussion.

SPEAKER_00 18:58

Definitely one to tune in for. We look forward to having you join us again soon.