My first job when I turned up in the DH Digital team was to review how we decide what to do next. I’m working in the strategy team, which means that alongside the work I do on raising capability within the department, I also programme manage our work across the whole of the digital team to shape the direction of where we’re going.
When I arrived, there were lots of documents explaining what we do, but it took me a good week of reading to get my head around it.
- a spreadsheet of “current” projects, some of which was up to date and some of which wasn’t
- a list of 15 objectives around transforming policy, comms and services- which was up for discussion
- some ‘manifesto’ slide decks on our policy and engagement work which had been agreed within the team
- an update to our digital strategy, which publicly promised to deliver work under 5 key themes of openness, simplicity, evidence, mainstreaming and efficiency.
And from looking around, I could see
- a busy team, working hard on lots of important projects, being busy with ‘BAU’, and people in different bits of the team picking things up left, right and centre.
Despite all of the documents and all of the busy-ness, it was difficult for me as a new arrival to work out exactly what we were busy ‘about’, and what we were busy ‘for’. So it felt like we needed to move from lists of objectives, ambitions and manifestos, into some a more tangible roadmap to show where we’re going.
My first task was to look at how we triage new projects, and communicate what we’re doing both within the team and to our stakeholders.
We need a triage process because of this conundrum: it’s difficult to do the right thing, do it quickly, and do it properly. It’s easy to compromise one element- but you end up with the wrong product, a poorly built product, or a product that’s never delivered because it took too long.
We have recently had our office ‘done up’ with new hotdesking facilities and an exciting whiteboard-painted wall, so this felt like a perfect resource for bringing our projects into a space where people could see them and talk about them
Crucially, this should help us adopt a more agile way of working - as a whole team, rather than 30-odd busy individuals working on competing priorities. By working together, we should be able to prioritise and plan more effectively, so that we get the right things done more quickly, and get early feedback to make sure that each project we deliver is top quality.
The first thing to do was a short ‘discovery phase’ to understand:
- What is the overarching context for what we’re doing?
- Who are the users of our programme wall?
- What are the needs of the different users of the wall?
- What would a successful prototype deliver?
I worked really closely with Lisa, who’s recently joined the team from GDS. Together we worked out where our ambition of digitally transforming the health and care system fit into the overarching DH purpose of helping people live better for longer.
We recognised that the purpose of the wall is to enable us as a team to start the right things first, and focus on them, to ensure that we do them properly- sorting out the triangle conundrum above. A successful wall would enable us to discuss new work as it came in, prioritise what we were doing, and allocate specific skillsets and time available in the team to the projects that help us make the most progress towards achieving our objectives. It would also cause a shift in the way that we’re working- from being a team of individuals to a team that can collaborate effectively to get the right things done first.
We mapped out our users, and discussed their needs. I ran a language analysis session with our engagement lead and head of strategy to understand how they naturally prioritised work in the team when they were put under pressure. This helped us to identify the criteria for prioritising one project over another- being the size and impact of the projects, where they contributed to multiple objectives, and where they really helped us to ‘transform’ something (although we did have some trouble with that word ‘transform’- as we’re still grappling with what we want to transform things into). This in turn helped us to build a prototype ‘card’ for the wall, to represent projects as they move through their journey from proposal to done.
We spent quite a while discussing how to present the projects, and finally agreed to split the projects into ‘transforming comms’, ‘transforming policy’ and ‘transforming services’- in line with the team objectives document.
We set out a prototype process for suggesting ideas, scheduling them, reporting progress and communicating completed projects.
And the alpha was born.
Over the next few weeks, we began to iterate.
- The cards on the wall evolved- from a hand drawn folded template, to a single-sided digital version.
- We ran sessions with individual team leads to understand their projects and see how the wall could better meet their needs- we learnt by doing.
- We moved the boundary lines around- so the ‘backlog’ became much bigger, ‘next’ could only hold 4 cards per objective, and ‘doing’ became strictly things we were working on this week.
- We piloted whole-team show and tells around the wall, to share our successes- and learnt how to keep those sessions to time!
- We held team-level discussions to focus our energy on priority projects, and push things on by timeboxing them.
- We had conversations about what BAU means, and how to represent it.
And we got to Beta.
We’re continuing to use and improve the wall, and writing this blog is an action from our last triage/wall meeting, where we discussed what we need to do to celebrate what we’ve done! We’re still getting used to the wall but it’s certainly becoming more and more helpful.
What I’ve learned:
- Change takes time- and people need to see and feel it working to buy in. Having something physical really helps with that seeing and feeling.
- Writing things down makes you do them- and helps other people help you.
- Showing and telling works- we’ve already identified crunch points where people were needed for two things at once, and avoided problems growing by talking about our current projects regularly and openly.
- Understanding user needs is crucial- and continual feedback really helps to make things better, because it’s very difficult to get everything right first time. This goes for the wall, and for individual projects too.
- Timeboxing something (putting a carefully selected mini-team to work on it for a week, and getting it finished) is really rewarding. The product is better, and it gets done more quickly. And as long as we’ve made sure it’s the right thing to do through the initial triage process, we’ve beaten the triangle- hooray!
- I need to blog more regularly- sorry this is such a long post!