# Value Realization

> Closes the loop that every other financial-case skill in this pack opens — checks realized results against the original business case, full-potential diagnostic, or synergy case line by line, and attributes the gap to assumption error, execution, or external shock. Use whenever the user wants a post-implementation review, wants to check if an initiative or deal actually delivered its promised value, or has a past business case, full-potential diagnostic, or synergy case that's never been checked against what actually happened.

- Skill: `natan-mohart/value-realization` (Agent Skill)
- Install (CLI): `npx skillmds@latest add natan-mohart/value-realization`
- Raw SKILL.md: https://api.skillmd.com/api/skills/natan-mohart/value-realization/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Natan-Mohart (https://skillmd.com/u/natan-mohart)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/natan-mohart/value-realization

---


# Value Realization

## When to use
Use 6-18 months after a business case, full-potential diagnostic, or synergy case was approved, to check whether it actually delivered. Every skill in this pack that produces a projection (business-case-builder, full-potential-diagnostic, synergy-case-builder) has no accountability loop without this step — a business case with no eventual value-realization check tends to get more optimistic over time, since no one ever pays for being wrong.

## What it does
Compares the original projection's driver-level numbers against actuals at the same granularity, attributes material variances to a specific cause (assumption error, execution gap, or external shock), and states plainly whether the initiative is on track but delayed, or genuinely off track — then feeds the finding back into how future cases in this organization get built.

## Method
1. **Pull the original projection at driver level**, not just the headline number — the same granularity business-case-builder, full-potential-diagnostic, or synergy-case-builder produced.
2. **Gather actuals at the same driver-level granularity and time periods**, so the comparison is apples to apples.
3. **Compute variance per driver, not just the bottom line** — offsetting errors can make a headline number look fine while hiding that every underlying driver missed in a different direction.
4. **Attribute each material variance to one cause**: assumption error (the input was wrong from the start — check against any assumption-audit that exists), execution gap (the assumption was reasonable, delivery fell short), or external shock (outside anyone's reasonable forecast).
5. **State the verdict plainly**: on track but behind schedule (needs a revised timeline, not a new decision), or genuinely off track (needs a real decision about continuing, adjusting, or stopping).
6. **Feed the recurring cause back into practice.** If assumption error keeps showing up across past reviews, that's a signal the assumption-audit step is being skipped or done too lightly upstream — name it as a process fix.

## Inputs
- The original projection (business case, full-potential diagnostic, or synergy case) at driver-level detail
- Actual results at the same granularity and time periods
- Any assumption-audit findings from the original case, if available

## Output format
Driver-by-driver projected-vs-actual comparison with variance; cause attribution per material variance; an explicit on-track-but-delayed vs. off-track verdict; one process-level learning fed back into future case-building.

## Example
An initiative projected at $3M NPV within 18 months is reviewed at month 12: revenue tracks 15% below plan (an overly optimistic conversion-rate assumption, an assumption error) while costs run 10% under plan (an execution win). The blended NPV still looks roughly on track, but the review flags the revenue-driver miss as the real signal worth revisiting, rather than declaring the case validated because the bottom line happens to still look fine.

## Common pitfalls
- Checking only the bottom-line number, missing that offsetting driver errors can accidentally produce a healthy-looking total.
- Treating every miss as an execution failure without checking whether the original assumption was ever realistic.
- Skipping the review once a case has served its purpose of getting funding approved, breaking the accountability loop for every future case.