Start here: the engagement playbook · The Final Leap

Read this once end to end before your first engagement. After that, work from it step by step — every step tells you what to do, which artefact to use, how to decide what happens next, and the condition that has to be true before you move on. Nothing here is optional reading for a lead consultant.

The rule this whole document exists to enforce

We sell measured outcomes, not activity. That means every claim we make at the end has to be traceable to a figure we agreed how to measure at the start — before anyone knew which way it would go. Every step below exists either to establish that trace or to protect it. Skipping a step does not save time; it removes the evidence that the work was worth paying for.

How the engagement is shaped

Four phases, six gates, fifteen steps. A gate is a decision point with written criteria: it is passed, or it is escalated. It is never quietly absorbed. If a gate cannot be passed, that is information the sponsor is paying us to surface, and surfacing it late is the single most expensive thing we can do.

The whole engagement. Fifteen steps, five phases, six gates. Colour marks the phase; a navy diamond marks a gate, where the engagement either passes written criteria or escalates.

Each gate rises on the one below it. You cannot sign off a baseline you have no access to, or prove a result against a baseline nobody agreed.

The same engagement against a calendar. The phases overlap deliberately — the maturity work in step 9 runs alongside the baseline extraction in step 8, which is also what you continue with when access has stalled.

Phase	Steps	Typical weeks	Gate at the end	What exists afterwards
Enquiry and qualification	1–4	Week 0	G0 Qualify	A named sponsor, a written question, and a go or a polite no
Propose and contract	5–6	Weeks 0–2	—	A signed SOW, and an engagement seeded in this workspace
Access and baseline	7–10	Weeks 1–6	G1 Access, G2 Baseline, G3 Telemetry contract	A validated pre-period, a maturity read, and metric definitions everyone has signed
Intervene	11–12	Weeks 5–14	G4 Changes live	Findings delivered, playbooks and guardrails live with pilot teams
Prove and hand over	13–15	Weeks 12–20	G5 Proof and handover	A populated scorecard, deltas reported with uncertainty, and a named internal owner

Where the week numbers come from

These are the ranges a 16–20 week Track 01 engagement actually runs to, not a target. Track 02 compresses phases one to three and spends longer in step 12. The dates that matter are the ones in the SOW; these are for sequencing, so you know what should already be true when you start a step.

Before you touch a step: five things that are always true

Measure before you change anythingIf you cannot establish a pre-period, say so in writing at G2 and state it as a design weakness in every deliverable that follows. A baseline reconstructed after the fact is a weaker claim, and we name it rather than hiding it.
Pair every speed metric with a counter-metricLead time never travels alone; it travels with change failure rate. A speed figure published without its counter-metric is the single easiest way to mislead a sponsor, including by accident.
Never report individual-level dataNo per-engineer anything, to anyone, ever — including to the sponsor who asks for it. The workspace has no column for it. If you are asked, see step 10 for the words to use.
Name the J-curve before it happensValue realisation dips before it rises. A sponsor who hears this in week two of a dip hears an excuse. One who heard it at kickoff hears a forecast coming true. This is the difference between a renewal and a cancellation.
Write the uncomfortable finding down firstThe finding you are reluctant to put in the readout is usually the one with the most value in it. Draft it first, while you still have the nerve, then decide how to say it well.

Read these before your first engagement

The Field GuideThe method in full — the reasoning behind every step below
Evidence registerEvery external claim we make and what each source does and does not support
Anti-gaming guardrailsHow each metric can be gamed and what we do about it

Qualify

Step 1 · The enquiry arrives

Convert an unstructured enquiry into a scored, comparable record with a verdict — before anyone spends calendar time on it.

Owner: Whoever is on enquiry duty that week
Time: 10 minutes
Done when: The lead exists in Leads with a score, a verdict and a named owner.

What happens

Enquiries arrive through the public form at /start. The form captures sponsor role, team size, when AI tooling was activated, which systems are reachable, what is driving the timing, and the problem in the enquirer's own words. On submit it scores itself out of eighteen across those six dimensions and assigns one of four verdicts. The lead then appears under Leads in this workspace.

If the enquiry came by email, phone or a conversation at a conference, you submit the form on their behalf. Do not keep a lead in your inbox. An unscored enquiry cannot be triaged, cannot be compared against the others sitting in the pipeline, and cannot be picked up by a colleague when you are on leave.

How the score is built

Dimension	Points	What earns the top score
Sponsor seniority	0–3	CTO, CIO, VP, Head, Director or Chief in the role title
Scale	0–3	200+ engineers
Baseline availability	0–3	Not yet rolled out, or activated within the last 3 months — the pre-period still exists
Data access	0–3	Git provider, CI/CD and incident tooling all reachable
Timing pressure	0–3	A fixed date: board review, audit or regulatory deadline
Clarity of the decision	0–3	A detailed written problem statement rather than a line of interest

Why "not yet rolled out" scores as highly as a recent rollout

Because the pre-period is the whole engagement. A client who has not yet activated their AI tooling is the best client we can have: we can measure the before properly. A client who activated eighteen months ago is a harder, weaker engagement whatever their enthusiasm, and the score says so deliberately.

Artefacts for this step

The enquiry formSubmit on the enquirer's behalf if the enquiry arrived another way
LeadsWhere the scored lead lands
Discovery and qualificationThe reasoning behind the scoring dimensions

Why this step exists

The expensive failure in consulting is not losing a bad deal. It is spending six weeks and two senior people discovering it was a bad deal. The scoring is deliberately harsh on the two dimensions that cannot be fixed by enthusiasm — whether a baseline still exists, and whether the data can be reached — because those two decide whether we can produce evidence at all.

The enquiry is scored. Now decide who gets a call.

Qualify

Step 2 · Triage: respond by verdict, within one working day

Give every enquirer a useful reply quickly, and spend discovery calls only where they can pay off.

Owner: Enquiry duty
Time: 20 minutes per lead
Done when: The lead status has moved off "new" and the reply has been sent.

The verdict decides the response. These are not suggestions — a "nurture" lead given a full discovery call is a day of senior time spent on a conversation that cannot convert yet, and a "strong fit" left for a week is often gone.

What the score does. The form assigns the verdict automatically; the verdict assigns the response.

Respond according to the verdict

Strong fit · 15–18

Reply within four working hours. Offer two specific 45-minute slots in the next three working days, named person to named person. Attach nothing except the one-pager. Ask one question only: which systems a read-only account could be arranged for, and how long that usually takes at their organisation.

Then: step 3, discovery call.

Qualified · 11–14

Reply within one working day with two slots in the next week. Before the call, identify which dimension scored low and prepare the question that resolves it — usually baseline availability or data access. Say plainly in the reply that the call will cover whether a defensible before-and-after is still possible.

Then: step 3, discovery call, with the weak dimension as the first agenda item.

Nurture · 7–10

Reply within two working days. Do not offer a discovery call. Send the field guide and the self-diagnostic, and name the specific condition that would change the picture — a named sponsor, a decision date, or read access. Ask to check back at a stated point, usually one quarter. Set the lead status to nurture and diarise it.

Then: revisit on the diarised date. Many of these return as strong fits once a budget cycle or an audit arrives.

Not yet · 0–6

Reply within two working days, honestly and warmly. Say that we would not be able to produce evidence worth their money yet, and why — usually no sponsor, no reachable data, or nothing to decide. Point them at the library, which is public. Do not offer a call, and do not leave the door artificially ajar.

Then: close the lead as not-yet. Record the reason; the pattern across these is how we learn what to change.

Saying no quickly is a service, and it is also commercial

A fast, reasoned no earns more referrals than a slow maybe earns revenue. Several of our strongest engagements began as a declined enquiry where the honest reason was remembered a quarter later. Write the no as carefully as you would write a proposal.

Artefacts for this step

Objection handling and FAQThe specific wording for the hard replies, including "can you just give us a usage dashboard"
Leaflets and one-pagersToolkit · 05-COMMERCIAL — the single attachment for a strong-fit reply
The field guideWhat you send a nurture or not-yet lead

A call is booked. Now find out whether evidence is possible.

Qualify

Step 3 · The discovery call

Establish whether a defensible measurement is possible, who owns the decision, and what question the engagement must answer.

Owner: Lead consultant, with a second on the call to take notes
Time: 45 minutes, and do not run over
Done when: The scorecard is scored, and the honest question is written in the sponsor's own words.

How to run it

0–5 min

Frame the call

Say what the call is for and what it is not. "By the end I want to know whether we can give you a defensible answer, and if we cannot, I would rather tell you today." This sentence sets up every honest conversation that follows.

5–20 min

The decision, not the technology

What decision is waiting on this? Who signs it off? What happens if the answer is unwelcome? Keep going until you have a decision with a name and a date against it. "We want to understand our AI ROI" is not a decision.

20–32 min

Data and baseline reality

Which systems, who grants access, how long it has taken before. When was the tooling activated, per team — not organisation-wide. Can a pre-period be reconstructed. This is the section that most often ends an engagement, so do not rush it to be polite.

32–40 min

Appetite for unwelcome findings

Ask directly: if the finding is that the rollout has not moved delivery outcomes, what happens to it? The answer tells you whether you are being hired for evidence or for cover. Listen for who they say they would have to tell.

40–45 min

Close with the question

Read back the one question the engagement must answer, in their words. Get verbal agreement on the sentence. Email it the same day. That sentence becomes the engagement objective in the workspace, and the readout is judged against it.

Score the card during the call, not afterwards. A score you calculate later cannot change what you say while you are still on the line — and the whole point is to let you say "I do not think we can help you yet" at minute thirty-five.

Qualification scorecard

Score it during the call. Eleven or below out of twenty-one is a polite no — and saying so quickly is worth more than a quarter of pipeline.

Dimension	0	1	2	3
Sponsor	No named owner	Interested manager	VP or CTO engaged	VP/CTO with a decision deadline
Pain	Curiosity	Internal questions being asked	Board or budget pressure	Spend under active challenge
Data access	Unlikely	Possible but slow	Achievable in ~4 weeks	Available now
Baseline	None recoverable	Partial history	Pre-rollout history exists	Already measuring
Scope clarity	Vague	Teams identifiable	Teams and systems named	Teams, systems and the decision named
Timing	No driver	Vague interest	Budget cycle approaching	Fixed date: board, audit or renewal
Change appetite	Wants validation of a decision already made	Open to findings	Prepared for unwelcome findings	Has already warned leadership metrics may dip

0/ 21Score the dimensions above

Disqualifiers override any score: a number wanted to justify a decision already taken, individual-level measurement, no sponsor above EM level, unobtainable access, or usage targets they will not reconsider.

Artefacts for this step

Discovery and qualificationFull question bank, the scoring rationale, and how to run the call
Discovery call scriptToolkit · 05-COMMERCIAL — the long-form script and question bank
Interview guidesToolkit · 02-ASSESS — for the stakeholder interviews that follow in step 9
Objection handling and FAQFor the objections that surface on this call

The answer that should stop you

If the sponsor says the decision has already been made and they need support for it, you are being asked to supply cover, not evidence. Decline. It will not survive contact with the data, and our whole proposition is that our numbers hold up when someone hostile checks them. R04 and R08 in the risk register both start here.

The call is scored. Now make the go or no-go explicit.

QualifyG0

Step 4 · Gate G0 — qualify, or decline

Make the go or no-go decision explicitly, with the criteria written down.

Owner: Lead consultant, countersigned by a second
Gate criteria: Sponsor named, systems known, the honest question agreed in writing.
Done when: G0 is marked passed in the workspace, or the lead is closed with a reason.

All three criteria, not two of three. A named sponsor who is a manager without budget is not a named sponsor. Systems "probably accessible" are not known. A question agreed verbally but never written down will have changed by the readout — and it will have changed in the direction that makes the engagement look worse.

Sponsor named, with budget authority or a named person who has it
The systems we need are identified, with an owner for each access request
The question the engagement must answer is written down and the sponsor has seen the wording
The scorecard total is 12 or above out of 21
Someone other than the lead consultant has read the above and agrees

The G0 decision

All five checks pass

Proceed to proposal. Create the engagement in the workspace now rather than after signature, so the gates and risks exist while you are writing the SOW.

Then: step 5.

Scorecard 12+ but a criterion is unmet

Name the single condition that would close it, put a date on it, and hold the proposal until then. Do not write around a missing sponsor; it is the most common cause of an engagement dying in month three.

Then: revisit when the condition is met.

Scorecard 11 or below

Decline, with the reason stated plainly. Offer the library and a check-back date.

Then: close the lead, recording the limiting dimension.

Qualified. Now put the measurement promise in writing.

Propose

Step 5 · Proposal and SOW

Put in writing what we will measure, what we will not claim, and what the client must provide for the engagement to work.

Owner: Lead consultant
Time: 2–4 days
Done when: The SOW is signed and the client obligations in it are acknowledged by name.

What the proposal must contain

The honest question from step 3, quoted in the sponsor's words
The standing metric set, with every speed metric shown beside its counter-metric
The J-curve, with its depth and duration stated as a forecast — typically a 15% dip over roughly 3 months
What the engagement cannot establish: no causal attribution from an observational design, named as a limitation rather than buried
Client obligations with dates: read-only access, a named data owner, survey distribution, and attendance at the five gate reviews
The handover condition: a named internal owner for measurement after we leave

Pre-commit the dip, in the proposal and again at kickoff

R03 — cancellation during the J-curve dip — is the highest-impact risk we carry, and it is almost entirely preventable with two sentences written before the dip happens. State the expected depth and duration. State which leading indicators you will report while outcome metrics are still down. A sponsor who has pre-committed to the dip will defend it internally for you.

Artefacts for this step

ROI model guideHow to build the value case, and which inputs finance will dispute
Proposal and SOW templateToolkit · 05-COMMERCIAL
Pricing and engagement modelsToolkit · 05-COMMERCIAL
Metric dictionaryPaste the exact definitions into the SOW, not paraphrases
Pitch deckToolkit · 06-DECKS — for the proposal meeting

On the value model

Build it with the client's own cost inputs, in front of them, and leave the spreadsheet with them. A model they watched you build and can change themselves is one finance will argue with productively. A model that arrives finished is one finance will reject wholesale — R13.

Signed. Now instantiate the method rather than a project plan.

Propose

Step 6 · Create the engagement in this workspace

Instantiate the method so the engagement is run against it rather than from memory.

Owner: Lead consultant
Time: 15 minutes
Done when: The engagement exists with 6 gates, 15 risks, 7 maturity domains and 20 metrics per team.

Clients → the client → create an engagement. Creating it seeds the gates G0 to G5, the fifteen-risk register, the seven maturity domains and, for each team you add, the twenty-metric standing set with counter-metrics already paired. You are not building a project plan; you are instantiating the method, which is why the seed is not editable at creation.

Record the objective verbatimThe engagement objective field takes the sponsor's sentence from step 3. If the readout does not answer this sentence, the engagement is not finished, and this field is how anyone can check.
Mark G0 passedWith the date and who countersigned.
Add the teams in scopeOne per wave. Each team gets its own metric set because each is measured against its own baseline — never a pooled average across teams.
Set the J-curve forecastDepth and months, matching what you wrote in the proposal. The engagement page then shows where you are against it.
Review the fifteen risksThey are seeded open. Close the ones that genuinely do not apply, with a reason. Raise the likelihood on the ones this client has already shown you — R01 if access took a month to discuss, R04 if a dashboard was mentioned twice.

Artefacts for this step

ClientsWhere you create the client and the engagement
EngagementsThe list, with gate progress per engagement
Maturity index rubricThe seven domains that were just seeded
Metric dictionaryThe twenty seeded metrics and their counter-metric pairs

The engagement exists. Now get to the data — this is the urgent one.

BaselineG1

Step 7 · Gate G1 — access

Get read-only access to the systems that hold the evidence, early enough that the baseline is not compressed.

Owner: Lead consultant, escalating weekly
Gate criteria: Read-only access to Git, CI/CD, incident and ticket systems confirmed working.
Done when: You have personally run a query against each system and seen rows come back.

Start this at signature, not at kickoff

R01 — access delayed beyond week 3 — has the highest combined likelihood and impact in the register, because it is the one failure that compresses every step after it. Request access the day the SOW is signed. Escalate weekly, in writing, to the sponsor. Three weeks of silence is not a delay to absorb; it is a gate to escalate.

Confirmed means you ran a query and saw data. An account that exists but returns nothing for the repositories in scope is not access. Check the date range too: a Git account that can only see the last 90 days cannot give you an eight-week pre-period if the tooling was activated four months ago.

Git provider: commit, PR, review and merge history for every repository in scope
CI/CD: build, test and deployment records with timestamps and outcomes
Incident tooling: incidents with severity, start, detection and resolution times
Ticket or work-tracking system: items with state transitions and timestamps
The AI tool's own telemetry, if any — diagnostic only, never an outcome metric
A named data owner on the client side who can answer a question within a day
Written confirmation that extraction is permitted, from whoever owns data governance

Artefacts for this step

Data access and security checklistToolkit · 02-ASSESS — the request wording, system by system
Telemetry contract templateToolkit · 01-METHOD — raise it now, sign it at step 10
Track 01 runbookThe extraction queries and the validation steps

If access stalls

Week 2, nothing granted

Escalate to the sponsor in writing, naming the systems and the owner for each. Restate the effect on the baseline window in dates, not in generalities.

Then: continue with the maturity assessment and interviews, which need no system access.

Week 3, still nothing

Escalate G1 formally. Put the engagement timeline revision in writing. This is what a gate is for.

Then: sponsor decides — extend, reduce scope, or pause.

A regulatory or privacy constraint blocks extraction

This is R12. Do not attempt a workaround. Move to aggregate-only extraction with the client's own team running the queries, and state the resulting limitation in every deliverable.

Then: revise the telemetry contract at step 10 to match what is actually possible.

Access confirmed. Now establish what was true before anything changed.

BaselineG2

Step 8 · Gate G2 — the baseline

Establish a validated pre-period that the client has signed off, before any intervention begins.

Owner: Lead consultant with the data analyst
Gate criteria: At least 8 weeks of data per team, extracted and validated.
Done when: The client has signed off the baseline figures as recognisable.

Eight weeks per team is the minimum, and it is a floor rather than a target — twelve is better, and anything under eight is reported as a weakness. Per team, not pooled: teams differ more from each other than most organisations expect, and a pooled baseline hides exactly the variation that makes the findings useful.

Validation, before you show anyone anything

Reconcile the totalsDeployment counts and incident counts against whatever the client already reports internally. If your numbers differ from theirs, find out why before the readout, not during it.
Check the activation dates per teamNot the licence purchase date — when that team actually started using the tooling. These differ by weeks, routinely, and the boundary sets the pre-period.
Look for the structural breaksA re-org, a tooling migration, a release-process change, a major incident, a holiday shutdown. Anything that moves a metric for reasons unrelated to AI adoption gets annotated now.
Have the client recognise their own numbersShow the baseline to an engineering manager who lives in that team. If they say "that lead time looks wrong", you have found a definition problem while it is still cheap.

When there is no recoverable baseline — R02

It happens, and the honest response is better than the clever one. Reconstruct a retrospective boundary from per-team activation dates, state in writing that the design is weaker as a result, and name that weakness in every deliverable including the executive summary. Do not quietly use a shorter window and present the result with the same confidence as a proper pre-period.

Artefacts for this step

Metric dictionaryThe exact definition for each of the twenty metrics — use these, not local variants
Measurement design and analysis guideToolkit · 01-METHOD — comparison design, confounders, how to report uncertainty
AI Value ScorecardToolkit · 04-MEASURE — the .xlsx. One copy per engagement; fill the baseline column now
Track 01 runbookExtraction and validation, step by step

The numbers exist. Now find out why they look like that.

Baseline

Step 9 · Maturity assessment, survey and interviews

Explain the numbers. The telemetry says what is happening; this step says why.

Owner: Lead consultant
Time: 2–3 weeks, overlapping the baseline extraction
Done when: Seven maturity domains scored with evidence, and survey response above 40%.

Run this in parallel with step 8, not after it. It needs no system access, which also makes it the work you continue with when access has stalled.

Illustrative only — a shape we see often. Measurement and value management (D6) is the limiting domain here, which is why the tooling investment in D1–D2 is not showing up as outcomes.

Instrument	Who	What it gives you
Maturity assessment	Engineering leadership, platform, QA	Seven domains scored 1–5 against the rubric, each with named evidence
Developer experience survey	Every engineer in scope	Perceived friction, trust in the tooling, and where time actually goes
Stakeholder interviews	6–10 people across roles	The explanations the survey cannot give you, and the things nobody writes down

Score the maturity rubric on evidence, not impressions

Every domain score needs a named artefact or observation behind it — a pipeline configuration, a policy document, a rota, something you saw. A score you cannot defend at the readout will be the one the client disputes, and they will be right to.

If survey response is low — R07

Below 40%

Extend by a week, have the sponsor re-send rather than you, and confirm to engineers in writing that responses are not individually identifiable. Most low response is a trust problem, not an attention problem.

Then: report the achieved rate alongside the findings, always.

Below 25%

Treat the survey as indicative only. Say so explicitly in the readout and lean on interviews and telemetry instead. Do not present a 20% response as representative because the numbers happen to be convenient.

Then: note it as a limitation in the evidence pack.

Artefacts for this step

Maturity index rubricThe seven domains and the 1–5 criteria
AI maturity assessment questionnaireToolkit · 02-ASSESS
Developer experience surveyToolkit · 02-ASSESS
Interview guidesToolkit · 02-ASSESS — by role
Role-based adoption playbookWhat good looks like per role, for scoring context

You know what you will measure. Now agree what it means and what it may not be used for.

BaselineG3

Step 10 · Gate G3 — the telemetry contract

Agree in writing what each metric means, who owns it, and what it may and may not be used for — before any number is published.

Owner: Lead consultant, signed by the sponsor and the data owner
Gate criteria: Metric definitions, owners, permitted and prohibited uses agreed and signed.
Done when: The signed contract is attached to the engagement in Files.

This is the most skipped gate and the most expensive one to skip. It is what you point at in month four when someone asks for a per-engineer view, and what prevents a metric being redefined mid-engagement in the direction that flatters the rollout.

What it must state

Each metric's exact definition, including the query boundary and what is excluded
The owner of each metric on the client side
Permitted uses: team-level trend reporting, engagement readouts, the quarterly review
Prohibited uses: individual performance assessment, team ranking, capacity planning, anything in an appraisal
The aggregation floor — no reporting on a unit smaller than a team, with a minimum team size
Who may see which view, and that the sponsor cannot request an individual breakdown
What happens to the data at the end of the engagement

The request that will come, and the answer

Someone will ask for per-engineer figures, usually informally and usually from a well-meaning sponsor who wants to help a struggling team. The answer: "The workspace has no individual-level data in it — there is no column for it, by design. Team-level is the smallest unit we report, and that is what makes engineers willing to answer the survey honestly." Then show them the signed contract. This is why you got it signed.

Artefacts for this step

Telemetry contract templateToolkit · 01-METHOD
Anti-gaming guardrailsHow each metric is gamed and the counter-metric that catches it
Metric dictionaryThe definitions to paste in — verbatim

Everything is measured and signed. Now tell them what is true.

Intervene

Step 11 · The findings readout

Tell the client what is true, including the parts they will not enjoy, and get agreement on what to change.

Owner: Lead consultant presents; a second attends
Time: 90 minutes, with the deck circulated 48 hours ahead
Done when: The sponsor has agreed the intervention list and the pilot teams.

How to structure it

First

The question, read back

Open with the sponsor's own sentence from step 3. Everything that follows answers it. This also stops the readout drifting into a tour of the data.

Then

What the baseline shows

Per team, with counter-metrics beside every speed metric. Flag the structural breaks you annotated at step 8.

Then

What the maturity read shows

Lead with the limiting domain. The lowest score is the one capping the others, and it is usually not the one leadership expected.

Then

Where the time actually goes

The lead-time decomposition. In most engagements review wait dominates, which reframes the problem from "write code faster" to "unblock review" — and that is the finding that changes what the client does on Monday.

Then

What we cannot establish

Say it out loud rather than leaving it in an appendix. An observational design cannot prove causation. Saying so is what makes the rest credible.

Last

The intervention list

Three to five changes, each with an owner, a pilot team, and the metric it should move — plus the counter-metric that must not move.

Illustrative lead-time decomposition, percent of elapsed time. Writing the change — the part AI tooling accelerates — is rarely where the time goes. This single chart reframes more engagements than any other.

If the findings are politically unwelcome — R08

The pressure to soften arrives as a request to "reframe for the audience". Reframe the language as much as you like; do not reframe the finding. Keep the number, keep the uncertainty, change the words. If you are asked to remove a finding, say that you will note the disagreement in the evidence pack rather than remove the result — which is usually enough to end the request.

Artefacts for this step

Findings readout deckToolkit · 06-DECKS — the structure above, as slides
Measurement design and analysis guideToolkit · 01-METHOD — how to report uncertainty honestly
Executive scorecard dashboardToolkit · 04-MEASURE — the one-page view for the sponsor
Objection handling and FAQFor the readout questions you can predict
Export the engagement metricsFrom the engagement page, to build the deck from live data

The interventions are agreed. Now make them real.

InterveneG4

Step 12 · Gate G4 — changes live

Get the agreed interventions actually running with pilot teams, with guardrails in place.

Owner: Lead consultant with the client's named owners
Gate criteria: Playbooks and guardrails live with at least two pilot teams; interventions logged.
Done when: Each intervention has a start date, an owner and a logged entry in the workspace.

Two pilot teams is the minimum, because one team cannot tell you whether a result generalises — R11. Log every intervention with its start date as you go. At step 13 you will need to know which change preceded which movement, and reconstructing that from memory is how engagements lose their evidence.

Watch for the quality trade — R06

Review latency improving while review depth collapses is the most common false win in this work, and it looks like success on every dashboard. The counter-metric pairing exists to catch exactly this. Check M-05 against M-07 every fortnight, not just at the readout.

Two things that commonly go wrong here

Embedded engineers get absorbed into BAU delivery — R09

Agree protected time in writing with the engineering manager, not just the sponsor, and report the actual time spent at each gate review. This is a resourcing problem that presents as a motivation problem.

Then: raise it at the next gate review if it persists past two weeks.

Metric gaming once the scorecard is visible — R05

Review anomalies before publication, never after. A metric that improves implausibly fast is a definition problem or a gaming problem, and either way publishing it first makes it much harder to walk back.

Then: see the anti-gaming guardrails for the specific checks per metric.

Artefacts for this step

Role-based adoption playbookWhat to change, by role
Track 01 runbookMeasurement-led engagement
Track 02 runbookCapability-led engagement
Workshop facilitationFor the enablement sessions
Anti-gaming guardrailsThe fortnightly checks
Workshop packToolkit · 03-DELIVER — slides and exercises

Changes have been live for eight weeks. Now measure again, the same way.

Prove

Step 13 · Measure again, and report the delta honestly

Produce the after-period and report the change with its uncertainty and its confounders.

Owner: Lead consultant with the data analyst
Time: 8 weeks minimum after the interventions went live
Done when: The scorecard is populated and every figure traces to a version-controlled query.

Same definitions, same queries, same boundaries as the baseline. If a definition had to change, report both the old and the new and say why. A definition that changed quietly between the before and the after is not a finding; it is a mistake that happens to look like one.

Where the engagement should be on the curve by now. If you are still in the trough, report leading indicators and say so.

Every speed metric reported with its counter-metric, in the same view
Uncertainty stated — ranges, not single points presented as precision
Confounders named: re-orgs, migrations, seasonality, headcount changes
Per team, with the variation visible rather than averaged away
Survey re-run, with both response rates shown
Maturity re-scored for the second round, against the same rubric and the same evidence standard
Every figure traceable to a query that someone else could re-run

If the result is flat or negative

Report it. A clean negative result, honestly reported, is more valuable to a sponsor deciding on a renewal than a flattering number they cannot defend to their board — and it is the engagement that earns the next one. The evidence register exists so that we can say "the strongest trial evidence available includes a 19% slowdown" without flinching.

Artefacts for this step

AI Value ScorecardToolkit · 04-MEASURE — the populated .xlsx, baseline and after columns
Measurement design and analysis guideToolkit · 01-METHOD
ROI model guideTurning the delta into a value figure finance will accept
Evidence registerWhat each external source does and does not support

You have a result. Now make sure it outlives you.

ProveG5

Step 14 · Gate G5 — proof and handover

Leave the client able to keep measuring without us.

Owner: Lead consultant
Gate criteria: Scorecard populated, deltas reported with uncertainty, named internal owner in place.
Done when: A named client person has run the measurement cycle once, themselves, while we watched.

Handover is not a document; it is a person who has done it once. R15 — measurement dies after handover — is the risk that quietly undoes the entire engagement six months later, and the only reliable mitigation is watching someone else complete a full cycle before you leave.

Name the ownerA person, not a team or a role. Confirmed by the sponsor, in writing.
Hand over the queriesVersion-controlled, documented, and runnable by them without us.
Watch them run one cycleThey extract, they populate the scorecard, they produce the view. You observe and answer questions. This is the step people skip and the reason handovers fail.
Agree the cadenceMonthly extraction, quarterly review. Diarised, with the first two dates in calendars before you leave.
Write the evidence packEvery figure in the final deliverable, with its query, its date range and its caveats. This is what makes the case study usable later, and what protects the claim when someone challenges it in a year.
Book the first QBRBefore the engagement formally closes. A review that is not in a calendar does not happen.

Artefacts for this step

Quarterly review guideHow to run the review after we leave
QBR deckToolkit · 06-DECKS
Case study template and evidence packToolkit · 05-COMMERCIAL
Claims substantiation sheetToolkit · 00-START-HERE — every published number and its status
Share a read-only engagement linkA signed link, expiring in 30 days, for a sponsor who wants the live view

The engagement is closed. Now make the practice better at the next one.

Prove

Step 15 · After the engagement

Convert one engagement into something the practice knows.

Owner: Lead consultant, within two weeks of close
Done when: The case study is drafted with its evidence pack, and this playbook has been updated or explicitly left alone.

Draft the case study with its evidence pack, while the detail is still accurate. A case study without an evidence pack is a claim we cannot publish.
Add any new external evidence you relied on to the evidence register, with what it does and does not support.
Update the claims substantiation sheet if the engagement produced a number we now want to publish.
Record what this engagement taught us: a risk that should be seeded, a metric definition that needed changing, a step in this playbook that did not survive contact with reality.
Hold the first QBR on the date you booked at step 14.

This playbook is expected to change

It is a method that has met a limited number of real engagements. Where it was wrong, say so and change it — with the reason recorded, so the next person knows why the step reads the way it does. A playbook nobody edits is one nobody is really using.

Quick reference

Which artefact at which step

The toolkit mapped onto the journey. If you are at a step and wondering what to open, find the column and read down it.

Colour marks the phase each instrument belongs to. The metric dictionary appears four times — it is the document that keeps the proposal, the baseline, the contract and the final deltas talking about the same thing.

The six gates

Gate	Name	Cannot be passed without
G0	Qualify	Sponsor named, systems known, the honest question in writing
G1	Access	Read-only access confirmed working by you, personally
G2	Baseline signed off	8+ weeks per team, validated, recognised by the client
G3	Telemetry contract	Definitions, owners, permitted and prohibited uses, signed
G4	Changes live	Two or more pilot teams, guardrails in place, interventions logged
G5	Proof and handover	Scorecard populated, uncertainty reported, named owner has run a cycle

The risks most likely to bite, and where they start

Risk	What it is	The step that prevents it
R01	Access delayed beyond week 3	Step 7 — request at signature, escalate weekly
R02	No recoverable pre-adoption baseline	Step 1 — the enquiry score flags it; step 8 handles it honestly
R03	Cancelled during the J-curve dip	Step 5 — pre-commit the dip in the proposal
R04	Sponsor wants a usage dashboard as the deliverable	Step 3 — reframe on the discovery call
R05	Metric gaming once the scorecard is visible	Step 10 — the contract; step 12 — the fortnightly checks
R06	Review quality degrades while latency improves	Step 12 — counter-metric pairing, checked fortnightly
R07	Survey response below 40%	Step 9 — sponsor re-sends, confidentiality restated
R08	Findings softened under pressure	Step 11 — change the words, never the finding
R15	Measurement dies after handover	Step 14 — a named person runs a full cycle while you watch

If you only remember six things

Measure before you change anything, and say so plainly when you could not.
Every speed metric travels with its counter-metric. Always, in the same view.
No individual-level data, to anyone, ever.
Name the J-curve before it happens, in writing.
A gate is passed or escalated, never absorbed.
Handover is a person who has done it once, not a document.

The client wants to start before access is confirmed. Can we?

You can start step 9 — the maturity assessment, survey and interviews need no system access. You cannot start step 12. Intervening before a baseline exists destroys the evidence the engagement is being paid to produce, and no amount of goodwill recovers it afterwards.

They will not sign the telemetry contract. Is it really a blocker?

Yes. G3 is a gate. Without it, metric definitions drift towards whatever flatters the rollout, and you have nothing to point at when someone asks for a per-engineer view. If there is a specific clause they object to, negotiate the clause — not the existence of the contract.

Can we pool metrics across teams to make the numbers cleaner?

No. Teams vary more than organisations expect, and the variation is usually the most useful finding in the engagement. Pooling hides it and makes the result fragile the moment someone drills in.

The result is flat. What do we actually put in the readout?

The flat result, its uncertainty, and the confounders. Then what the maturity read and the lead-time decomposition say about why — which is where the actionable finding almost always is. A flat outcome with a clear explanation is a good engagement.

How much of this applies to Track 02?

All of it. Track 02 compresses steps 7 to 10 and spends longer in step 12, but the gates and their criteria are identical. Measurement is not the part you drop when the engagement is capability-led — it is how you show the capability landed.

Where do client deliverables live?

In the engagement's Files tab, not in the library. The library holds the templates; the Files tab holds the instances for one client. Uploads there are access-checked, so a sponsor with a share link sees only their own engagement.

Every document in the library

The Field GuideThe method in full
Metric dictionaryAll 34 metric definitions
AI maturity index rubricSeven domains, 1–5 criteria
Anti-gaming guardrailsPer-metric gaming modes and counters
Track 01 runbookMeasurement-led engagement
Track 02 runbookCapability-led engagement
Role-based adoption playbookWhat changes, by role
ROI model guideThe value case and its disputed inputs
Discovery and qualificationQuestion bank and scoring
Objection handling and FAQThe hard conversations, scripted
Workshop facilitationRunning the enablement sessions
Quarterly review guideLife after handover
Evidence registerEvery external claim and its limits

Sources