Developing and supporting an online service – can you do both simultaneously?
We live in a real world with blurry lines that sometimes prompts us to change the way we deliver projects
We’re delivering a unique public beta project for a government client. After building the application from scratch, we’ve successfully shifted to supporting the live service while we continue to develop new features during an ongoing beta phase. This is quite unusual. While ongoing iteration in response to user needs is the right thing to do, digital public services don’t tend to require significant development after their transition to live.
We’ve learned many lessons from planning our delivery model and today I’ll share some of them.
Agile delivery phases – how are services usually built and supported?
If you work with digital public services, or agile delivery in general, you’ll be familiar with the phases that digital products and services move across. These phases mean you can continuously design, build, test, and iterate the service based on user needs. They help us progress quickly from exploring user needs, prototyping potential solutions, and building minimum viable products to developing a fully functional service available to users.
There’s often a clear distinction between the building phase and the “service is done and we’ll support its running from now on.” phase. The transition from one stage to another is marked by the end of the beta and the beginning of the live phases. The same provider can deliver from start to end, or a handover to a different company may be required along the way. This makes the cut off between building a service and supporting it once it’s done even more distinguishable. But…
Can you concurrently and significantly develop a digital public service while already supporting it?
Yes! We live in the real world with blurry lines that sometimes prompt us to change the way we deliver projects to maximise the value for clients and their users. Especially when it comes to digital public services. It’s not that common but, occasionally a client might have the budget to carry on developing the application after a fully functioning product is made available to users at the end of public beta.
From a delivery point of view, this can create an unusual situation when an agile team prepares to finish the public beta phase and shift the application to support, alongside planning the next development round. And these 2 very different stages can be just a couple of weeks apart (or even concurrent).
Combining active development with application support can seem a bit complicated. That’s because it is! How could it not be, since it pushes you to hand over something that’s meant to be nearly done, while acknowledging there’s loads more to develop and making that happen? At a basic level, for example, it isn’t always straightforward to distinguish if a request coming through falls under service support or constitutes a new feature to develop. Regardless of the complexity and challenges, as our experience shows, it’s feasible to make a service go live and support it with continuous development.
How to plan for simultaneous application support and development (what we’ve learned)
Be agile
A good starting point when faced with an unexpected delivery model is being prepared to be creative, flexible, and learn on the go. Basically, you need to be agile, not just do agile! From early on, it’s important to treat the development and application support packages as 2 separate, but interconnected projects, each with its own team. And even contracts and account managers or Delivery Leads, if possible. This helps set boundaries around what falls under the scope of building additional features versus what fits within the support package to keep the application live, secure, and maintained.
Keep focussed on users
Another consideration is to keep the users and their needs at the forefront of planning and delivery. When charged with the complex delivery of a project, let alone multiple projects at the same time, it can be easy to get caught up in focusing on the process and its efficiencies, rather than people. That includes both team members and the end users. Linked to this is the core need to anticipate and plan for the application downtime for support and feature development activities, which limit user access. Plan carefully to avoid disruptions and remember, always focus on people over processes!
Open and honest communication
Value and maintain open and honest communication with the client and team at all times. It’s essential to be clear on the roles, risks, and costs to deliver the development and application support, as well as the different delivery model for both. Having a strong client relationship is crucial, because by trying new things and learning on the go, you’ll come across challenges and reveal gaps in the usual delivery process and beyond on both sides. Mutual trust to do the right thing even if it’s hard, helps when unpredictable things come up. And they always do, no matter how much you plan.
It’s challenging but possible
Let’s sum this post up… as our experience shows, despite the challenges, it’s possible to simultaneously support and develop an application. Sometimes it’s simply the right thing to do for the client and users – you need to find ways to make it work.
Supporting an application while also considerably and continuously developing it is a complex and challenging process – technically and from a delivery perspective. We’ve shared some of our initial delivery lessons learned and we expect there to be much more that we learn and pass on in future. But for now, we’d love to hear about your experience and learnings if you’ve encountered similar circumstances.
