Operated function · time to first value
Nothing is wrong. The kickoff happened, everybody was enthusiastic, and then the customer needed to raise an internal access request, their data owner went on leave, and the sponsor got pulled onto something urgent — and none of that is anybody’s job to chase.
The kickoff is good. Both sides are motivated, a plan is agreed, dates are written down, and everybody leaves the call believing this one will go smoothly. Then the plan meets the customer’s actual organisation.
The first dependency is usually theirs and it is usually small: an access request that needs a ticket, a data extract that needs a person who has other work, a security review that has a queue, a decision that needs somebody one level up. Each individually is a week. Together they are a quarter.
Nobody owns chasing it. Your side does not want to nag a customer who just paid; their side is not blocked on anything urgent, because the thing they bought is not yet doing anything that hurts to be without. So the request sits, politely, in a state where both parties believe the other is progressing.
The sponsor moves on. Not away — just on, to the next thing, because the purchase felt finished at signature. When the project needs a decision three weeks later there is nobody with the standing to make it quickly, and it waits for a calendar rather than for a judgement.
And the internal reporting looks fine, because implementation projects are reported by phase and the phase gates are ours. The customer sitting in "awaiting client data" for six weeks shows as on track in a status that measures our own steps.
Most onboarding elapsed time is spent waiting on a dependency inside the customer’s organisation, and implementation plans measure our phases — so the dominant component of time-to-first-value is not on the chart.
That is why adding implementation capacity so rarely shortens onboarding. More consultants complete our steps faster and change nothing about the six weeks awaiting an access request, which was most of the elapsed time to begin with.
Making the waiting visible is the whole move, and it requires a different unit: not phases but dependencies, each with an owner named on the customer’s side, a date it was requested, and an age. Once a dependency has an age, it becomes chasable — and chasing something specific and small is socially very different from asking a customer how the project is going.
The second thing is renewing the sponsor rather than assuming them. The person who signed felt finished at signature; a short, specific, low-effort touch that tells them what is blocked and what one thing they could unblock is worth more than a monthly status document nobody reads.
And the third is defining first value before anything starts. Most onboarding has no agreed completion condition, which means it cannot be reported as late — and something that cannot be late is something nobody hurries.
The pattern data closes it: when the same dependency stalls most customers, the correct fix is upstream in what you ask for or when you ask for it, which removes the delay for everybody rather than chasing it per account.
Time from signature to observed first value — measured by elapsed days against your own baseline, measured from signature rather than from kickoff.
How that time divides — measured by our work, our waiting, and waiting on the customer — separated, where previously only our phases were tracked.
Dependencies with a named owner and an age — measured by the share carrying both, against a baseline where they existed as plan text without either.
Customers stalled past your threshold — measured by accounts with no dependency movement past your defined age, surfaced rather than found at a review.
Which dependency stalls most often — measured by stall frequency by dependency type across accounts, which points at an upstream fix rather than a per-account chase.
Whether onboarding can be said to have finished — measured by accounts reaching an agreed, observable first-value condition, against a baseline where completion was a judgement.
that a customer who has lost interest is re-engaged by chasing, and no authority inside your customer’s organisation. Nothing here escalates within their business, raises their tickets, or overrides their priorities. It makes the waiting visible and specific; the customer still has to act.
Plan and stage state come from whatever you already run implementations in. Nothing migrates and no second project plan is created — two plans for one implementation is how two people give a customer different dates.
The observable first-value condition is read from your own product or systems wherever possible, because a completion condition that depends on somebody ticking a box in a status meeting is a completion condition that gets ticked to close a project.
Customer-side dependencies are tracked as records with owners and ages, not as bullet points in a document — a bullet point cannot age and cannot be chased.
Everything goes out in your name, in language your delivery and account leadership approved, and is attributed rather than impersonated. The tone question matters more here than anywhere else in this group, because the recipient has already bought and a badly-judged chase reads as being managed rather than served.
The boundary is the dependency. A specific, small, named ask is delegated. Renegotiating scope, moving a contractual date, discussing commercial consequences or escalating within the customer’s organisation is not, and those route to your account owner.
Frequency is capped by your rule, and an account whose sponsor has gone quiet escalates to a human rather than receiving a fourth message.
Operational access is not permission to train. Customer implementation data — which frequently includes their internal structure, systems and constraints — does not become material improving anything serving another organisation, including their competitors.
Account owners must agree the message set, because it reaches customers they are responsible for and a chase that lands wrong costs them a relationship they will have to repair.
Delivery leadership owns the first-value definition and the stall thresholds. A vendor-set threshold produces alerts that do not match how your implementations actually run.
Where your contracts contain onboarding obligations or milestone-linked payments, those are established at scoping, because a chase that touches a contractual milestone is a commercial communication rather than an operational one.
One trailing cohort of implementations — read-only, no customer contacted — measuring elapsed time from signature to observed first value, split into our work, our waiting, and waiting on the customer.
Measuring from signature rather than kickoff is the change that makes the number honest, and it usually adds weeks nobody was counting. The three-way split is the finding: most organisations discover the dominant component is customer-side waiting they had no chart for.
The cross-account pattern arrives with it. Where one dependency stalls most implementations, the fix is upstream — ask for it earlier, ask for less, or remove the need — and that is a change you make once rather than a chase you run forever.
If you continue, the first delegation is the specific dependency chase on one cohort, with the first-value definition agreed and the message set signed off by the account owners.
On schedule against a plan that starts at kickoff and is made of your own phases, most do. Measure from signature and split out customer-side waiting and the number usually changes materially. That is a read-only exercise on implementations that already finished, and if the split shows waiting is a small share, your onboarding genuinely is fine and this is the wrong purchase.
Asking how the project is going does. Asking whether one named person has been able to raise one specific access request does not — it reads as competence, because it demonstrates you know exactly where the thing is. The difference is specificity, which is why dependencies are tracked individually with owners and ages rather than as a plan status. Where an account is sensitive, it routes to its owner rather than into a cadence.
Largely true per account, and largely false across accounts. When the same dependency stalls most of your implementations, the actionable fix is yours: ask for it at signature instead of at kickoff, reduce what you need, or remove the need. That pattern is invisible while each delay is treated as that customer being slow, and it is the highest-return output of the observation phase.
Almost nobody does, and that is the finding rather than a blocker — something with no completion condition cannot be late, and something that cannot be late is something nobody hurries. Agreeing an observable condition, read from your own product rather than declared in a status meeting, is part of the first phase and is worth doing whether or not anything is ever delegated.