This article is part of the OpsCorp method library. To see where your program stands across all nine planning dimensions, take the scorecard.

Every Artifact Is in the Shared Drive. Nobody Can Use Them.

Capability Transfer: Three Levels of Handoff

The planning engagement produced a complete set of artifacts. The integrated roadmap with dependencies and milestone sequences. The operating model with governance, cadence, and role definitions. The risk register with assessed risks and mitigation plans. The change plan with audience maps and communication design. The rollout plan with waves, criteria, and learning agendas. Every artifact is in the folder. Every template is complete. The team has access. Three months later, the roadmap hasn’t been updated since the consultants left. The operating rhythm has degraded from weekly to ad hoc. The risk register is stale. The change plan sits unused. The team has the artifacts but not the capability to operate them. This is the document-dump trap: confusing access with capability. Having the files is necessary. Knowing how to use them is what matters. The Capability Transfer sub-artifact exists to close this gap systematically.

Why Documents Don’t Transfer Capability

Artifacts are tools. Like any tool, they require skill to operate. The integrated roadmap isn’t a static timeline. It’s a dynamic model that needs updating when dependencies shift, milestones move, and new information arrives. Updating it requires understanding the methodology: how dependencies are tracked, how sequencing logic works, and how to recalculate the critical path when conditions change. The operating model defines cadences and governance. Running the cadences requires facilitation skills. Knowing when to escalate a decision requires judgment about the governance framework. Maintaining the model as the program evolves requires understanding what’s essential structure versus what’s adaptable detail. The risk register needs ongoing maintenance. New risks need to be identified, assessed, and added. Existing risks need to be updated as conditions change. The assessment methodology, the criteria for severity and likelihood, needs to be understood by the person maintaining the register, not just the person who created it. In each case, the consulting team that built the artifacts had two things the receiving team doesn’t: the methodology behind the tool and the practice of using it. Handing over the artifact without transferring both is like handing someone a musical instrument without lessons.

The Three Levels of Transfer

Capability transfer operates on three levels, and most handoffs only complete the first. Level 1: Documentation. The artifact exists, is clearly written, and is accessible. This is the minimum. It’s also where most handoffs stop. The team has the documents. The handoff is declared complete. Level 2: Training. The receiving team has been walked through the artifact, understands its structure, and knows how it’s supposed to be used. This is better than Level 1 but still insufficient. Understanding how something works in theory is different from being able to operate it in practice. Level 3: Practice. The receiving team has actually used the artifact under realistic conditions. They’ve updated the roadmap when a dependency shifted. They’ve facilitated a governance meeting using the operating model. They’ve added a new risk to the register and assessed it. They’ve done the work, ideally while the consulting team was still available to coach them. Level 3 is where capability transfer becomes real. The test is not whether the team can describe how the artifact works. It’s whether the team can operate it independently.

What Practice Looks Like for Each Artifact

For the integrated roadmap: the receiving team should update at least one dependency and resequence at least one milestone while the consulting team is available to guide and correct. They should practice the process of evaluating a change, identifying downstream impacts, and updating the document. For the operating model: the receiving team should facilitate at least one governance meeting and run at least one decision escalation process while the consulting team observes. They should experience the awkward moments, the unclear decisions, the messy discussions, and build the judgment for handling them. For the risk register: the receiving team should add at least two new risks, assess them using the established methodology, and propose mitigation plans. They should practice distinguishing between risks that need escalation and risks that can be managed within the existing plan. For the change plan: the receiving team should design at least one communication cycle using the audience map, change inventory, and messenger selection framework. They should practice the process of translating the plan into specific actions. For the rollout plan: the receiving team should evaluate at least one set of wave success criteria and practice the go/no-go decision process. They should experience the tension between evidence and momentum and build the discipline to make evidence-based calls.

The Ownership Assignment

Capability transfer requires named owners. Each artifact and process needs a specific person who is responsible for maintaining it, using it, and evolving it. The ownership assignment captures:

  • The artifact or process. What’s being owned.
  • The owner. Who is responsible. A named individual, not a team.
  • The backup. Who covers when the owner is unavailable.
  • The maintenance cadence. How often the artifact is reviewed and updated.
  • The support plan. What happens when the owner encounters a situation the training didn’t cover.

The support plan is critical and often missing. It connects directly to the Operating System Handoff, which defines how the program’s operating cadences transfer to the internal team. Even after Level 3 practice, the receiving team will encounter situations they haven’t seen. The first six months of independent operation will produce questions. The Close Package should define how those questions get answered: a retained advisor, a knowledge base, an office hours session, or a named contact who can help.

How to Close the Gap from Where You Are

Programs at this stage have completed Level 1 (documentation) and possibly Level 2 (training). The gap is Level 3 (practice). If the consulting team is still engaged, schedule practice sessions for each artifact. Allocate time for the receiving team to operate the tools under guidance. This is the highest-value activity in the final weeks of an engagement and the one most often cut when timelines are tight. If the consulting team has already left, simulate the practice. Assign each artifact to its owner. Have the owner update it within the first two weeks while the context is fresh. Document every question that arises. The questions reveal the capability gaps that need to be closed. Then address ownership. If nobody is specifically assigned to each artifact, nobody will maintain it. The assignment should be visible, agreed to, and supported with time allocation. The question is whether the organization closes the gap between access and capability before execution begins: or whether the artifacts sit in the folder while the team rebuilds from scratch.


Keep Reading

New to the Close Package? Start with the foundations:

Ready to benchmark your work against best-in-class? See what excellence looks like: