Plan for the transition

Partners will need to handle the entire gamut of activities associated with product delivery once we disengage. They need to own the product vision, support users of the system, deliver product updates by themselves, develop a plan for product dependencies like infrastructure, ATO, and third party integrations, and understand how to hire and manage agile-oriented vendors. The entire team should be thinking about the transition from the start, with a more concerted effort to identify and address gaps as you get closer to disengaging. If the partner will be hiring a vendor, the team should advocate as early as possible for the people and resources critical to success as the agreements process typically takes 3-6 months to execute. Work with your team to develop a plan to transition ownership fully to the partner, and identify transition risks and actions to mitigate them.

Considerations: What it looks like when this is done well

The project team and their stakeholders understand and can explain the vision for the product, its current state, the decisions and tradeoffs that have been intentionally made, and the work needed to further develop the product.
The project team is demonstrating an independent commitment to agile, outcome-oriented practices, and are not just doing agile ceremonies in name only.
The team is able to practice DevSecOps, and work that is secure and meets the team’s definition of done is able to be continuously released each sprint.
All artifacts, code, tooling, and infrastructure are transferred to the partner and no longer reliant on 18F accounts.
The partner has a long-term staffing strategy to appropriately support and staff the product when the 18F team leaves, either with people internal to the partner organization or with contractors/vendors.
If the partner is working with a vendor, they have established trust between the parties and good working practices to oversee and manage the vendor’s work.

Activities: How to get there

Transitions are the responsibility of the entire team, and you should work together to plan and divide up work based on individual areas of expertise.

Include a plan in the roadmap to transition ownership over to the partner. Start the process of planning and skill building within the first 2-4 weeks, and get more concrete and tactical as you approach the end of the engagement.
Include specific target outcomes and appropriate metrics for the transition related to iterative development, human-centered design and research, continuous deployment to end users, working with stakeholders, and technical leadership.
Assist your partner in developing a staffing plan, for example by providing a skills gap analysis, sample role descriptions, and hiring support if/as needed.
Plan to transition code and assets to accounts the partner has access to.
Regularly check in with the product owner about how ready they feel to take over.
Document project/product history and major milestones/developments.

Incorporation: What to do next

Consider if your partner would benefit from ongoing lightweight support to solidify their new practices and work through challenges that arise post-engagement.

Resources

18F only, Approach to transformation: A description of how we intentionally transfer our practices as part of our work with agencies.
18F only, Transition goals: A framework you can use to assess the partner’s current digital maturity or readiness and develop transition goals (alternative formats 18F only, here and 18F only, here).
18F only, Transition planning: A collection of transition plans from prior engagements.
18F only, Cross-functional team management: A detailed outline of what a partner should look for to determine what is working well on their cross-functional team (internal or vendor) and what could use improvement.
18F only, Validating the path to production: How to test an agency's ability to host and deploy prior to a contractor starting.
18F only, Project closeout: A checklist of tasks that need to be completed once an engagement ends.