From lab to operations: the handover nobody plans

Most lab pilots do not fail in the lab. They fail in the three months after, when the people who built them step back and the people who must run them were never really asked. A good handover starts on the first day of the pilot, names one receiving owner in operations, and transfers four things: the decision, the budget line, the know-how and the measures. If any one of them is missing, the pilot quietly returns to the lab or disappears.

Why the handover is where good pilots die

A lab is built to be different from operations. It moves faster, tolerates ambiguity, borrows people and works around standard processes. That is exactly why it can test new ideas. It is also why its outputs rarely fit the machine that has to run them.

Vijay Govindarajan and Chris Trimble describe this tension in The Other Side of Innovation (2010): the "performance engine" that runs today's business is designed for repeatability, and innovation work needs a partnership with it rather than a wall between them. Labs that treat operations as the audience for a final demo, rather than as a partner from the start, set up the handover to fail.

The usual symptoms are familiar:

• The pilot "worked", but nobody in operations agreed what "worked" meant.
• The lab team was the only team that understood how it ran.
• There was money for the pilot and no line in next year's operating budget.
• The receiving manager inherited a new service on top of existing targets, with nothing taken away.

Step-by-step: planning the handover from day one

1. Name the receiving owner before the pilot starts

Before you spend a week on the pilot, find the person in operations who will own the result if it succeeds. Not a sponsor who likes the idea; the manager whose team will run it on an ordinary Tuesday. Ask them directly: "If this works, will you run it?" If the answer is "maybe", treat that as a finding. A pilot with no receiving owner is a research project, and it should be scoped and reported as one.

2. Agree the success test with the receiver, in writing

Write down, with the receiving owner, what result would make them take it on. Keep it to two or three measures they already care about: cycle time, error rate, cost per case, complaints. A KPI tree helps connect the pilot's measure to the targets the receiver is judged on. If the lab's success test and the receiver's success test differ, the receiver's wins.

3. Put an operations person inside the pilot team

One person from the receiving team should work in the pilot, part-time at least, from the start. They catch the rules, systems and habits the lab would otherwise miss, and they carry the know-how home. This single decision does more for handover than any document.

4. Map the future service, not just the pilot

Pilots run on workarounds: a lab member answering emails by hand, a spreadsheet instead of a system, a manager approving exceptions personally. Before the decision to scale, draw a service blueprint of how the service will run without the lab: every frontstage step, every backstage step, every system and policy it depends on. The gaps you find are your handover work plan.

5. Run a premortem on the handover itself

Gather the lab team and the receiving team and ask: "It is six months after handover and the service has been quietly switched off. What happened?" A premortem surfaces the real risks: a vendor contract that ends, a policy that was never changed, a team that lost its headcount. Assign each risk to someone.

6. Write the RACI for the transition period

For each activity in the blueprint, decide who is responsible, accountable, consulted and informed: during the pilot, during the transition, and after. A RACI for three time periods makes the shift of ownership visible. The lab should be accountable for less every month.

7. Secure the budget line before you celebrate

A pilot funded from the lab's budget has no future unless someone moves it into an operating budget. Work with finance early: what will it cost to run at scale, from which line, starting when? If the budget cycle closes before the pilot ends, request a provisional line based on the success test.

8. Hand over with a checklist and a date

Use a rollout checklist that covers people trained, procedures written, systems configured, policies changed, support arranged and measures in place. Set a handover date and announce it with a stakeholder communication plan so staff, customers and leaders know who now owns the service.

9. Stay on call, then step away

Agree a fixed period, often one or two cycles of the service, when the lab remains available for questions. After that, the lab stops attending. If the service cannot run without the lab, it was not handed over.

What actually transfers

It helps to name the four things that must move, because labs often transfer only one.

Check each line before the handover date. A pilot that has moved three out of four is still a lab pilot.

Illustrative example

Illustrative. A city transport authority's lab tested a new process for handling accessibility complaints. In the pilot, two lab designers triaged complaints by hand and called back every complainant within 48 hours. Satisfaction rose and the pilot was declared a success.

When the lab presented the results, the customer service director asked who would make the calls. Her team had no budget for it and the complaints system could not flag accessibility cases. The pilot stalled for five months.

The lab restarted with the director as receiving owner. A senior agent joined the team for six weeks. Together they drew a blueprint that replaced manual triage with a new category in the existing system, agreed a 72-hour callback the team could actually sustain, and moved the cost into the service budget for the next year. The lab stayed on call for one quarter, then stepped away. The 72-hour target was less impressive than the pilot. It also survived.

Do's and don'ts

Do

• Name the receiving owner before the pilot starts.
• Let the receiver define success in their own measures.
• Embed one operations person in the pilot team.
• Design the scaled version without lab workarounds.
• Set a date when the lab stops attending.

Don't

• Present a finished pilot to operations as a surprise.
• Hand over a slide deck and call it a transfer.
• Measure success only on lab metrics such as "ideas tested".
• Add a new service to a team's work without removing something else; a stop doing list helps here.
• Keep the lab as the permanent owner "just for now".

Questions people ask

When should a lab hand over a pilot to operations? When the receiving owner's success test is met and the four transfers (decision, budget, know-how, measures) can all be completed. Planning starts at the beginning of the pilot; the handover itself happens when the scaled version can run without lab people.

Who should own an innovation after the pilot? The manager whose team will run it daily, not the sponsor and not the lab. If no such person will take it on, the pilot should be stopped or redesigned, which is a legitimate outcome. See how to stop a project well.

Why do successful pilots fail to scale? Usually because pilots run on workarounds and borrowed attention that do not exist at scale, and because no one moved the running cost into an operating budget. The fix is to design the scaled version during the pilot, not after it.

Where to go next

For the wider picture, read what an innovation lab is, and why most fail and 5 reasons innovation labs get closed in year two; a lab that hands nothing over rarely survives its second budget. The method guides that carry most of the handover are the service blueprint, the RACI, the premortem and the rollout checklist.