What usually causes the delay?

The organisation rather than the product: material that is not findable or current, a permission question nobody has answered, and the weeks it takes for a new method to become the one people reach for. Access is quick and none of those are, which is why vendor setup times are a poor guide to anything.

How should we estimate it?

As a list of what it is waiting on rather than as a duration. This material has to be organised, this policy question answered, this group has to change a habit. That form can be checked as you go, and it turns the slow parts into work somebody can pick up instead of a delay to be reported later.

Does a long time to value mean the tool is wrong?

No, but it changes what the decision requires. A long payback needs sponsorship that survives a change of priorities and a plan for the stretch with nothing to show. Buying it on the strength of an afternoon's enthusiasm is what leads to cancellation partway, with the cost spent and the benefit still ahead.

Usually by narrowing rather than by hurrying. Pointing the tool at one team's most painful task gets something real back sooner than a general deployment, and it produces evidence that funds the wider work. Shortening the preparation itself mostly means deferring it, and the deferred part reappears once people start depending on the output.

Glossary

Time to value

Time to value is how long it takes from buying something to the point where it is genuinely paying back, which separates a tool you can try from a programme you have to commit to.

In plain terms

Between the decision and the benefit there is a period of setting up, learning, and getting the thing pointed at the right work. For some tools that is an afternoon. For others it is a project with a data cleanup in the middle. The length of that period decides how much conviction the purchase needs, because a long one has to be funded and defended through a stretch where there is nothing to show.

Why it matters

Because it determines what kind of decision you are making, and it is frequently misjudged in the optimistic direction. A tool that pays back in a fortnight can be tried on somebody's judgement and abandoned cheaply if it disappoints. A tool that pays back in two quarters needs sponsorship that survives a change of priorities, and buying the second while planning for the first is how initiatives get cancelled in month three with the money spent and the benefit still ahead of them.

How it works

The slow part is almost never the software. Access takes minutes; deciding which work to point it at, getting the material into a state it can use, agreeing what is permitted and persuading people to change how they do something all take considerably longer. A tool marketed on how quickly it installs is answering a question nobody was stuck on.

Data readiness is the commonest delay and the one least often planned for. Anything that answers from your own material is waiting on that material being findable, current and permitted to use. Where it is scattered across systems with unclear ownership, the tool is ready and the organisation is not, and the interval belongs on the estimate rather than coming as a surprise.

Habit is a real cost with a real duration. People have an existing way of doing the work that is reliable and fast for them, and the new way is slower until it is not. That crossing takes weeks of ordinary use rather than a training session, and treating it as instantaneous is what makes a fortnight's estimate become a quarter.

It varies enormously by what the tool does, which is why a single organisational expectation is unhelpful. A drafting assistant is useful the day it arrives. Something that searches across internal systems needs those systems connected and their permissions understood. An automation needs the process it automates to be stable enough to be worth encoding. Judging all three against one expectation makes two of them look like failures.

The honest estimate names what it is waiting on. Not a duration but a list: this material has to be organised, this policy question has to be answered, this group has to change a habit. Stated that way the estimate can be checked, and the parts that are slow become things somebody can work on rather than a delay to be reported.

Where the time actually goes

Almost all the published attention goes to the first mark, which is the shortest and the only one the vendor controls. The second is where most projects actually sit for longest, because it contains the unglamorous work of deciding which task this is for and getting the underlying material into a state where the tool can do anything useful with it. The third is the one that gets left off plans entirely: people have an existing method that is fast and reliable for them, and the new one is slower until enough repetitions have passed. Reading the picture this way changes what an honest estimate looks like. Rather than a number of weeks, it becomes a statement about which of these three is the constraint here, and that version can be worked on by somebody instead of merely being waited out.

Seen in the wild

A drafting assistant that produces something useful on the first afternoon, where the only preparation is deciding what to try it on.
ChatGPT
Internal search that cannot be judged until the systems it reaches across are connected and their permissions are understood.
Glean
An automation that waits on the underlying process being stable enough to be worth encoding at all.
Make

Common misconceptions

People assume

A short setup means a short time to value.

In fact

They measure different things and the second is usually much longer. Setup ends when the tool works; value starts when the work changes. Between them sit the data preparation, the permission questions and the habit, none of which appear in a quick-start guide and all of which are on the organisation's side rather than the vendor's.

People assume

It is the same for every tool we buy.

In fact

It differs by an order of magnitude across categories, and holding one expectation makes the slower ones look like failures when they are behaving normally. An assistant is useful immediately; something answering from internal material is waiting on that material. The estimate belongs to the tool and the work, not to the organisation.

Telling them apart

Time to value vs AI ROI

Time to value

When the benefit starts. Decides how much patience the purchase needs.

AI ROI

Whether the benefit exceeds the cost, once it has started.

A tool can have an excellent return and a time to value long enough that nobody waits for it.

Questions

What usually causes the delay?: The organisation rather than the product: material that is not findable or current, a permission question nobody has answered, and the weeks it takes for a new method to become the one people reach for. Access is quick and none of those are, which is why vendor setup times are a poor guide to anything.
How should we estimate it?: As a list of what it is waiting on rather than as a duration. This material has to be organised, this policy question answered, this group has to change a habit. That form can be checked as you go, and it turns the slow parts into work somebody can pick up instead of a delay to be reported later.
Does a long time to value mean the tool is wrong?: No, but it changes what the decision requires. A long payback needs sponsorship that survives a change of priorities and a plan for the stretch with nothing to show. Buying it on the strength of an afternoon's enthusiasm is what leads to cancellation partway, with the cost spent and the benefit still ahead.
Can it be shortened?: Usually by narrowing rather than by hurrying. Pointing the tool at one team's most painful task gets something real back sooner than a general deployment, and it produces evidence that funds the wider work. Shortening the preparation itself mostly means deferring it, and the deferred part reappears once people start depending on the output.

Key takeaways

Setup time and time to value are different measurements, and the second is much longer.
The delay is almost always on the organisation's side, not the product's.
Data readiness is the commonest cause and the least often planned for.
Estimate it as a list of what it is waiting on, which can be checked and worked on.
Narrowing the first target shortens it; hurrying the preparation only defers it.

Tools that use this

ChatGPT
Useful on the first afternoon, with almost nothing to prepare.
Glean
Cannot be judged until the systems it reaches are connected and permissioned.
Make
Waits on the underlying process being stable enough to encode.

Last checked July 2026

All glossary terms