3

I am currently transitioning responsibility from one team to another. All tasks that are handled by team A will be in the future handled by team B. The tasks are mostly support.

Is there any check list that should be followed in such situations? What are the most common problems in such situations?

  • Short term project, long term project, or some other situation? It might affect the answers. – SBWorks Nov 8 '11 at 9:47
  • @SBWorks: it is a long term project. Mostly support tasks for other teams, but also some development. – Robert.K Nov 8 '11 at 10:20
5

Although everybody suggest that we should have documents, having a 100% coverage of the system we support, in reality it never happens. Few of the following things may help

  1. Have somebody from team A to shadow team B for some period. This will help to solve those support issues, where it's not easy to discover secret recipe for solutions.
  2. Compile the list of most frequent support tickets and make sure your team spend some time to understand those area, even if there is no actual ticket.
  3. Communicate about this transition to all the stake holders. They may feel some degradation in the support services for some time.
  4. Make sure to maintain the morale of the team. Team members may feel bad about themselves when not matching customers expectations. Moreover users, with their urgent issues, will be creating pressure to get there things done and that's where you need to pitch in and save unnecessary trouble for your team members.
2

The principles of both teams need to work together to establish a transition plan so that everyone is crystal clear on how to answer the who, what, where, when, why, and how the transition will work. I would bet the three biggest risks you will face is a severely constrained timeline in which to conduct the transition, stakeholder grief due to the imminent degradation of support services that WILL occur because of the transition, and the new team not have all and/or the right resources--human and otherwise--ready to go.

Is this change due to a re-compete loss? If so, the new team should expect a transition partner that might range from what looks like lazy to downright sabotage.

I think having a readiness checklist is critical, and it should be derived from the plan above. You might use the risk breakdown structure to help brainstorm those things that need to be on the checklist: Technical, Security, Equipment, External, Financial, Organizational, Contractual....

If I had to choose the highest priority in the change, it would be the impacted stakeholders, the teams' customers, creating early and ongoing communication setting the expectation that services will be less than desirable for time to come. These would be the highest priority risks on which I would focus during and after the transition.

1

There are numerous templates online for transition responsibility (e.g. from one team to another or from development to maintenance/support).

I Googled around and found this one template from the North Carolina government. I'm sure you could find others that would be helpful.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.