Building or re-designing a digital service is always a big undertaking, and you are usually required to pull together a business case for it. Which is fair enough.
The answers and insights from a Discovery phase can be extracted into your business case with demonstrable thought and rigour.
DIGITAL SERVICES FOR UK GOVERNMENT DEPTS AND AGENCIES
If you are a UK Government department or agency your case will need to demonstrate how your service will achieve the Digital by Default Standards. Government Digital Services (GDS) will want to see this if you require their approval for the service.
And even if you aren’t a UK Government department or agency (or subjected to GDS approvals), you will still need to make the internal case for financing a digital service.
This post’s advice is mainly for the scenario of re-designing an existing digital service, but still relevant if you’re building a brand-new digital service, perhaps to improve on a current offline, manual process / service, e.g. submitting a paper-based order form application.
But first things first…
REASONS NOT TO BUILD A SERVICE
I know you are keen to build something great, but let’s take a minute to look at why you should NOT build a digital service:
- it costs money, lots of it – a big upfront cost to build it, and an ongoing cost to maintain it
- can take a long time – half a year by the time you’ve procured a supplier, run a Discovery, built an Alpha, and then a Beta
- it will be a big distraction for your in-house colleagues from their other priorities
- never a silver bullet – building something new won’t automatically resolve other issues around resources, internal process, skills and governance
A good business case considers and articulates each of these reasons carefully. And a good Discovery phase can give you just what you need.
PROVE THERE IS A GENUINE AND SIGNIFICANT USER NEED
Assuming there is a user need for your proposed digital service is no longer good enough. The Government’s Digital by Default Standards are very keen on this. It is Standard number one on the list!
Fortunately, a good Discovery will get you to the heart of this question… and a combination of these activities will help you to explore, identify, and validate the user needs:
- explore and define the service’s audience (called user types)
- run usability testing with real target users on the existing service
- analytics review – most un/popular content, top search terms…
- interview current and prospective service users
- talk with people in your organisation that have direct contact with the service users, e.g. call centre staff
- develop personas and user flows for the primary user types – with direct input of actual users
- run user surveys to validate user needs with a larger, quantitative sample
The GDS Service Design Manual has fantastic guidance on how to perform all of these activities.
By the end of the Discovery phase you will have these valuable outputs to work with:
- persona profiles that articulate the context, needs, motivations, and behaviour of the service’s target users
- analysis of web stats and user surveys with extracted insights and recommendations
- a prioritised backlog of user stories to articulate which needs the service must meet
Once you have done this initial round of intense user research during the Discovery phase you need to subject your findings to a bit of a grilling:
- how many people (users) actually have these needs, and how often? Is that enough to worry about or to be a priority?
- are these needs really more important than other user needs you know about (perhaps met by other services)?
- are you already meeting these user needs on the current service? It might be doing a better job than first thought or just needs some tweaking
- is it really for you to meet these needs?
- are these needs already being met by someone else?
It is really hard not to be biased at this point, especially when you are getting answers you might not want to hear. But these are the sorts of questions you are going to be subjected to later, so better to get it straight now.
CONSIDER HIRING IN SOME DISCOVERY EXPERTS
Some teams like to run the entire Discovery in-house, but bringing in experts, such as seasoned user researchers, can be a great return on investment:
- they have the skills and experience to get the most value out of each Discovery activity
- give an independent and objective voice can win over internal skeptics (and are harder to ignore)
- give full focus to the Discovery (which is hard for in-house teams with their other responsibilities)
- quickly cover all the activities in a comprehensive Discovery
- advise you how to approach your business case
IS THERE SUFFICIENT USER NEED TO PROCEED?
By the end of the Discovery you should be much clearer on the user needs for the service and whether they are a sufficient priority.
If they there is little user need and / or it isn’t a sufficient priority then you shouldn’t proceed to an Alpha.
Don’t see that as some sort of failing – it is a good thing. You will save a lot of money, time, and general heart-ache on a service that isn’t justified.
And if there is a genuine and sufficient user need, you can be confident to proceed to an Alpha with user-centred gold to work into your business case and wider communication of the project.
MAKE THE FINANCIAL CASE
Most things boil down to money, so a good Discovery needs to begin to answer these questions:
1. HOW MUCH DOES THE CURRENT SERVICE COST US?
Talk to the people that run the current service to get some numbers against these items:
- licenses – for the CMS or other propriety software the service is dependent on
- hosting
- supplier and contractor fees for maintenance and updates – do you make one-off requests and payments or have a support contract?
What about offline services?
If the current service is an offline, manual process such as a paper based order form service, you should still find out what it costs to operate. Mail costs? Staff time to process the forms?
2. WHERE CAN THE SAVINGS BE MADE?
Once you know what you are spending money on for the current service (and how much) you can begin to explore where and how savings can be made. Examples might include:
- we won’t continue to pay expensive licences (with a move to open source software or to cheaper cloud based tools)
- we can significantly reduce our current hosting fees by switching
- our in-house Tech Team will be able to update the service’s functionality (instead of paying our current expensive supplier)
- staff will find it much simpler to update content which saves time
What about offline services?
Again, focus on which bits of the manual service will no longer be required or could be scaled back by introducing a digital version of the service.
3. HOW MUCH MONEY COULD WE SAVE?
It goes without saying that it is better to put some numbers against these claims to show evidence for your case.
So ask these sorts of questions during your Discovery and remember savings aren’t just measured by the dollar:
- how much quicker could it be for users to complete common tasks on the service? (run usability tests to explore this)
- how much quicker will it be to update and publish new content on the service?
- how much quicker will it be to make functional changes to the service?
- how much will we save if we don’t need to pay for these licenses (opting for open source technologies for example)?
- are we paying too much for our hosting?
You will struggle to be specific at this point because you don’t know yet what the new service which actually be, but you will start to see patterns of what seems unreasonably high and what to focus on in the business case.
TAKE THE TIME TO BENCHMARK THE CURRENT SERVICE
If it is difficult to update and publish content on the current site, consider observing and timing this so you have a benchmark to retest against if you build an Alpha and Beta service.
I worked with a client that timed (benchmarked) how long it was taking for staff to update content on the digital service. It was a painfully slow process.
They already knew how much it cost per hour to employ their salaried staff at each band, which meant they were able to calculate the monetary cost (waste!) of content updates. Quite a lot it turned out. That went straight into their business case.
You could also record the time it takes for users to complete common tasks on the current service when you run usability tests.
Word of caution: asking people to perform tasks they are familiar with will skew things. They will have overcome their initial stumbles and make the service user experience look better than it actually is.
Watch out for that and try to test with people who a unfamiliar with the existing service.
Calculating cost per transaction for your service
GDS like to measure the cost per transaction and then monitor that over the life-cycle of the service. Their guide tells you how.
This is a killer metric for a business case if you can demonstrate (with some working out) the anticipated saving a new service will bring.
4. HOW MUCH MONEY WILL THE SERVICE COST TO BUILD AND MAINTAIN?
Realistically you can’t possibly know the answer to this question yet. You still don’t know what the service actually needs to be. And won’t have a really good idea until you have built an Alpha.
But consider this: building a new service and maintaining it properly always costs serious money. As soon as you engage outside experts the bill will start ratcheting up with day rates for digital specialists ranging from £500 to 1,000.
Talk through your Discovery findings with some potential suppliers and they will be able to give you a stronger steer on the price to proceed to an Alpha and Beta. You can then work that into your business case.
PROVE YOU WILL BRIDGE THE GAP TO THE DIGITAL BY DEFAULT STANDARDS
This is for all you UK government departments and agencies that need to meet the all important UK Government’s Digital by Default Standards.
It will be much easier to make the case for spending money on a redesigned service if you can prove that your current service is not meeting those standards. In fact digital services must meet these standards to get Cabinet Office funding approval.
This falls into two parts:
PART A – proving your current service doesn’t meet the Standards (and being clear which Standards it fails against)
PART B – prove that a new service will meet the Standards
We’ll look at both parts…
A NEW SITE DOES NOT EQUAL MEETING THE DBD STANDARDS
A recurring mistake over the years has been to assume that building a new digital service will solve all the current issues associated with the current service. It never does.
To be frank: you don’t have to build a brand new service to meet many of the 18 DbD standards. It is often better that you don’t.
Take this example: Standard #3 – ‘Put in place a sustainable multidisciplinary team that can design, build and operate the service, led by a suitably skilled and senior service manager with decision-making responsibility.’
During the Discovery you can easily identify that such a team does not really exist. It will be apparent that no one has formal ownership of the existing service, and a light content audit will reveal that much of the content is also unowned (and not sustained).
It will be obvious that the service is failing against this standard. That (starts to) answer Part A of our question.
So then we must think about how the service can meet Standard #3. This is Part B.
And we can do that with a few simple recommendations at the end of our Discovery phase:
- assign a service manager to the service ASAP – “John R would be the obvious candidate. John would need this formally adding to his job description for ~20% of his time.”
- identify and approach subject matter experts to own the content marked as “not owned” in the content inventory. They should be strongly encouraged to review the current version of their content to ensure it is accurate and up to date
- train the team how to better maintain the current service, e.g. how to properly use the CMS it is built on
None of these recommendations require technical changes or a new version of the service.
A good Discovery will potentially reveal many “quick(er) wins” you can implement before you engage in a much larger, expensive redesign and build project.
That might mean you can spend this year’s budget on something more pressing, but still make big steps to improve the service.
So exhaust your “low hanging fruit” first and tell that story in your business case. Demonstrate that you aren’t naively throwing money at some silver bullet solution.
PROVE THE NEW SERVICE CAN BE SUSTAINED
Building a digital service you can’t sustain longer-term is an expensive, time wasting, reputation damaging, and demoralising own goal. Great.
But if you take the time to ask the right questions about your current service (and your other comparable services) you will be able to largely predict your ability (or not) to sustain a new service.
Use the Discovery phase to dig around these questions:
- does the service currently have a service manager (or equivalent)?
- are they [the service manager] pro-active? Is it in their job description? How much time can they dedicate to it?
- do they and the wider team have the necessary skills to run the service?
- is the content in a good state (accurate, relevant, up to date)?
- does all the content have assigned, and pro-active owners to maintain it?
- does any sort of content review and archiving policy exist?
- will there be additional resources available to support the service? Any upcoming recruitment round planned?
- will more services be introduced / decommissioned that will affect the resourcing for this service?
- is the service’s analytics being regularly reviewed (a basic install of Google Analytics is not sufficient)?
If you are struggling against any of these with your current service, something will need to change for the new service to meet the Standards.
Building a new service will NOT solve underlying issues around sustainable governance.
Pull through these insights from your Discovery into the business case. Demonstrate your grasp of this challenge and what you intend to do about it to ensure any new service can be sustained.
Steps could include:
- employ a dedicated service manager to lead the build phases and take ongoing ownership in Live
- implement a content review policy with dedicated content owners
- implement an evaluation plan with KPIs to monitor and improve the service
CONCLUSION
When you submit a business case for a digital service you are putting your reputation on the line. You are staking a claim about the need for a new service and proposing the outline of a solution.
You are asking your organisation to commit money, time and focus on this project.
You really don’t want to get this wrong.
Taking 4 to 8 weeks to run a thorough Discovery that digs into everything we’ve briefly looked at here will give you that extra confidence.
You will test and rehearse your own arguments before putting your head above the parapet.
And most importantly, you will all be working towards the right thing.
