The challenge
When the time comes to swap out a support team, people naturally get nervous. That happened recently in an assignment for a large government organisation, where we transitioned all the support and assurance activities for a data analytics service from one supplier to another within four weeks.
What we did first
Recognising the need for speed and transparency, we took a proactive stance to gain the trust and confidence of all the dependent teams and services. We acknowledged that we didn’t have all the answers but were ready to experiment, adapt, and learn.
- Toolset: Our first step was establishing what tools we would use to define, communicate, and manage the work. I chose to combine Confluence, Jira, Teams, and Miro from the approved software available. These tools were accessible to the whole organisation, so it was not just a technical setup task but a strategic move to provide our stakeholders with a clear view of the transition.
- Structure: Next, we wanted to create a flexible delivery framework to start the work quickly and iterate our approach as we learned. We chose three themes to structure the project: People, Processes and Tech. We then agreed on a priority list: ASAP, Go-Live and Post Go-Live. This created a framework to map out activities and identify solutions.
- Hit list: Finally, we brainstormed a stakeholder map of all the people we wanted to speak to so we knew who to speak to first and how to involve them.
Getting to work
We ticketed the hit list up in Jira and, using the integrations, created dashboards in Confluence to help Senior and executive Leaders understand the project’s status quickly.
The first group of people we spoke to were the incumbent team. We wanted to understand:
- Who did what and how they did it (Processes)
- Who were their touchpoints in the organisation, and why was it essential (People)
- What products and services are they used to (Tech)
This session provided us with an overview of how the support team functioned and what the drivers were, so we now had an idea of what we would need to transition. It also allowed us to chunk the work up even more and add tickets to Jira.
The work breakdown looked like this:
We could then prioritise the discovery activities based on the structure outlined above and introduced a rating of the quality of the handover/way of working to help us further determine where to focus our efforts.
ASAP Tasks
We got to work understanding the Customers, Live Service and Customer Tech essential for running the live service and ensuring documentation around Ways of Working and access were in place. We choose these as ASAP Tasks because we needed to thoroughly understand the Customer, Customers tech and the Live Service we would need to support. Therefore we wanted to quickly establish how much work was required, so chose to focus on this area first. To support this we also need to grasp the Team Tech to ensure we had full access to everything required to provide a support service.
We managed the work by ticketing all the activities as Jira Tasks and then grouping them as Epics aligned to the work breakdown structure. While this resulted in many tickets, it ensured that we got everything and allowed us to prioritise tickets easily as the transition progressed.
We created a KanBan board to reflect our work pattern. The result helped us focus on getting work done, and the peer review improved the quality of our work.
We regularly ran refinement sessions to fill out the details and prioritise tickets before we moved it to TO DO, and the team picked up the work.
We integrated Jira with Confluence to create a dashboard that showed the status of all the tickets in table and pie chart form so Senior Leadership could quickly understand the transition’s status.
Go-live Tasks
While the team worked through the Now Tasks, I focused on the next phase of work: Go-live Tasks: Comms, Partners, Team and Assurance.
We wanted to understand how we Communicate, who our Partners will be, how to set up the Team and what Assurance activities are required to we could build collaborative relationships. Working with the existing team, we listed (and ticketed) all these areas then prioritised the backlog based on understanding of the Way of Working.
In collaboration with the programme comms team, we followed up on the official transition announcement and arranged meet-and-greets with all the Partners. These sessions also provide an excellent opportunity to discuss our plans for more prosperous collaboration and transparency so we can better serve the user community.
Check-ins
We took an many opportunity to review the brief, analyse the working patterns, and reprioritise the backlog. This activity assured us that we were on top of the work and that our priorities were correct. In addition, there would be an excellent opportunity to productionise the support service and highlight the markers for working towards being a high-performance team, both of which would provide added value to the customer.
Head Down to the Finish Line
As we reached the midpoint, we were in our flow; tickets were moving across the board, we swarmed on and escalated blocked tickets, and the team began to pick up live service work based on their newly acquired knowledge. We also shadowed the existing team, creating and refining Way of Working documentation where there were gaps and improving our knowledge as we progressed through the transition.
We reported progress to Senior Leadership throughout the project, providing regular live updates via the dashboard. The whole approach blew them away. They liked how fast we made an impact and the transparency around workload status provided by the dashboard.
As we continued refining the backlog and analysing our flow, we added tickets and created Everything Else tasks. Also, we moved some tasks, which we initially planned as Now or Go-Live, to actioned later as our knowledge of the support service grew through process and stakeholder analysis.
In addition to the translation work, we began working closely with the Product Owner to create a process for refining and prioritising user needs. This process covered Everything Else tickets and Requests for Work tickets that filtered through during and after the Meet and Greets session. All of this was visible on our published backlog and roadmap, providing the user community with a view of our current and future work.
Transition Day
As the day to switch over to the new team running the service approached, we reviewed all the remaining tasks to ensure we focused on critical areas to support the live service on Transition Day. Approximately 50 tickets left at this point, and we decided that 35 were either duplicates, no longer required or could be picked up later as an Everything Else task.
With a looming deadline and newly refined focus, we were able to work through the remaining tickets.
On Transition Day, the team seamlessly took ownership of supporting the users, knowing what activities to do and how to do it, thanks to clearly documented processes, peer reviews, and shadowing of the existing team. Thanks to the Meet and Greet session and the newly created processes of Product Development with the Product Owner, we knew who our stakeholders were and their priorities.
Lessons Learned
- Use a lightweight, flexible delivery framework. To work fast and make an impact, you need a structure that allows you to focus on what is essential and ignore (for now) what can wait.
- Learn by doing—Planning sessions can be resource-intensive, take up time, and often become out of date quickly. It is better to work through challenges to gain a practical understanding of the work and better understand the dependencies, blockers, and amount of effort required to solve them.
- Refine and reprioritise – The more you learn about a project, the better you can decide what to focus on doing and what not to focus on doing.
- Be transparent. By letting senior management and users see what the team is doing and what the status of the work is, you create trust, which allows you to focus on what is essential.
- Over communicate—Throughout the transition, we used a combination of Teams, Emails, and Calls to ensure that affected users knew what would happen, when it would happen, and when it had happened.
So there you have it, mobilisation, discovery and delivery in 4 weeks from a standing start. If you would like to discuss how we can help you transition a team please get in touch.