Lessons learned from go-live (post for Select) (#321)

Author: kieron-bradshaw

app/select/2025/12/lessons-learned-from-building-cohort-manager/cohort-manager-landing-page.png

@@ -0,0 +1,121 @@
+---
+title: 5 lessons learned from building Cohort Manager
+description: Five important lessons we learned from getting Cohort Manager live (and what we're doing about them)
+date: 2025-12-17
+author: the Select team
+tags:
+  - beta
+  - live
+  - breast screening
+---
+Our team recently celebrated getting Cohort Manager live! 
+
+In case you’re new to the product, Cohort Manager is used alongside other digital systems to identify people that are eligible for routine breast screening. It transforms their data into the specific format needed by breast screening services, and checks for quality issues, such as gaps or conflicting information within each record. It also supports with tasks to manually add or block participants in the breast screening cohort.  You can find out more in [our previous posts](/select/).  
+
+Getting the system live with very few issues was rightly seen as a huge success, and the team gathered to reflect on the project and discuss what went well and what could be improved.  
+
+Here are five important lessons we learned and what we're doing about them. 
+
+![A zoomed-out view of the digital ‘Mural’ board used to facilitate the team retro session. It’s split into four sections with headings: ‘What went well?’ ‘What could have been better’ ‘Ideas’ and ‘What could we do differently next time’. Because it’s zoomed out, content on the notes isn’t readable - but we can tell by the volume of them that lots of ideas were captured during the session.](retro-session-mural-v2.png "The Mural board used to facilitate the team retro session.")
+
+## 1. Mature teams that work openly can overcome significant challenges 
+
+For every challenge faced, a common theme for us suceeding was the maturity of the team, and how well people communicated and collaborated.  
+
+When project scope changed repeatedly or unforeseen problems emerged, the team were patient and worked flexibly and efficiently. Working in the open helped keep everyone aligned and maintained momentum, with team members frequently discussing blockers, asking questions, and being receptive to constructive feedback. 
+
+A challenge to this was the large size of the team, which sometimes made communication difficult, caused silos between professions and made roles and responsibilities unclear. This also moved us away from agile principles, making it difficult to be cross-functional and autonomous. 
+
+> [!NOTE] What we're doing going forward:  
+>
+> - running sessions to better understand each other's roles and how we can work together even more effectively 
+> - adjusting team structure to fit delivery needs 
+> - being clear on intentions when adding resource to the team (and regularly assessing if the team is too big) 
+> - reviewing the size and shape of regular team meetings and how they’re run
+
+---
+
+## 2. Build relationships early (and keep them going) 
+
+We had some great successes when we built good relationships with stakeholders. For example: 
+
+- regular collaboration with partners like the National Service Desk kept everyone aligned 
+- access to user groups for research and testing strengthened the final product 
+- our collaboration with technical platform colleagues was crucial to the smooth go-live 
+- senior leadership support was invaluable as we approached go-live  
+
+Challenges occurred when we didn’t do this early; for example, limited early engagement with live service management teams meant we initially spent time designing for the wrong user group. There were also blockers in recruiting users needed for research that could have been resolved with earlier relationship-building. 
+
+> [!NOTE] What we're doing going forward: 
+>
+> - establishing better connections with partner teams from the start of future work 
+> - continuing to build relationships with teams such as Cohorting as a Service, the National Back Office, and clinical leads 
+> - circulating senior leadership conversations and agendas in advance, so the team can feed into discussions 
+> - ensuring the right business change conversations happen early so we design for the correct users 
+
+---
+
+## 3. Define scope and document decisions as you go 
+
+Our project scope changed significantly during delivery. Some examples of this were:  
+
+- the vision of Cohort Manager reduced from being used across multiple screening programmes to focussing on breast screening 
+- important technical integrations with other systems, such as ServiceNow, have been held back for future releases 
+- changes in priorities outside of the team (in the wider digital screening space) brought new, often reduced requirements 
+
+Another challenge was that not all significant decisions (including stakeholder reviews and sign-offs) were documented from the outset. Plus using multiple channels for information (Slack, Confluence, SharePoint) created confusion about where to find things and made it harder for new team members to get up to speed. 
+
+> [!NOTE] What we're doing going forward: 
+>
+> - applying agile thinking of ‘rapid, thin-slice delivery’ – so that changes in scope are easier to absorb 
+> - getting technical integrations with ServiceNow underway   
+> - creating a clear decision-making process so everyone knows how and why decisions are made 
+> - setting clear expectations about how and where to document work and decisions 
+> - setting clearer and tighter sprint goals 
+
+---
+
+## 4. Making late changes creates pressure across the whole team 
+
+Last-minute changes created significant pressure and impacted the quality of the product. For example: 
+
+- a major feature for reports was added to the user interface late without opportunity for improvements before go-live 
+- late changes to the process of how some data exceptions would be handled meant we needed to roll out training with users incrementally rather than all at once 
+- a key technical decision about how users would access the system changed very late and work had to be reverted 
+
+The pressure to meet the go-live date meant rushing some decisions and limited our ability to be truly transformative with certain features. 
+
+> [!NOTE] What we're doing going forward: 
+>
+> - implementing a release strategy to align with changes and future proof the platform 
+> - regular prototype demos to users and stakeholders, to reduce surprise requirements when things feel done 
+> - conducting impact assessments to help prioritise features outside a release scope 
+> - setting realistic expectations with senior leaders and stakeholders about what's achievable within constraints  
+
+![The landing page in Cohort Manager’s user interface. This is where users can choose to access data exceptions or reports that need to be manually investigated. The navigation cards for each of the areas show the number of exceptions or reports outstanding, giving the user an overview of their tasks.](cohort-manager-landing-page.png "The landing page in Cohort Manager’s user interface - the 'reports' section was added late during the build of the product.")
+
+---
+
+## 5. Focus on user outcomes, not just technical architecture 
+
+With Cohort Manager being such a complex product, the technical architecture behind it was crucial. It became so important and demanding that it took focus away from designing for the problem being solved, and our end users.  
+
+The complexity also resulted in it being difficult to define whether we were building a data transformation product or a system for operational staff (and if for the latter, who our users were). Breaking scope up around the problem we were solving may have helped keep the focus on what users need to achieve, not just what the system components required. 
+
+> [!NOTE] What we're doing going forward: 
+>
+> - designing around what we're trying to solve and user needs, not just technical architecture 
+> - defining clearly who our users are for each piece of work 
+> - continuing to work closely with current users to gather feedback on the live system 
+
+---
+
+## Summary 
+
+The team delivered a major new digital system with very few problems at go-live – a significant achievement. 
+
+The importance of teamwork, clear scope and documentation, building relationships, managing late changes, and maintaining user focus will shape how we approach our next piece of work. 
+
+Before we finish, here’s some parting wisdom from the team:
+
+> **Celebrate the wins, no matter how big or small – it will keep you going!**