Proof of value
A fifty-billion-dollar organisation should not be asked to adopt an operating system on the strength of a demonstration. It should be asked for one queue, one workflow or one measurable failure — with the baseline taken before, and the stopping condition agreed in advance.
A pilot was run. It went reasonably well. Six months later the organisation still has not decided, because nobody agreed beforehand what result would constitute a yes — so the outcome was interpreted rather than read, and each stakeholder interpreted it toward the position they already held.
It was also probably scoped to whatever was easiest to get permission for, which is rarely the thing that mattered. A pilot on a low-stakes queue proves that the technology works on a low-stakes queue, and the sceptics in the room know that.
And there was no baseline. Somebody measured after, compared it to a number remembered from before, and the comparison could not survive being questioned by anybody who wanted it not to.
Without a baseline taken beforehand and a stopping condition agreed in advance, the result is unfalsifiable — and an unfalsifiable result cannot move a decision.
The single most valuable artefact a proof of value produces is not the improvement. It is the baseline. Most organisations discover during that phase that they did not previously know how long their own process took, where the waiting was, or how much rework it generated.
That is why the first phase can be observation only. It grants no authority to act, changes nothing, and still produces the number that every previous improvement argument lacked. Several organisations should stop there and spend the quarter fixing what it revealed.
The second thing to agree in advance is what would make you stop. Written down beforehand, it is a criterion that makes the result meaningful. Raised afterwards, it is a dispute — and it is the same sentence either way.
Knowing where your process time actually goes — measured by work time, wait time, blocked time, approval time and rework, decomposed for the first time.
Whether the constraint is where everyone assumed — measured by the observed flow break, which is frequently somewhere nobody had proposed fixing.
Whether the authority model survives your security review — measured by the review completing, on a real deployment rather than a diagram.
Whether the result is defensible internally — measured by comparison against your own pre-agreed criteria and your own baseline.
What a failed attempt costs you — measured by result-settled economics — work we accept responsibility for and fail to complete is restored, not invoiced.
a guaranteed improvement. If the observation phase shows the constraint is a policy, a vendor or an approval nobody owns, the honest outcome is that we cannot move it and you learned that cheaply.
Read access to the systems holding the relevant state, one person who owns the process, and one person who can grant authority. That is close to the whole list for an observation phase.
It does not need a migration, a data warehouse project, or a platform decision. If a proposal for a pilot requires any of those, it is not a pilot — it is an implementation with a smaller name.
Identity comes from your identity provider so the pilot does not create a parallel user store that somebody has to clean up if you decline.
The authority granted is narrow enough to enumerate on a single page, and it can be withdrawn immediately without a contract change. Nothing widens without an explicit new grant.
The baseline and the result belong to you, in your possession, in a form you can take to your own stakeholders without us in the room.
A pilot is easier to approve than a purchase, but it is not exempt from review — and treating it as exempt is how a pilot becomes the thing security discovers in production later.
Bring security in at scoping rather than at go-live. An observation-only phase with read access to one system is a materially smaller review than a platform adoption, and starting there means the harder review happens with evidence rather than with a diagram.
One queue, one workflow, one department or one measurable operational failure — chosen because moving it would change somebody’s mind, not because it was the easiest to get permission for.
The temptation is to pick something safe. Resist it. A pilot on a low-stakes queue produces a result the sceptics can dismiss, and they will be right to, which means you will have spent a quarter and still be having the same meeting.
Pick something bounded but consequential, take the baseline before granting any authority, and write down what would make you stop. Those three decisions determine whether the outcome settles anything more than the technology does.
And be willing to conclude no. A proof of value that ends in a well-evidenced no is a successful proof of value, and it cost you a scope rather than a platform migration.
Because they lacked a baseline and a stopping condition, so the result was interpreted rather than read. Those two artefacts are what make this different, and both are produced before any authority is granted. If we cannot agree what a yes looks like during scoping, the pilot should not start.
For an observation phase they are approving read access to one system with no execution authority, which is a materially smaller review than a platform adoption. Bring them into scoping rather than presenting at go-live. If read access to the scoped system is still refused, that is a real constraint and it is better established in week one.
Then that is the result, and it was cheap. Observation frequently shows the constraint is a policy, an approval nobody owns, or a vendor dependency — none of which we can move. You would have learned that for the cost of a scoping exercise instead of an implementation, and you would have the flow data to act on it yourself.
The commercial terms are part of scoping rather than a surprise, and the underlying economics are result-settled: work we accept responsibility for and fail to complete is restored rather than invoiced. What we will not do is price a pilot so that failure is profitable for us, because that is the arrangement that makes every subsequent number untrustworthy.