Nobody Owns the Outcome

You're nine months into a multi-year financial transformation, and the budget is under pressure. Nobody has told you the results are bad. But people expected to see something by now, and nobody has said what.

Then the question comes. It might be in a budget review, or a hallway, or the last five minutes of a steering committee: what is your team actually doing, and how does it contribute to value?

You can explain how the work is going. What you can't do is point to the number it was supposed to move. That number was set before you arrived, in conversations you weren't part of, and you're being measured against it anyway.

You're graded on a number you never saw

Somewhere before your team existed, a business leader made the case for this transformation. There was usually a real cost-benefit analysis behind it, often built on what the software vendor projected, which doesn't always rest on specifics about your organization. Then the money was approved and a team was put together to carry it out.

So you received the number. You weren't a party to it. You can question how the work gets done, and your tactics are fair game. Whether the strategy makes sense is a conversation you're rarely invited into.

That's why the question shows up the way it does. If you're in-house, you're asked why you need these resources, or why you need more, or what the people you have are doing. If you're a consulting firm, you may be asked whether the budget needs to be there at all.

What the business case leaves out

I don't want to overstate this. The business case isn't empty, and it does capture some of what the transformation is supposed to produce. But three things sit outside it.

First, it rarely says whether your team is expected to make those results happen. Revenue, cost and cycle time belong to business leaders. Your team influences them through understanding, readiness, manager reinforcement and capability. You don't control pricing, demand, product quality, supply, technology performance or staffing. Even if the case did hand the outcome to you, you couldn't deliver it alone.

Second, there are expectations that never made it onto paper. Hopes about where the business should be by now. Feelings about whether things are moving fast enough. Processes that quietly depend on the financial outcome and were never built out. Then something outside the program changes, the pressure rises, and people feel you should be doing more, without saying what more would look like or tying it back to what the transformation was justified on.

Third, the milestones that were written down don't hold still. The work shifts, and something that looked feasible turns out not to be feasible in the first phase. It isn't that it will never get done. It just won't get done first. A slipped milestone gets read as no value.

Bad faith is rare. Nobody made the role explicit, so it defaulted to the one group that can't fill it.

Nobody gets fired for a benefit that never had an owner, except someone on the transformation team.

I think those unwritten pieces, the assumptions, the hopes and the dependencies, are the real assets a transformation team should be collecting and managing.

Stop claiming credit. Build a case.

The usual defense is a number. Training is 97% complete and adoption is 81%. It's true, and it doesn't answer the question you were asked. It also leaves you taking credit for results you didn't control, or blame for results you did.

Build a case instead. Here is the outcome we wanted. Here is what had to be true for it to happen. Here is what we did about the parts we could influence. Here is what the evidence shows. Here is who owns the rest. A case beats a claim, and you can start building it in week one. It also pulls the real owners into the outcome while they still have time to act.

Week one: ask what has to be true

You may be handed a number you didn't build and can't fully vouch for. Challenging it head on is rarely safe. Ask a different question: what has to be true for this to happen? You aren't disputing the ROI. You're finding out what it depends on.

Say you're leading the launch of a new treatment at a life sciences company. Commercial success depends on sales knowing how to position it, the CRM capturing opportunities correctly, managers deciding where stretched salespeople spend their time, marketing having approved materials, manufacturing making enough product and supply chain getting it to where demand exists. One outcome, many paths that all have to come together.

For each condition, ask whether your team can influence it, whether another part of the business shares it, or whether it sits with someone else. Then get a named person to accept it.

That conversation is uncomfortable, and it is the first proof of value. It exposes owners who have deferred, assumptions nobody tested and conditions nobody owns. Finding that in week two beats finding it in month nine. A number alone invites doubt. A number with its conditions and named owners invites commitment.

While the work runs: show whether the conditions are getting stronger

Track three things. What is the potential outcome? Are the conditions for it being put in place? Has the business result shown up? They coexist. A company can hold $20 million of potential value, have most of the conditions in place and have realized $3 million.

The earliest evidence is human. Six months before launch, one employee says, "I understand why we're changing this, and my manager has already started talking with us about how our work will change." Another says, "I understand the project, but my manager says we'll probably keep using the old process." Neither is an adoption metric. The second one tells you more, and you can still fix it.

A red, yellow or green can't say that marketing and manufacturing are ready while sales capacity stays tight, or that CRM adoption is climbing while managers keep pushing the established products. You can. Say where the outcome is moving, where it's stuck and who owns the stuck part, and say it to that person early enough to matter. It also answers "what is your team doing?" before anyone has to ask. When a milestone slips, you aren't defending a date. You're showing what changed.

At go-live: hand over the evidence along with the system

Most handovers transfer what the team built. Transfer the outcome too: the result, the conditions, the evidence so far, what remains open and who owns each piece. Owners accept it out loud, with a short list of signals to watch and a name for who's watching. A ninety-day check-in helps, but the design should work without one.

Months later: contribution beats credit

When someone asks what the transformation delivered, the owners can answer, and the answer holds up better than a claim. "The conditions for the productivity outcome are largely in place. People use the new process consistently and throughput has improved. The financial benefit hasn't shown up because nobody has removed or redeployed the extra capacity." Or: "Adoption no longer limits us. Commercial results now depend on sales capacity and market demand."

Those are business conversations. A new manufacturing system works, people are proficient, throughput climbs, and the revenue never arrives because the company can't sell the extra output. The transformation delivered the operational outcome, and demand blocked the financial one. The reverse happens too: product ready, supply available, strategy sound, and managers still don't reinforce the new behavior. That one belongs to the transformation team, and the evidence should say so. This doesn't shelter the change function. It holds the team to what it controls and puts the next constraint in front of the person who owns it.

Why most teams can't work this way yet

The evidence lives everywhere: business cases, plans, meeting notes, stakeholder conversations, employee feedback, operational reports, financial results. It arrives at different times, and earlier evidence changes meaning as new facts land. The usual fix is software that asks the team to type it all in. Now people spend their capacity feeding a system so they can prove they did the first job. We took the old process, put it in a UI and called it intelligence.

Forms existed because software couldn't read. It can now. I expect tools that work from the plans, notes, conversations and reports teams already produce, that show what they think and why, and that keep a person in the loop to correct the conclusion when it's wrong. The system does the heavy lift. The team keeps the judgment.

The seat teams have been missing

When a team can show where an outcome is stuck and who owns the stuck part, the relationship with the business changes. Proof stops being a defense at the end. The team becomes the group that sees constraints first, names the owners and brings evidence early. That earns trust, and trust earns a bigger seat: a voice on what to fund, how to sequence it and which conditions need an owner before launch.

Transformation teams were never going to prove they caused a business outcome. A better standard is answering three questions with more confidence each week.

A team that can answer those has named the outcome, made ownership explicit, strengthened the conditions within its reach and handed owners the evidence to act on the rest. That beats any ROI slide, and it starts in week one.