Geof Harries

If you work in government or a large organization, you’ll likely have encountered some or all these scenarios when trying to get a new digital service shipped and into the public’s hands.

• Support staff are nervous about making a service available that changes an established process and program. How will they handle complaints? Issues? Bugs? What if something goes wrong, especially at scale?
• Staff believe that the product is not yet complete and will cause issues if we proceed as is. There are still outstanding bugs and issues to be addressed, but we have to ship now!
• Program owners are nervous about their staff bringing these concerns to them in an area (technology) they may not be comfortable in and know enough about.
• Owners are worried about putting themselves at risk in the media and within government amongst their peers and superiors.

These are all legitimate concerns. I’d feel the same way if I was in their position.

Thankfully, I’m not in their position. During my time in government, I’ve been involved with shipping over 100 online services and websites. I’ve got the scars to prove it.

Here’s some of the lessons I’ve learned when it comes to successfully managing change and delivering working processes, policy and software.

Have an ongoing support plan and budget

All services should be backed by a support plan and budget that allows for continuous large and small improvements throughout its lifetime.

I want to highlight the term “continuous”. This is important. If you only respond to issues as they arise, you risk building up technical debt and leave yourself open to emerging security threats. Your service may also stop meeting user needs.

A support contract is typically between 1 and 3 years in length whether through a vendor, internal staff or a combination. In our group, we typically recommend 5 to 10% of the original project budget for a contract amount.

Support plans allow you to respond to technical problems, security vulnerabilities, policy updates and changes in user behavior. They can also cover new features and ongoing user support and training as staff leave or join an organization. This includes keeping user manuals current.

Empower program staff with the right tools and mindset

The end of development and launch of a service is just the start of a longer journey. A digital service needs care and attention. It’s like moving into a house. You buy or build, then decorate, patch, maintain and extend. The process never ends.

After you go live with a digital service, your team will often dramatically shrink in size. For example, people who helped with design, policy and development will move onto other roles and projects. Your relationship with them can evolve into simply saying Hi in the hallways.

As a program owner, you may feel alone and concerned that you don’t have the skills and tools necessary to run the digital service in the public domain. You’ll become the face of the service, and that’s at once exciting and scary; probably more of the latter.

To compound this, you won’t know how good your service is until you run it in normal and unusual conditions. Therefore, it’s important to test and get performance monitoring tools in place before you launch, as well as a support ticket system, feedback form and web analytics reporting set up.

A soft skill tactic is to build unity within your service delivery team; the people who will run the service. Get them involved with issue and feature prioritization decisions whenever you can. They’ll find it easier to challenge decisions and share their input if they understand and feel respected by the process.

Recognize the value of psychological safety in helping people learn, whether they were involved in the initial service development or not. We sometimes invite new people into our release planning sessions so they understand how decisions get made and can contribute to the discussion.

Minimize launch risks with a small private beta

As we roll a service out to real users, we need to consider how we can minimize risk and maximize the potential to learn and iterate on the service.

Support staff need to be able to cope with users who might struggle to use the service in ways the original team may not have foreseen. Previous users will have to do something differently, and there will be a new set of users who will have to do something different for the first time.

An effective approach we’ve used is to roll out smaller versions or portions of a service to a limited group of people. We call this a private beta. A beta is used to get real world feedback and improve on the service before it’s opened to everyone.

This method helps to build confidence within a team and can help uncover new ideas and improvements.

Choose a launch date and stick to it

As you get closer to launch, staff may get increasingly nervous that the service won’t be ready or will cause problems because it won’t be fully complete.

This makes sense when you consider how these changes will directly affect how they interact with users and the submissions they receive and must process.

I’ve found the MoSCoW method very useful in planning not only the work from the beginning but also crucially, its last few stages.

We’ve deployed services that have been stripped down via MoSCoW to their absolute bare minimum – including removing what could be considered core features – to simply get it out the door. At that point, we start to rapidly iterate and push to Production.

That said, there’s a fine line between “good enough” and “dangerous to ship” that can only be determined on a per-case basis. It takes experience to know the difference.

I believe it is better for team morale to ship when “mostly done” rather than wait until something is “done perfectly”. It will never be done perfectly. This is especially true as users outside the organization start to encounter and try to use it. The service will almost always have to change.

The maximum length of time for a digital service project to go from kick-off to launch is between 6 to 8 months. Anything longer and project fatigue begins to settle in like a dark, heavy rain cloud from which it is hard to escape.

Communicate changes to come, ahead of time

After you know what’s changing with the move to a new service, you should work out whether users need to know about the change before it comes into effect. For example, if they must apply earlier, later or in a different way.

You don’t need to wait until you have all the details before you start to communicate.

Users will have to plan for these changes in advance. Tell them exactly what and when they need to know via a website, news article, support documents, email messages and other targeted communications. Do it in a simple, consistent way.

I’ve found using the government’s main website as the central reference point and directing people towards a single page on it works well.

In summary

The last few months before you ship a new government digital service can be tough. There’s a lot to consider and track from a project management perspective. Dealing with shifting priorities and endless budgetary decisions is constant and wearing.

Even more challenging can be the emotional needs that will often arise from staff. They are ones who will be responsible for operating the new or revised government program through the service. You must get them to buy into the process and feel empowered, and part of the team.

Thus, I hope that the lessons I’ve shared above will help you deliver a service as smoothly, non-stressful and enjoyable as possible.