Best-Practice Sharing at Scale: Transfer Readiness Brief

Candidate practice card: record what is actually known

Do not begin with the person or team described as best. Begin with a work problem and a practice that responsible people have chosen to examine. Link to the approved source instead of copying a private conversation into the transfer file.

• Work problem: the task, handoff or decision the practice is meant to support.
• Candidate practice: the observable steps and decision points, without promotional language.
• Source and permission: approved record, version, owner and permitted reuse.
• Observed result: what changed, for which population and period, kept separate from any causal explanation.
• Conditions: skills, tools, access, staffing, timing and support present in the source setting.
• Boundaries: exceptions, prohibited uses and the route for work outside the practice.
• Evidence status: described, checked locally, compared or still uncertain. Do not call a practice proven when the design cannot support that conclusion.

Source-to-receiver comparison: find the differences that matter

Complete this comparison with the source owner and receiving owner. Similar job titles do not establish similar work. Ask the receiving team to identify differences before showing a finished asset, so the central version does not anchor every local decision.

• Trigger and outcome: does the receiving team face the same work problem, and what would a useful result mean there?
• People and authority: who performs the step, who may decide, and who handles an exception?
• Workflow and volume: what happens immediately before and after the practice, at normal and peak demand?
• Tools and access: are the same fields, systems, devices and permissions available?
• Working conditions: what paid time, shift overlap, location or supervisor support is required?
• Language and terminology: which terms need local review without changing the operational meaning?
• Controls: which safety, privacy, employee-relations or customer requirements differ?
• Counterexample: in which receiving-team situation would the source practice be unsuitable?

Transfer hypothesis: fix the core and expose adaptations

Write one sentence: for this receiving group, using these steps in this situation is expected to change this observable part of the work because of this stated mechanism. Label it as a hypothesis. Then split the proposed practice into the core to preserve, local adaptations to test and unresolved questions. The source owner checks fidelity to the original account; the receiving owner decides operational fit. A local subject, safety, privacy or employee-relations reviewer joins when the practice enters that person’s remit.

• Core: the steps or decision rule that define the candidate practice.
• Adaptable: examples, terminology, sequence or delivery support that may change locally.
• Prerequisites: access, skill, time, data and owner that must exist before the test.
• Open question: a difference that the test can examine without hiding the uncertainty.
• Do-not-transfer element: a source detail that is irrelevant, restricted or unsafe in the receiving setting.

Bounded test card: decide before wider use

Choose the smallest test that still exercises the real work. Do not ask people to perform unpaid practice or bypass an approved system. A process check shows whether the practice reached the work as intended. An outcome check shows what happened next. Neither by itself proves that the practice caused the result.

• Receiving population and eligible work cases.
• Test start, end and responsible receiving owner.
• Briefing, practice opportunity and support available within working time.
• Baseline or comparison that is proportionate to the decision, with known differences recorded.
• Implementation check: whether the core steps were available and used as intended.
• Outcome check: the defined work result, plus quality, workload or access side effects.
• Feedback route: how participants can report a missing condition, misleading step or adverse effect.
• Decision rule: continue, adapt, stop or gather specified evidence, with a date and owner.

Withdrawal and record: keep scale reversible

Agree withdrawal before release. Name who can pause the test, where the active version lives and how participants will learn that it has changed. If the practice is stopped, remove or mark the obsolete material in every controlled channel, preserve the reason and return to the previous approved process where one exists. If it continues, record the receiving context and local changes rather than silently replacing the source version. A later team should be able to see what was tested, what was observed and what remains uncertain. A pilot may need a small draft aid: label it for the test audience and obtain the necessary source and local review before use. Use the transfer decision to scope wider production or adaptation; if testing exposes a missing instruction, return to the relevant brief rather than treating the stages as a one-way sequence.

Why this guide is useful

Use this original worksheet after a possible practice has been captured and reviewed, but before commissioning a learning asset or rolling it out. It decides whether a receiving team has enough fit, permission and capacity to test the practice. Knowledge capture, content production, localisation and use during a shift each have their own checks; use the linked resources when those jobs are needed.

Treat transfer as a test of fit, not a ranking

HM Treasury’s 2026 Magenta Book recommends building evaluation into an intervention early, testing assumptions before expansion and distinguishing implementation evidence from impact evidence. The CDC’s 2024 Program Evaluation Framework similarly asks evaluators to describe required skills, duration, setting and participant characteristics. This worksheet adapts those principles to an internal practice transfer. A good result in the source team makes the practice a candidate to test elsewhere; it does not establish why the result occurred or guarantee that it will travel.

Concrete example

Fictional example: a Manchester service desk proposes transferring an end-of-shift exception card to a US team. The source owner explains that it records the case owner, next action and escalation condition. The source team saw fewer reopened cases after introducing it, but staffing and queue rules changed at the same time, so the card is not labelled the cause. The receiving owner finds that the US workflow uses a different escalation route and has no overlap between two shifts. The teams keep the three required fields, replace the escalation term and arrange the test inside paid working time for the next set of eligible handovers. They check whether the card was completed as intended, whether the next colleague could act, and whether sensitive customer details were copied. The pre-agreed rule is to stop the test if the card conflicts with the approved case system or extends work beyond the scheduled shift. At review, they may continue, adapt or withdraw it. Even a better result would remain evidence from this bounded test, not proof that the card caused the change everywhere.

Sources

• HM Treasury: Magenta Book, 2026
• CDC: Program Evaluation Framework, 2024