Ten things I’ve learned about getting services to live

The project doesn’t end when the service goes live, although it can feel a bit like that

Since I’ve worked at dxw, I’ve led 3 projects where the team have been involved in successfully getting a service live:

When you’re in the middle of delivery you don’t always have the time you need to stop, reflect, and capture the things you learn. But it’s a really valuable thing to do. Having recently got the third of these services over the line, I’ve spent time reflecting on what I’ve learned.

It may sound obvious but I think it’s important to mention first, that…

1 – Your team is instrumental to the delivery of a product or service

We work in multidisciplinary teams. This means there’s often just one person representing a specialism. So having trust in individual team members, in the decisions they make, and the work they do is essential. We’re fortunate to have a wealth of expertise across all disciplines at dxw, which makes trusting one another easy.

The make-up of a team varies on each project. The team shape may not always be ideal or what you expect. This leads to my next lesson learned, that…

2 – Collaboration is essential

The ability to collaborate is core to an effective team, and effective delivery.

On all 3 projects I found that solving problems in collaboration is much easier than on your own. This was the case on the Judiciary’s single sign-on, when it came to solving technical challenges.

Team members often have multiple skills which can help with collaboration. On the DfE Teaching Vacancies project, the service designer, designer, user researchers, product manager, and developers found very effective ways to make collaborative design decisions.

User research is a good tool for team collaboration. Involving team members in research sessions who don’t have a direct responsibility for research, makes it easier to make collaborative decisions.

Collaboration is essential to a team of any size. But however large your team is, it’s vital to remember that…

3 – You can’t do everything

On all 3 projects there were concerns about the ‘completeness’ of the service before making it live. We’ve blogged about the importance of adding value early and often.

There’s often a reluctance to put something live when it doesn’t feel like it’s complete. Stakeholders and teams can be concerned about the reputational risk of putting a service live that will continue to develop, for the valid reason that it may confuse the users of the service.

Firm deadlines may limit what can be achieved before a service goes live. In such instances your product manager should guide the prioritisation of what should be done.

Concerns about doing everything often happen when someone is involved in an agile project for the first time. Agile principles are helpful when this is the case. Or ideally you start to build confidence about your approach among stakeholders and the team incrementally, for example by holding a regular show and tell or coaching team members.

One thing that prevents you from doing everything is…

4 – It’s easy to forget things

There’s always lots to do, whatever size the service is. In addition to designing and developing the service you need to find time for completing other things, like accessibility testing, preparing for a service assessment, completing a penetration test, or implementing a support model.

Writing things down can help, but not always.

It’s important to have the overall vision of what you want to achieve at the forefront of your mind. This will help you remember the most important things that have to happen to achieve the vision.

It’s a good idea to share the load among the team, know who is responsible for what, and have a simple way to track progress.

It’s helpful to use the standards available to you. Standards such as the government service standard or technology code of practice or in the case of DfE Teaching Vacancies, the job posting standard. These standards are there to help you do things in the right way. They make it clear what you need to do and it’s easier to remember the important things.

Another way to avoid attempting to do everything, or over-promising, or building too much, or forgetting things, is to…

5 – Keep a tight grip on the scope

Agree the high-level scope during the project inception, so you know what can be done in the number of sprints you have.

Sprint planning is an opportunity to define the scope further. A project lead, along with their team, needs to stand firm on the scope. Staying firm can be hard, especially when stakeholders would like new or additional things. It’s not to say things can’t change, but you need some evidence to determine why and how the scope should change.

Something that can make keeping scope under control harder is…

6 – Unexpected challenges

On every project things pop up that you’re not expecting.

On all 3 projects we faced challenges when it came to integrating the service we were building with other services.

There can often be practical challenges too. These could be related to team changes, getting the budget you need in time, the support you need from senior stakeholders, or being able to recruit research participants within your timescales.

You can’t plan for everything.

I find it helpful to identify potential dependencies or unknowns early on during the project inception. Knowing which dependencies are time dependent helps too, and when you need to know the answer to the unknown things. I identify when certain backlog items need to happen by, to prevent them from becoming challenging, or blocking other things from happening.

Getting to the point where a service is ready to go live is an achievement in itself. A lot of effort goes into getting to that point. I’ve found on all 3 projects that less time goes into thinking about…

7 – What happens once a service goes live?

The project doesn’t end when the service goes live, although it can feel a bit like that.

It’s hard to know exactly what will happen when a service goes live, and to be confident the service will perform as you think or the experience for users will be as you expect. So planning for a live service can be tricky.

On the Hackney Council project, 2 things helped a lot with this. First, setting up a daily standup when the service went live to allow key people to discuss how things are going. Second, having a simple and visible way to track any user or technical issues that arise.

You also need a way to fix problems quickly and respond to users. This is something that doesn’t need to be set in stone in advance, and should iterate once you’ve learnt more about how the live service operates.

It’s not until after something has gone live, or some time in the future that you realise that…

8 – You make a big impact

The impact may be improving the users’ experience, or to an organisation by making their processes more efficient. Or even better, both.

Sometimes it’s hard to see an impact straight away.

You need to give a new service or product time to embed and be used, before you judge how well it’s meeting user needs and how it may need to be iterated. We’re good at this at dxw. Our teams will closely monitor a new service to see how it performs, and will make evidence based decisions about what may need to change.

9 – It takes time to adjust to something new

On all 3 projects, members of the permanent team felt unsure about how the new service would impact on their current ways of working. As a delivery partner, our intention will always be to make processes easier and simpler. However, learning a new way of doing things is a task in itself. It’s hard to change how you provide a service to users overnight. So it’s vital that there’s a mechanism in place to support the people who will be responsible for administering the service.

It may also take time for users to adjust and adopt a new service. Clear communication to users and providing a service that has visible improvements helps.

My final point is important and is easier said than done…

10 – Stay calm under pressure

As a lead on projects, I need to do this but it can be difficult sometimes! On each of these projects the team has created a calm environment for themselves.

It’s pretty important to find a mechanism or a person that brings calmness when the pressure’s on, because you’ll perform better and the process will be more enjoyable. It’s often someone from a different discipline who can be a calming influence.

Although these learnings are all common for the 3 services I’ve worked on, that doesn’t mean the next service will be the same. For me, ultimately, it’s about learning from what I’ve done, but also being prepared to learn new things for the next time.