The five columns that make a goal testable

Two people can agree that the goal is to cut waste and still disagree at acceptance, because one agreement is about a sentence and the other is about a number. The metric definition table exists to make the second agreement possible. It has five columns, always the same five, always in this order.

The five columns

1. Metric definition. What exactly is counted, in the unit the customer already uses. "Waste" is not a unit; monthly write-off value is. The definition should be written so that two clerks reading it on different days would count the same thing.
2. Data source. Which system, which export, which account, and who has access. The source must be the customer's own data, not a sample the FDE assembled, because acceptance run on the vendor's data is a rehearsal rather than a test.
3. Statistical window of at least four weeks. A single week can be a good week. Four weeks is the shortest window that separates a trend from a run of luck, and it is the same duration the four-week rule uses to decide whether anything is alive.
4. Exclusion rules. Which days, stores, orders or exceptions do not count, written before the window opens. Written afterwards, every exclusion is an excuse, and both sides know it.
5. Dispute arbiter. A named role with access to the data and the authority to decide. Not a committee, not "the two project leads", not "we will work it out".

The fifth column is the one people skip, and it is the one that determines whether the other four survive a bad month.

What the five columns produce

A goal with all five columns can fail. That sounds like a low bar until you notice what the alternative is. A goal without them can be declared met by whoever speaks last, which feels safer during the project and is far more expensive at renewal, because neither side has anything to point at.

The definition stage locks four things: terminology, data basis, acceptance basis and fallback. The table is the acceptance basis, and the acceptance basis is what a delivery gets judged against later. It is also the precondition for killing something: a feature that has no line in the table cannot be declared dead, because there is no measure against which death could be observed.

A filled-in example

An anonymised retail deployment, with the top-priority metric in the first row:

Metric definition	Data source	Window	Exclusions	Arbiter
Monthly write-off value, the gap between delivered and sold units valued at cost	Customer's store POS export and delivery system log	Four consecutive weeks, settled by calendar week	Closed days, stocktake days and system downtime	The customer's finance owner for reporting
Per-store daily gap between units delivered and units sold	Same export, same log	Four consecutive weeks	Same as above	Same role
Share of store-days with a complete delivery and sales export	Both exports joined by store and date	Four consecutive weeks	Days when either export failed validation	Same role

Notice what the table does not contain: a target. Targets belong in the quote; the table defines what would be measured if a target existed. Keeping those apart is what lets a project renegotiate a number without renegotiating the definition.

The same table, done badly

A common version reads: metric "improve store operating efficiency"; source "the customer's backend"; window "after go-live"; exclusions "none"; arbiter "both parties, amicably".

Each column fails in a specific way. Efficiency has no unit, so the first dispute is about what to count rather than about the result. "The backend" is not a data source; nobody can reproduce the number without asking a person. "After go-live" has no end, so the measurement can be taken on the best week or the worst week, and the choice will be made by whoever is losing. "None" guarantees that the first holiday becomes an argument. And an amicable arbiter is not an arbiter; it is a postponement.

The deeper problem is that this table cannot produce a verdict. The project can end with everyone agreeing it went well and no one able to say what changed. That outcome is worse for the FDE than a clear failure, because a clear failure can be written into the sixth section of an anatomy and turned into a method-library entry, while a vague success teaches nothing and renews nothing.

How to use it on the next project

Fill all five columns before the quote goes out, lock exactly one row as the top-priority metric, and have the customer sign the table itself rather than a summary of it. Then check the table against the four-week rule: every row should be measurable over a window that long, or it does not belong on the page. If a row cannot survive that check, the honest move is to delete it and say so, which is also the moment to revisit the scope and the price built on top of it.