Would you scale a well-used engineering tool?
Teams use the new assistant. Total work has not yet fallen.
The question
Morrow has piloted an AI migration assistant with one team. The sponsor wants to roll it out to every team. You must explain whether the pilot supports that commitment. The company and all data are invented; this is not a measured AI benchmark.
| Before: hours | Pilot: hours | |
|---|---|---|
| First implementation | 40 | 24 |
| Review and rework | 12 | 22 |
| Support and enablement | 4 | 12 |
The task mix is fixed in this authored packet. The totals are 56 hours before and 58 in the pilot. This comparison is not a causal study.
“Choose whether to scale, narrow or stop the rollout and define the next evidence.”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: First implementation falls from 40 to 24 hours. What do you tell the sponsor?
What would you do here? Open the move you’d make.
Announce sixteen hours saved each week
Tempting, but it misses something. Review, rework and support rise by eighteen hours in the same packet.
Report the whole workflow and ask which costs recur
The strong move. This makes the next decision depend on the team outcome rather than use alone.
Ban the tool because any pilot overhead is failure
Tempting, but it misses something. Some enablement can be temporary; the packet does not yet separate it.
See how a strong candidate says it
“Implementation is faster in this packet, but total weekly work rises from 56 to 58 hours. I would not claim a team productivity gain from the 16 implementation hours alone. I would separate ongoing work from one-time enablement.”
Why it works: The decision concerns the whole team workflow, including costs moved to reviewers and support.
Step 2: New fact: 8 of the 12 support hours are one-time training. What remains unresolved?
What would you do here? Open the move you’d make.
Scale to all teams now because the projection is positive
Tempting, but it misses something. The six-hour benefit is a projection for one task mix, not an observed result for all teams.
Keep reporting a two-hour loss forever
Tempting, but it misses something. This ignores the new evidence that eight support hours are one-time.
Test the projected steady state with the pilot owner
The strong move. The new estimate is useful if its assumptions and remaining review work are explicit.
See how a strong candidate says it
“If the training ends, the ongoing total would be 50 hours for this fixed task mix. That is a possible six-hour benefit, not yet an observed steady state. Review and rework still need a clear owner and quality check.”
Why it works: Removing a one-time cost changes the decision, but the assumed steady state must still occur.
Step 3: New fact: two repeat weeks total 50 hours. Another team has no repeated migration work. How do you scale?
What would you do here? Open the move you’d make.
Target teams with the same work pattern and capacity
The strong move. This extends the evidence without pretending every team has the same benefit.
Require every team to hit a usage target
Tempting, but it misses something. Usage would become the objective, including teams with no matching task.
Stop the successful pilot because one team cannot benefit
Tempting, but it misses something. The unrelated team does not invalidate the observed result for the pilot pattern.
See how a strong candidate says it
“Expand to teams with the tested task pattern and accepted review capacity. Do not require the unrelated team to adopt. State the boundary and compare its outcome before extending the scope again.”
Why it works: A useful result in one work pattern need not generalize to a different team.
Step 4: New fact: the next cohort saves implementation time but doubles escaped contract defects. What is your action?
What would you do here? Open the move you’d make.
Keep expanding because the first pilot succeeded
Tempting, but it misses something. The next cohort has a material quality problem that the first pilot did not show.
Pause the failing cohort and investigate its contract defects
The strong move. This responds to the new evidence without discarding unrelated supported work.
Publish a higher usage target
Tempting, but it misses something. More activity does not repair escaped contract defects.
See how a strong candidate says it
“Stop expansion for that cohort and review the defects with its contract owner. Preserve the proven pilot scope only if its evidence still holds. A speed benefit cannot silently spend another team’s quality budget.”
Why it works: The new outcome changes the expansion decision even if usage remains high.
The answer, in short
- Decision
- Scale by supported work pattern, with review and quality ownership.
- Because
- The pilot’s steady-state benefit is specific; the next cohort can still fail.
- What would change it
- Recurring support costs, contract defects or a different task mix reopen the expansion.
Common traps
- Calling tool usage a business outcome
- Removing projected costs before observing the change
- Transferring pilot results to unrelated teams
Check your answer
- Did I include work moved to other teams?
- Did I separate observed and projected costs?
- Did I define the supported work pattern?
- Did I respond to the new quality evidence?
Last reviewed Nov 10, 2026