For most every business case that gets approved, almost none get proven. That gap, between what got funded and what anyone can actually point to eighteen months later, is where most technology investment quietly loses its credibility with Finance.
The problem usually isn't bad math. It's that nobody comes back to check it later.
Most technology business cases get built once, at the very start of a program, by the people closest to the solution and furthest from the balance sheet. They're optimistic by design and static by nature. Then they get handed off the moment the project starts, right when reality begins testing every assumption inside them. The people who built the business case have moved on. The baseline has been forgotten, or may have never been established in the first place. The original value projections can end up bearing no real resemblance to what actually happened.
That's not a business case. That's a pitch with a shelf life.
Value engineering fixes this. But only if it's treated as a discipline that runs the length of the engagement, not a document that opens it. At Naitiv, we build the case in three phases that map directly to how the work actually gets done: Design, Deploy, and Run. Each phase has a different job to do for the value case, a different failure mode if skipped, and a different owner inside the client organization who needs to sign off before it's real.
This is that framework.
Implementation-first thinking treats the business case as a gate. Clear it, get funded, move on to the "real work" of configuring and deploying. Outcome-first thinking treats the business case as the spec: the thing the entire engagement exists to prove true, phase by phase, with evidence Finance would actually accept.
The difference shows up in what gets measured. An implementation-first program tracks go-lives, tickets closed, and scope delivered. An outcomes-first program tracks the same operational data, but ties every milestone back to a dollar figure someone in Finance agreed to before day one.
That single discipline, insisting the case survive scrutiny at every phase and not just at kickoff, is what separates technology spend that gets defended at renewal from technology spend that gets flagged for review.
This is where most business cases actually get written, and where most of them quietly fail. Not because the arithmetic is bad. Because it's unfalsifiable. "Improved efficiency" and "reduced risk" are directional claims, not numbers Finance can underwrite.
A value case built during Solution Architecture and advisory engagements needs three things a slide deck rarely has.
A real baseline, wherever the data supports it. Current-state cycle time, cost per transaction, error rate: when those numbers exist, get them before the engagement starts, because a case built without them can't credibly claim improvement afterward. It can only claim a story. Not every engagement produces a clean quantitative baseline. Sometimes the client's data maturity only supports a qualitative one. Either way, discovery work should aim to produce it. Treat it as a deliverable, not a formality.
A range, not a point estimate. A single ROI figure invites a single objection: why not half that? A modeled range, conservative, likely, aggressive, with the assumptions driving each scenario shown explicitly, invites a conversation about which assumptions are realistic instead of a debate about whether the whole case is fiction.
A cost of inaction. Finance rarely funds a project purely on upside. They fund it when the downside of not acting is priced out too: compliance exposure, attrition from manual work, competitive erosion, technical debt compounding. Outcomes-over-implementations thinking means the design phase produces both sides of that ledger before a single configuration decision gets made.
The deliverable that survives Phase 1 isn't a slide. It's a baseline, a range, and an owner in the business who agrees the numbers are theirs, not the vendor's.
This is the phase implementation-first programs get most wrong, because all the pressure is on scope, timeline, and go-live. Measurement gets treated as something you'll "figure out after launch."
By then it's too late. If the workflow, the dashboard, or the reporting layer wasn't designed to capture the specific metric the Phase 1 case was built on, you don't get a second chance to baseline it. You get an implementation team insisting the project succeeded, and a Finance team with no way to independently confirm it.
Value engineering during deployment means three shifts in how the project gets run.
Measurement is a requirement, not a report. Wherever it's scoped and the data lives on the platform, the KPI from the value case should get built in, a field, a workflow state, a dashboard, during configuration, not requested from IT six months after go-live. That's the standard to design toward. It has to be priced into the SOW like any other requirement, and some KPIs sit in Finance or ERP systems outside the platform, where configuration alone won't capture them. Either way, the instrumentation needs an owner and a plan before go-live, even if the plan is "this one gets pulled from Finance's system, not ours."
Milestones are value checkpoints, not just delivery checkpoints. "Module configured" and "UAT passed" are project milestones. "First measurable reduction in cycle time observed" is a value milestone. A mature implementation plan tracks both, and reviews them with different audiences.
The business case gets revisited at go-live, out loud. Assumptions made in Design get tested against what was actually learned during Deploy: new constraints, better data, scope changes. If the number moved, say so before Finance finds out on their own. A revised case with a documented reason is credible. An unrevised case that turns out to be wrong is not.
This is the phase where outcomes over implementations gets operationalized or abandoned. Go-live isn't the finish line. It's the point where the case stops being a hypothesis and has to start being a claim backed by evidence.
Here's the uncomfortable truth about managed services and ongoing operations: this is where most value cases go to die quietly. Not because the value stopped being delivered. Because no one is still measuring it against the original claim. The team that built the case is gone. The dashboard that tracked it wasn't maintained. The system runs fine. Nobody's watching whether it's still worth what it costs.
Then renewal season arrives, and Finance asks a version of the same question they asked at Design: what are we getting for this? If the honest answer is "the same thing we said eighteen months ago, probably," that's not a renewal conversation. That's an audit risk.
Operating the value case, not just the system, means three things.
Value realization tracking is a managed service, not a courtesy. The metrics defined in Phase 1 and instrumented in Phase 2 get reported on a cadence, quarterly at minimum, with the same rigor as an uptime SLA. If it's worth promising, it's worth reporting.
Business reviews are priced in dollars, not tickets. A quarterly business review that lists resolved incidents is an operations report. One that shows realized savings against the original baseline, updated for what's actually changed in the business, is a value report. That's the document that defends the contract at renewal.
The case gets re-underwritten, not just re-upped. Businesses change. A case built two years ago against a baseline that no longer exists isn't being defended. It's being assumed. Treat every renewal as a chance to refresh the baseline and reconfirm the number. It's a lot easier to do that proactively than to explain, defensively, why nobody did.
This is also where Naitiv builds AI Ledger style audit trails into the operating model. Not because every client needs regulatory-grade evidence, but because the same discipline that satisfies an examiner also satisfies a CFO: a transaction-level record of what was promised, what happened, and what it was worth.
The Discipline Underneath the Framework
Design, Deploy, and Run map cleanly to advisory, implementation, and managed services. But the framework isn't really about service lines. It's about refusing to let the business case become someone else's problem the moment your phase of work ends.
A few operating principles carry the whole thing.
One case, three owners, zero handoff gaps. The same value case should be legible to the advisory team writing it, the implementation team building against it, and the managed services team reporting on it. If each phase produces its own version of "value," that's not a business case. That's three separate opinions.
Baselines are assets. Protect them. The single most common reason a value case can't be proven later is that nobody preserved the starting point. Baseline data deserves the same care as the solution design itself.
Silence is the enemy, not variance. A number that moved, with a documented reason, is defensible. A number that was never revisited is not, even if it turns out to still be accurate.
The business case is a living instrument, not a launch artifact. Pull it out and update it at every phase gate: design sign-off, go-live, and every business review after that.
Business cases don't fail contact with Finance because Finance is adversarial. They fail because they were built to get approved, not to get proven. A one-time argument instead of a running account.
Outcomes over implementations means building that running account from the first discovery workshop through every managed services review that follows. So that when someone asks what the investment actually delivered, the answer isn't a memory. It's a record.
That's the case that survives contact with Finance. Because it was never just a pitch to begin with.
If your last business case has gone quiet since go-live, that's worth a conversation. Reach out and let's re-baseline it, wherever it stalled, so you're working from a record instead of a memory. Contact us at info@naitiv.com.
.svg){kind=icon}
