How to Define a Measurable Outcome

A measurable outcome states what will be true when the work is done, in a way you can verify — a result, not an activity. "Treasury sees group cash intraday without touching a spreadsheet" is an outcome. "Build a cash dashboard" is an activity. The difference matters because teams that commit to activities can complete every task and still fail — the dashboard shipped, and treasury is still rebuilding the position by hand. An outcome tells everyone what success actually looks like, and lets you prove whether you got there.

Outcome vs output

An output is what you produce: a report, a feature, a system. An outcome is the change that output is meant to create. They're easy to confuse and expensive to confuse:

You can hit every output and miss the outcome. That's the whole reason to define the outcome first.

What makes an outcome measurable

Three things:

• Specific — a concrete end state, not "better" or "improved."
• Observable — you can point at something and say whether it's true.
• Tied to the problem — it resolves the actual pain, not a proxy for it.

How to write one, from the problem

The outcome falls out of a well-stated problem. Take the problem, describe the world once it's solved, and phrase it as something observable:

• Problem: "Treasury rebuilds month-end exposure by hand; it's slow and error-prone."
• Outcome: "Month-end exposure by entity is produced automatically and reconciles first time, without a manual rebuild."

Notice the outcome names no solution — not a report, not a system. That's deliberate: it leaves room for the best answer, and it's what you'll measure regardless of how you build it.

Leading, lagging and proxy measures

Some outcomes are directly measurable (a number, a cycle time). Others are harder, and you use a proxy — an observable signal that stands in for the real result. That's fine, as long as you're honest that it's a proxy and it genuinely tracks the outcome. What you're avoiding is a vanity measure — something easy to move that doesn't reflect the real change (usage of a feature nobody needed, say).

An example

• Vague: "Improve the cash forecasting process." Not measurable — you can't tell when you're done.
• Measurable: "The two-week cash forecast is produced weekly with no manual spreadsheet consolidation, and forecast accuracy at the one-week horizon is tracked and improving." Now everyone knows the target and can verify it.

What usually goes wrong

• Activity disguised as outcome. "Deliver the new module" — that's an output; the outcome is what the module changes.
• Unmeasurable outcomes. "Make it better" — no way to know if you succeeded, so scope and success float.
• Vanity measures. Optimizing something easy to move that doesn't reflect the real result.
• No owner for the outcome. A measurable outcome with no one accountable for it still slips.

Define the outcome first, make it observable, tie it to the problem — and you've given the work a target everyone can aim at and verify. That's exactly the field Delivery Sheet forces next to the problem: what's true when this is done, and how you'll know.

Part of the Finance Systems Delivery guide. See also problem statements vs solution requests and the project intake process. The newsletter sends one finance-systems pattern every two weeks.