Developing digital services in health requires all sorts of assurance processes – clinical, technical, information governance and so on. I’ve seen assurance that can range from highly effective and supportive, to being a complete drag on innovation, quality or pace. It all depends on how it is executed.
The worst form of assurance is when teams have to go begging to a governance board of high-and-mighties who have zero knowledge of a product, its users, the research and the tech and design trade-offs made to get the product to where it is. Assurance in this case is just not meaningful, and often defaults to the strength of the relationships between the requester and assurers.
The absolute best form of assurance is when experts are considered part of the delivery team, sharing the same vision and outcomes, and assuring as they go as part of an iterative ongoing process. They can still report to higher-ups, but the decision remains closest to where the knowledge is.
My experience was that during the pandemic, all assurance of the digital services I worked on was the latter by necessity. But it shouldn’t need a pandemic. Experience from across many sectors in Public Digital shows this is a better way.
In Public Digital we often talk to clients about working in the open. We think it’s a key ingredient of successful digital transformation.
What is working in the open?
Working in the open means showing people the work you are doing, as you’re doing it. At a minimum this should be people within your team and people across your organisation. Even better is sharing publicly, with stakeholders outside your organisation who have an interest.
Working in the open is not just about demonstrating progress, but also talking openly about mistakes, changes, and things you’ve learned. It’s partly to support communications, to help you build a movement for change. But it’s also about good governance. It gives stakeholders a window onto your work that drives up quality, helps unblock, and manages your dependencies. Work in the open by being open about the work.
Typical examples of working in the open are as follows.
Hosting ‘show-and-tell’ sessions. A show-and-tell is a regular (every 2 weeks, say) open invite event. The team does a short presentation about recent progress, and allows time for questions at the end. Importantly the team does not simply give a status update but “shows the thing”. Such as prototypes, designs, research, or other lightbulb moments.
Publishing regular updates on the team’s progress. For instance by writing and publishing weeknotes. Or writing regular posts about more specific things as they learn them. This could be a set of insights from user research sessions. Or the logic behind making a particular choice about a technology.
Publishing code and documentation as open source. When a digital team is developing a digital service or piece of software they should code in the open wherever possible. Publishing code in public repositories helps teams focus on the quality of their code and documentation. It allows others to build or copy the work that has been done.
GCHQ’s internal Boiling Frogs research paper on software development and organisational change. If GCHQ can work in the open, anyone can.
Using workplace messaging tools. This is one of the simplest things you can do to help your teams work in the open more. Posting information in a ‘chatroom’ rather than sending an email switches the default visibility of a message from closed (only the people copied get it) to open (everyone in the channel or room gets it). This helps all the team know what’s going on, and allows the team to discuss important topics together. It also allows discussion to happen asynchronously without the need for a meeting.
Richard Pope has published a brilliant thread on twitter of some of the things teams publish in the name of working in the open & transparency.
Working in the open: chat rooms
How does working in the open help
What is the traditional way of communicating?
Traditional methods of project communication typically follow these patterns:
Broadcast. The communications are one-way.
Hierarchical. Only the most senior people are allowed to represent the project.
Tightly controlled. Everything has to be cleared by a separate comms team.
PR-oriented. The objective is to spin what you’re doing to show it in the best possible light.
Big bang. One big press release when the work is ‘finished’.
These types of communications are often impersonal, inauthentic, and frankly boring.
Advantages of working in the open
Working in the open is typically low cost and has a number of advantages
It supports better project communications because:
It builds momentum. Digital transformation is not only about technology. It’s also about changing culture, process and operating models. You won’t be able to do this in a silo. By working in the open, you can develop your narrative and bring people with you. It helps create momentum for change. Sharing what you’re doing little and often increases the chances people will engage, reaching wider audiences.
It’s 2-way. It allows your audience to interact and converse with you. It opens up a channel for you to receive feedback.
It is timely and relevant. Avoiding long comms clearance processes enables your communications to happen when the work does. This helps build momentum and keeps you on the radar of key stakeholders: decision makers or funders. Decision makers don’t like surprises.
It has more authenticity. Working in the open allows you to talk in the voice of the people who best understand the project. Helping people understand why you’ve made the decisions you have builds trust. Like your maths teacher used to say, show your working out.
It supports better project governance because:
It makes the service better. More eyes and earlier eyes on the service, product or project means it will get improved, more quickly and at lower cost/risk.
It is a window onto your world. It allows stakeholders a much clearer understanding of what the hell is going on than a Red/Amber/Green status report in 8pt Arial on a slide.
It manages dependencies. Legacy organisations tend to try and manage dependencies in large spreadsheets. This may allow one person (the owner of the spreadsheet) to understand dependencies. But this isn’t enough. Working in the open allows everyone to see what’s in flight, and identify and manage dependencies for themselves.
It helps you manage and persist knowledge. It enables you to build an open store of understanding and insight over time about how and why things have been done. This makes it easier for others to copy or pick up where you left off. It allows others to link to what you are doing and explain.
It supports capability building because:
It helps you hire. Digital professionals like to be able to work in the open. If your organisation can show that it works this way, you will attract more of the people you need. “I asked members of the audience to raise their hand if they wanted to work at GDS after reading one of its blog posts. 75 per cent of people put their hand up.”
It is democratic. Everyone on the team is empowered to showcase their expertise about what they’re doing and why. This builds confidence in communications skills. It helps everyone feel like they are contributing.
If you want to build trust, confidence, and learning, we suggest you work in the open.
For the uninitiated, this is the policy response to a challenge teams are navigating up and down the country. Some responsibilities for health and care fall to the NHS, and some things are done by local councils. This can create a mess of misaligned incentives, duplication, and fragmentation.Enter the Integrated Care System (or ICS for short) to help straighten things out.
“In an integrated care system, NHS organisations, in partnership with local councils and others, take collective responsibility for managing resources, delivering NHS care, and improving the health of the population they serve.”
NHSE/I.
NHSE’s proposal aims to formalise the model, putting the ICS reforms on a statutory footing and give them responsibility for planning and buying services. This is an oversimplification, but the move would seemingly repeal aspects of the Health & Social Care Act 2012. For further reading NHS Providers has released a helpful primer.
What the paper says about digital
There are quite a few references to digital in the NHSE/I 40-pager. I’ve extracted them to save you a job.
Starting from the off, there’s a clear strategic intent to put digital & data at the heart of the change. It’s one of a handful of key themes.
“…we will need to devolve more functions and resources from national and regional levels to local systems, to develop effective models for joined-up working at “place”, ensure we are taking advantage of the transformative potential of digital and data, and to embed a central role for providers collaborating across bigger footprints for better and more efficient outcomes. The aim is a progressively deepening relationship between the NHS and local authorities, including on health improvement and wellbeing.”
In addition to this broad strategic intent there are more specific points on digital that are set out as follows:
ICS’s will have an SRO for digital on their boards.
ICS’s will need a digital transformation plan.
There is a responsibility to build digital and data literacy of the whole workforce “as well as specific digital skills such as user research and service design”. And can we just pause for a round of applause for whichever official managed to squeeze that latter clause in. 👏
Introduce shared contracts and platforms including shared EPRs.
Develop or join a shared care record joining data safely across all health.
Build the tools to allow collaborative working and frictionless movement of staff across organisational boundaries, including shared booking and referral management, task sharing, radiology reporting and pathology networks.
Follow nationally defined standards for digital and data to enable integration and interoperability.
Use digital to transform care pathways.
Develop shared cross-system intelligence and analytical functions.
Ensure transparency of information about interventions and the outcomes they produce.
Develop a roadmap for citizen-centred digital channels. NB Not sure why this would be different to the digital transformation plan referenced above, but nevermind.
Roll out remote monitoring to allow citizens to stay safe at home for longer.
What does that mean for local digital capability?
So far so lofty. But what does the team look like that has to be put in place to deliver all of this?
The challenge of doing cross-institution service design in health and care has long been a bugbear of mine and many others. How can you possibly design great services across such a fragmented system? The NHS must be the largest manifestation of Conway’s Law on the planet. So on the face of it I think this reform is A Good Thing. But it will only solve the digital mess if there is also investment in capability at the ICS level to be able to deliver it. The types of people you need to deliver all of the above amounts to really rather a lot of specialist skills. And there are, assuming the website is up to date, 21 ICS’s currently.
Individual trusts, councils, and others will also have their own digital and technology teams. Institutional fiefdoms will still need to be managed, so how to ensure all the relevant organisations have skin in the game and that the whole is greater than the sum of its parts? This will all also need to be executed in the context of national agencies delivering platforms, framework agreements, and inevitable ministerial pet projects.
What should an ICS Digital Team look like?
I guess a lot of this will need working out and no doubt people are on the case as we speak. But my starting points for an ICS digital transformation team would be the following:
Multidisciplinary: it would contain designers (service, interaction, content); transformation experts; product and delivery people, user research; interoperability gurus; data scientists; IG experts (the ones that enable not block); and experts in the management of commercial IT contracts. It would also definitely have some technical architects (not armchair architects, ones that can still write code) and developers.
Empowered, within some well understood and enforced guardrails delivery teams need to have clarity of purpose but freedom to act. There needs to be an agreed patch for sensible service design, and this feels most achievable at the ICS level. Teams should be autonomous to work within that. But there should also be some rules around what gets built or bought, based on the NHS design standard and use of common NHS platforms.
Networked: the teams across the country should all be talking to each other. One of the most brilliant but little-talked-about innovations of the central government digital transformation movement was the cross-government Slack instance. All digital professions in the civil service across the country could instantaneously reach tens of thousands of other experts. A question like “does anyone have experience of translating services into Welsh” would attract multiple offers of help within seconds. Building on the curated communities that already exist like Digital Health Networks need to be turbocharged.
That’s my view at least. I am sure others will have alternatives and I’d really love to hear them.
This post was originally published on Medium on 10 December 2020.
We’ve been doing some more work on our intranet. Here’s a rundown of our latest release and some final thoughts on what I’ve learnt working on this product.
Why take a digital approach to an intranet?
I’ve said in previous posts that intranets can be the scorn of digital purists. “Why not just have a wiki and a blog – it’s totally free?” they cry. Well, maybe.
But as this is my last intranet sprint (sprintranet?) I wanted to make the case for taking a digital approach to this ever present departmental tool. I think there are 4 compelling reasons.
Improved experience for users. The obvious one. Civil servants are users too, and saving them time and effort with products that work is better for them, and better for taxpayers.
It’s a means of spreading digital culture and techniques widely across the department. Talking to lots of teams in the department about their intranet content or involving them in user research has enabled me to introduce principles of agile and user-centred design to lots of people who otherwise would never have encountered these techniques. A good thing in the wider scheme of digital transformation.
Getting content design more widely understood. I’m increasingly convinced that content design training should join information security and unconscious bias as mandatory for policy civil servants. Until that happens, working with teams on their intranet content is a decent alternative.
It’s a good training ground. A staff intranet is a reasonably low stakes environment, which makes it ideal for practising agile techniques, user testing and the like. Particularly as uses are on your door step. Four different fast streamers have now participated in running guerrilla testing or pop up labs in the department, and done brilliantly at it.
On to the highlights of our latest release. As ever, if anyone is interested in playing around with the intranet WordPress theme, it’s available on Github. All comments and thoughts welcomed.
Homepage
In our last intranet post we talked about the changes to the homepage design. The changes have attracted a lot of great comments. But more importantly our ongoing testing is showing users are completing popular tasks more easily.
Of course not everything is working perfectly, so we are continuing to tweak and improve. For instance we found users were not noticing when new content was being posted in the campaign box. So we introduced a ‘new’ banner to signal this event.
Information architecture
Our ongoing user research has repeatedly surfaced pain points for users navigating the site. Users did not always understand the main section headings, or what topics might be listed underneath.
To test further we ran several card sorting sessions to try and come up with better labels and a more intuitive architecture. Despite plenty of hard work, it turned out we couldn’t. Naming and sorting things into categories is just one of those timeless problems. We ended up agreeing that what we had was probably the least worst option.
To attack the problem from another angle we introduced some new functionality. We implemented the brilliantly named Accessible Mega Menu. This now provides a drop down of topics that appears underneath a section heading, to help users see what is available and help them answer their questions more quickly.
Events
The department puts on a wide range of events. By making use of the Eventbrite API, our intranet administrators are able to create and manage events using all the functionality of Eventbrite. Once published, the event details are pulled automatically into the relevant intranet pages. Along with some design tweaks, we’ve made an already excellent events booking process even better.
Our next sprint will be later in the year. Look out for further updates from a new product manager then. And a final word of good luck and thanks to the brilliant team. My laptop will continue to wear our mission patch with pride.
This post was originally published on the Digital Health blog.
Six months ago I made a career pivot from policy making to product management. The roles require a similar mix of empathy and politics, so I feel I’ve taken to it reasonably well. Alongside a deep understanding of Internet-enabled technologies, a notable difference is how much and how effectively product management makes use of specific tools and methodologies to solve problems.
So here are ten techniques I would bring into a policy team if I went back. If any of the terms don’t make sense, Ben Stevens from the Home Office has posted a handy glossary.
Work in sprints. Choose a time period of 1 or 2 weeks to help give structure to the team’s work. Get everyone together at the start of the sprint and agree the things you are going to focus on completing in that time, remembering that new tasks will come in too. This is called sprint planning.
Hold ‘stand-ups’ over the course of the sprint, and ‘retrospectives’, and ‘show and tells’ at the end of it. Don’t be spooked by the language. These are just meetings, so not exactly an alien concept to policy makers. There’s no need for me to repeat better guidance elsewhere on this, except to endorse how useful they are as an ensemble.
Get a wall. Every team needs a wall. I managed a major house renovation last year and even had a wall (this is not a joke). At its simplest this is expressing a task on a Post-It note, fixing it to a nice flat surface that people can gather around, and moving the tasks through columns labelled ‘doing next’, ‘doing now’, and ‘done’. Do this, and then feel the energy and sense of achievement coursing through the team as they deposit card after card in the done column at each stand-up.
Create genuinely multidisciplinary teams. I spent some time shadowing my mentor who works on NHS.UK Alpha a few weeks ago. It’s a full-blown agile team, replete with product manager, delivery manger, content writers, designers, and developers. Having such expertise around a table enabled them to do magical things, like designing the key features of a GP look-up service, in record time. My experience of policy is usually hierarchical group of something akin to project managers. Other experts tend to be in a box somewhere, wheeled out for special occasions. It also now seems amazing to me that design thinking in policy is still seen as the cutting edge while it’s de rigeur in digital.
Make it someone’s explicit responsibility to knit the team. The mantra goes, “the unit of delivery is the team”, and commensurate effort is placed in getting that team working brilliantly together. My experience working in policy teams is that if they are working great, then great. But if they are not, the response is usually a shrug and sporadic suggestions for ‘more social events’. Digital methodology encourages constant communication between the team using stand-ups. It celebrates successes through show+tells, and does a thorough job of learning from failures through retrospectives. The result is a team completely aligned around an objective, with everyone feeling they are part of something important, and fantastic pace of delivery. Tasks fall to the team not individuals. This reduces risk of single point of failure.
Separate responsibility for day-to-day delivery with big picture and vision. In digital there are overlapping and complementary roles called product manager and delivery manager. The former focusses on macro issues: vision, roadmap, stakeholder management. The other focusses on micro issues: unblocking the obstacles the team faces day-to-day, and doing the team coaching I describe above. This structure recognises something important about our minds being poor at doing two things at the same time. It’s very effective.
Try out some new collaborative tools. Digital teams more naturally have their fingers on the pulse of internet-enabled tools to facilitate team communication, prioritisation, or collaboration. I know IT systems can create barriers to this; but in an age where everyone has a smart phone it’s not hard to find workarounds. If you had to pick any, for me it is Slack. There’s a bit of a backlash against Slack at the moment (Slacklash?), but frankly I’m still at the crest of the wave of appreciation that sees how much more efficient than email is at enabling team interaction.
Prioritise properly. Product recognises you can’t do everything, so have a plethora of techniques for deciding what comes next. Do a few things well rather than lots of things mediocrely, and be rigorous in your approach to choosing which those things should be.
Clap more. Digital teams religiously clap their teammate’s or others’ presentations. This is not only courteous, but sends the presenter away with those few extra endorphins that make it all seem worth it.
Be agile.Note the small ‘a’. My simplest interpretation of this is understanding that for almost everything, your first answer could well be wrong. Doing something and then testing it is better than trying to get it perfect first time. As long as it is labelled as such, it is fine to say something is a prototype or early version and will be iterated, improved, or even binned.
None of these suggestions are especially complicated. But they can be tough to implement in teams unfamiliar with the language and culture. Digital teams should help with this where they can, as forming good habits should not solely be the preserve of digital. They should be for everyone.
I’d be delighted to give my novice advice to any policy makers, so do get in touch if it would help. Hat tips to Lisa, Matt, and Kylie for product coaching, andBenji for delivery management advice.
We designed our intranet to be continuously improved, and over recent weeks have been doing just that. Since the intranet’s launch last year we have gathered data and done extensive research to deepen our insights into our users’ behaviour. This is enabling us to flex our product to meet our users’ changing needs – in line with digital best practice.
In our most recent development sprint, we focussed on the homepage. The intranet homepage is the first thing most people in the department see when they log on in the morning, so it’s not surprising that 99.9% of user journeys begin there. That’s not true of all websites – GOV.UK pages are often reached via a search engine – but our default makes the homepage a prime piece of digital real estate. It deserves excellent design and only the most important content or features.
From looking at site traffic we could see the content users visited most over the past year. For instance: guidance on performance management, expenses claims, booking video conferencing, and a few specific forms. Over the last month or so, content about the DH2020 change programme has also been very popular.
This data informed our qualitative research. We interviewed twenty-one individuals, asking them about their use of the intranet. We also observed them using the homepage to try and perform particular tasks. As well as interviews, we ran card sorting exercises and a co-design workshop where users drew sketches of their ideal homepages, or voted on features they liked from other government intranets. The range of ideas generated ranged from the pragmatic to the extravagant. But the discussion was invaluable in helping our suppliers understand the needs of DH staff. Over two weeks our experts translated those insights into some of the changes you can now see:
Bringing in common design patterns by integrating the menu, search and login into the header to help users find them
Developing prominent areas for links to popular services and pages; these are customisable by our content team so can change as needs change
Introducing a campaign box to highlight the most important ‘need-to-know’ information of the moment
Increasing the number of news stories further down the page; as the large number of users felt the stories dropped off the homepage too quickly
Retaining a clean design that users responded to well, but binning the bits that users did not need or want anymore
Communicating via Slack across several UK locations, the team deployed the changes early last Tuesday morning. Thanks to the brilliant work of the developers we encountered almost no bugs, and by the time we got into the office some fantastic feedback had started to come in.
Launching is the start of a process, not the end. We’re moving straight into more user testing, including those using assistive technologies, to ensure our changes are performing as we want.
An ‘agile intranet’ is something the department should be proud of. Internal services and tools are rarely built in this way. It has only been possible for us to effect improvements to this product quickly, cheaply, and securely thanks to ourpredecessors. They left us a site built on open source software, to open standards, with no contract lock-in, and with the precedent set for relentless focus on user needs. Long may that continue.
No digital product is ever perfect or finished. Even a site that is 90% cheaper than its predecessor, and boasts a user satisfaction reaching post-launch heights of 80%. My challenge as the new product manager for the Department of Health’s intranet is to build on that daunting baseline, and carry on the great work of my predecessor, Kylie Mulholland. Revisiting lessons learned from the intranet’s first development seemed a good place to start.
Over the summer we ran a discovery phase to understand how people were responding to the new site. We found that overall, users much preferred the new product to what came before. However, they would still like to find things more easily through either search or navigation, particularly the things that help them do their job. These findings were borne out by analytics data: video conferencing arrangements consistently appear among the site’s top search queries. The discovery also revealed unmet needs on the editorial side, where content owners and editors wanted a more streamlined publication process.
Last week we brought together a multidisciplinary agile team to begin a new period of development. We work in several organisations and multiple locations; Whitehall, Old Street, and as far as Atlanta, Georgia, so online tools like Slack, Basecamp, and Talky are helping to keep us connected with each other and our users.
Stubborn on vision; flexible on details
Our first step was to draft a set of high level goals for this phase of development, which support our overall vision of making the DH intranet the best in government. As ever, we welcome feedback.
Users can find everything they need and access the services they want
Borrowing a method from the Government Digital Service, we then built a prototype roadmap. This exercise forced us to think about what we would have to learn or prove if we wanted to achieve our goals. For instance, to show that “users can find everything they need”, we need to first find out what users are looking for, and then show, using data, that our improvements actually do help users find those things more easily.
We also identified and prioritised the big themes emerging from the discovery and mapped them against a rough timeline of development sprints. These included search and navigation, events, content management, and sign-in.
Finally, we used the roadmap to map out: our users, the wider ‘system of systems’ that support the intranet, our most important stakeholders, our assumptions, and any dependencies. This helped surface challenging questions early on. Our prototype roadmap is on display in Richmond House and will help us communicate to stakeholders what we are doing, why, and broadly when.
Our first sprint
Before we get going on new features, the team are first reviewing and cleaning the code base, fixing bugs along the way, and by the end of the week we’ll have it back in GitHub. Making things open makes them better and from next week any organisation can take our code and ideas and start to build their own intranet sites, according to their own users’ needs.
I’ve learned a lot in my first weeks in product management. It has not taken long to experience the tension between user needs (what evidence suggests end users of the product want to see) and business needs (what other stakeholders would like their users to see). This forces you to ask some pretty fundamental and philosophical questions about the real purpose of the ‘thing’. I’ve also learnt that getting the right policy, process, and governance around the product may be at least as important as the product itself. Finally, I’ve sensed that many digital folk think that intranets are the devil’s work! It’s our job to prove them wrong.
Originally published on the Department of Health digital team blog.
