Validation

Establish evidence about emerging and realized outcomes, compare it with expectations, and assess what it implies for the reasoning behind the change.

What it is

Validation establishes what outcomes a change is actually producing and what that means for the reasoning behind it. Unlike the first three functions, it does not correspond to one of the three fundamental elements. It is where the loop turns back on itself.

In the loop

Validation follows execution, though it does not have to wait for it to finish. It can begin as soon as meaningful evidence about outcomes exists, and for many changes that is well before anyone declares completion.

Its work has three parts. Establish what is actually happening, using outcome results and whatever else can be observed. Compare that against what was expected, principally the outcome targets. Then work out what the comparison implies, which is the part most easily skipped.

That third part is where validation earns its place. A difference between expectation and result has several possible explanations, and they lead in different directions. The direction may have been realized poorly. The assumption connecting the target state to the outcomes may have been wrong. Circumstances may have moved. The expectations may have been badly founded to begin with. Or the judgement about what was valuable may need revisiting. Attributing the difference to execution by default is a recurring mistake, and not necessarily the most accurate explanation.

Validation is also where unintended outcomes surface, if anyone is looking for them. A change that produced exactly what it promised and something damaging nobody anticipated has not succeeded, and no comparison against targets will reveal that.

From here reasoning can move back to execution, direction or intent, as far as the evidence warrants.

Vulnerability

Assumed success. The change is declared to have worked because it was delivered, implemented, or because its targets were met, without anyone establishing what it actually produced.

This is the easiest failure in the loop to commit, because everything about how change is organized encourages it. Delivery has a visible endpoint and outcomes do not. Teams disperse. Attention moves to the next thing. Nobody is left whose job is to ask what happened.

Outcome validation is the practice that addresses it.

Assumed success. Outcome validation is the practice that addresses it.

Guiding question

What outcomes are we seeing, how do they compare with what we expected, and what does that tell us about the reasoning behind the change?

Related

• Validation is one of the five functions of The Intent Loop. It has no corresponding fundamental element of change.
• It follows the Execution function and feeds the Evolution function.
• It uses Outcome references, principally outcome results compared against outcome targets.
• Outcome validation is the practice for this function.