Preparing to deliver an outcome with a DOS supplier
We’ve blogged previously about digital opportunities and ways to engage the market to make sure your procurement gets the best pitches from the most appropriate suppliers.
We’ve developed our thinking on this through lots of conversations with other suppliers and with buyers. We’ve also drawn on our extensive experience of going through the procurement process as a supplier to inform our understanding.
We think engaging the market early is a really good way of ensuring the best possible outcomes and value for money. We put this into practice by giving a bit of our time to speaking to teams or organisations who are thinking about bringing a new project to market when they ask for our help.
Oxford City Council
A couple of weeks ago, we met with Neil Lawrence from Oxford City Council. Neil’s been working tirelessly to put together a bid for the new Local Digital Fund that MHCLG have opened up. When we met, he’d been collaborating with 8 other local authorities. This climbed to a whopping 14 in the week before the application went in.
Neil’s written about the things he took from our conversation which are rightly focused on the thinking he did as he prepared to apply for funding and take a project out to market. We wanted to share some more general thoughts to consider when you’re preparing to start a new project, whether you’re building in-house or finding a supplier to deliver an outcome.
Shared purpose is crucial to success
Even if your project will involve a single organisation and a single supplier, it’s important to start the project with a common sense of why you’re doing the work and what you expect the project to achieve. This conversation should involve everyone who is going to have responsibility for some, or all, of the project. That includes stakeholders outside the delivery team.
Without this, there’s a risk that during or after the project things slow down or stop because there’s disagreement about whether the work is delivering what it should be.
This conversation also helps build momentum to take the team into the first weeks of the project. It gives you something that articulates the scope and focus of the project to the whole organisation (and beyond, ideally).
Iteration is harder in practice than in theory
Teams working in an agile way using user centred principles will be working to get whatever they’re working on in front of users as soon as possible. For organisations less accustomed to this way of working, this can be really unsettling, because it feels like giving users something that’s knowingly unfinished.
It’s important to communicate openly and regularly about this way of working and what it means in practice: that the first thing made available to users will change iteratively and incrementally as the project progresses, and this is expected and desirable because it helps ensure that the highest value work for users is prioritised.
When this isn’t sufficiently well understood, it can generate concerns about impact. This can either be because stakeholders expect the service to have the desired impact from the very first time a user sees it, or because stakeholders worry that the promised iterations won’t come, and they’ll be left with a minimal service indefinitely.
The suppliers you choose to work with should support you with communicating this through their working practices and their own ongoing engagement with the stakeholders within and around your organisation as part of delivering the project with you.
Honesty is the best policy
It’s tempting to get the support of the right people in your organisation by assuring them that the project will operate in a familiar way to past projects. If this is your organisation’s first agile or user centred project that’s unlikely to be the case. It’s important to surface that early so that you can have open, pragmatic conversations about how to handle necessary things like budgets and reporting before the work starts.
It’s worth approaching this in as collaborative a way as you can, thinking about different perspectives. Whilst a delivery or digital team might be quite comfortable with the idea that a discovery will mostly deliver problems to solve and answers to questions, colleagues in finance, risk, or operational teams might not expect that.
There are always more problems to solve
When a project is focused on an area that hasn’t been historically prioritised, or a delivery team is functioning well and delivering an alpha or beta at pace, it’s tempting to broaden the scope of the project to include related, equally important things.
Avoid this temptation. Expanding the scope of the work always involves trade-offs. If you widen the scope, the resulting outcome will have less depth. If you choose to change the scope to dig deep into a particular aspect of the problem, it won’t reach as widely as it might have done.
There’s a fine balance. Sometimes it’s right to change focus, but try to think of this as a shift rather than expansion to avoid diluting the power of the outcome or overstretching your team.
It can also be tempting to start multiple projects that run in parallel, to cover all of these related problems. This can be particularly tempting because funding two or three discovery projects is often a viable option on the surface.
However, each discovery project will identify some problems to be solved and some options for alphas. Those will cost more than a discovery, and will likely need larger teams with a different range of skills. There’s also the risk that you’ll have the same problem on a larger scale if multiple parallel alphas become multiple parallel betas.
Thinking about what happens after this project before you start reduces the risk that you’ll need to put things on hold almost as soon as you get people excited about fixing them, and can mean you feel like you’ve spent money for nothing. This has a knock on impact to how easily you can demonstrate the value of agile, iterative, user-centred working practices to others in your organisation.
Think about value early and often
Value is important for every public sector team (and almost all product teams in all sectors). Value can mean financial value, either in terms of a return on the investment in the project or through increasing efficiency and saving time or money in how a service is delivered. Value can also mean less tangible but equally important things like reducing the emotional strain involved in using a service that’s related to difficult life events or experiences, or raising the visibility of services that support social value in communities.
The ideal is a thread of well understood and articulated value that follows a project from discovery through to a live service. Investing time and effort in a good Discovery, being clear about what you want to learn or prove in an alpha, and releasing a beta early and iterating it often based on short feedback loops with your users are good ways of doing this. In a future post, we’ll talk about some ways we’ve found of getting the most value from the Discovery phase.
If you’re thinking about using a supplier to deliver your next project and you’d like to chat through what you’re thinking before you do, get in touch via email, tweet us @dxw come and visit us in London or Leeds, or join us at UK GovCamp in January!