Project handoffs are not simple. Teams have their own cultures and work styles. Without planning, a project could lose institutional memory, time, quality, and funding when it passes from one team to the next.
Last year USAGov received a benefit locator as an MVP (minimum viable product) from 10x, GSA’s crowdsource incubator. By planning with 10x, and preparing for the eventuality of the transition between teams, we were all able to mitigate many of the risks involved in a product handoff. Here are 6 lessons we learned as the benefit locator project changed hands:
1. Time the entrance
It’s important to schedule your handoff window in advance so the incoming and outgoing teams can prepare for the off- and onboarding.
A lot of planning went into the benefit locator handoff and the actions that had to come before it. From the start, 10x's goal was to develop the locator only as far as an MVP and then pass it to our USAGov team for further development and scaling. Knowing this ahead of time prepared both teams for the shift. They were able to define critical considerations like the statement of work for the new team, the funding requirements, and the necessary approvals.
It’s important too for both teams to be realistic when setting schedule expectations. For example, if an outgoing team doesn’t have enough time to complete the established requirements for turnover, the incoming team might have extra work to do. This can add undue pressure, rush the onboarding process, and lose time.
2. Anticipate time lags
Because of the duration of the procurement process, there was a gap of about five months from the time 10x completed the MVP to the time USAGov's product manager arrived and began the new team's onboarding. The 10x and USAGov teams anticipated this gap and allocated 10x's time and resources at a minimum to focus on maintenance and service rather than active development during this time.
Having a stable MVP in place during this period allowed the public to use a functioning product while the transition and onboarding took place.
3. Pace and stagger the onboarding
10x built a small but robust product with a lean and experienced team, but scaling that product required the new team to grow accordingly.
Pacing and staggering onboarding worked well for the inbound team. The USAGov team was able to ramp up the work gradually, onboarding contractors in several small groups. This provided an opportunity to create a repeatable onboarding cycle, which helped the team connect and settle into their work. It also helped avoid the chaos and disorganization that can sometimes follow large-scale onboarding efforts.
4. Establish a culture of documenting
The 10x and USAGov teams developed a culture of documenting work throughout the product's lifecycle. The 10x team documented the benefit locator’s creation and its progress through the 10x program's four-phase research and development process. This helped USAGov’s team lead, members, and stakeholders know how the locator began and grew. And it gave us an understanding of how to continue building the product.
The 10x team recognized that their documentation fit their specific work culture. When the time came for the handoff, they prepared and reframed the information so it would be more accessible for our incoming USAGov team. 10x created a centralized ‘shortcut document’ with links to about 50 other documents related to the project. Used as a kind of table of contents for the project, it made onboarding the new team easier. It also created continuity for the institutional memory of the product.
5. Discover & prioritize where you are going
When we received the benefit locator documentation from the 10x team, we made a discovery assessment and began adapting it to our USAGov team style and culture. Our exploratory deep dive helped us understand how the product was built--what technical and user experience decisions went into its creation. It helped us develop a vision for the next version of the product.
6. Communication, communication, communication
Regardless of thorough documentation, planning, and structuring, teams are made of humans. The products being built may be digital and technical, but the people and teams building them aren’t. So it was important to keep open and active communication throughout the handoff within and between teams. We requested more support hours from the 10x team than we thought we might need. This allowed our team to reach out to 10x freely, avoiding guesswork and saving time in the long run. It also gave 10x a chance to set their expectations for how engaged they would be post-handoff.
There is no perfect way to execute a project handoff. But whether it’s anticipated or unexpected, whole or partial, the more thought and communication the outgoing and incoming teams can invest, the better-prepared everyone will be to carry the project forward.
