We (the portfolio management team) have been asked a few times lately about common pitfalls or reasons that digital spend requests might be rejected.
It is actually very easy to respond to this as it’s almost always down to the initial discovery phase not being robust enough.
Discovery in basic terms is just about ensuring that you’ve got enough evidence to support the development of your proposition and then demonstrating the steps you will be taking in order to make it a reality.
There is no standard for discovery phases as the detail required will vary according to the nature of the project. This means that despite requests, we can’t develop a one-size-fits-all template. Instead though we can help by giving a steer as to the sorts of things you should be exploring.
This blog post outlines the six main areas that we talk about most often and provides links to additional resources where appropriate.
By the end of your discovery phase, you should expect to understand and have documented the following:
1) End-users
- Who they are - the different groups of citizens that will access your service, their defining characteristics (demographics, motivations, attitudes, behaviours) and approximate number of people within each group. You should also make sure that you include the proportion of users that will require assisted digital support.
Personas are a useful way of capturing this information. A persona is a short description or biography of a fictitious user that defines each group. They provide clarity and focus for the duration of the project and ensure that everyone remains aligned from those responsible for design and development through to those responsible for marketing and communications.
- The needs they have – The requirements that each user group has for your service. This should include the needs that certain users will have for assisted digital and/or non-digital channels.
Userstories are the best way to summarise your findings. Whatever research techniques you employ to find out the information, this should be the output you aim for.
Your list of user stories should then be prioritised to inform the development schedule.
- Current fulfilment of needs – the way users are currently doing what they need to do and how successfully they’re able to do this.
User journeys document the paths that users take in order to do what they want. They’re a useful way of understanding the different touch-points or interactions and will reveal any gaps or potential overlap with other services.
2) Context
- Your business- what the mandate or high level objectives are for your organisation and how your project aligns with these. Who each of the key stakeholders or stakeholder groups are and the requirements they have for the service.
- Policy priorities – the current, health and government-wide policies that are relevant for your project and how your project delivers against these.
- The health and care system – what the needs of the rest of the system are for your project (this could be the Arm’s Length Bodies, NHS Trusts, local government etc) and how your project links up with what’s already available.
3) Current offering
- Content audit – an inventory and evaluation of the information and user figures of your current website (where applicable) which outlines the changes needed to improve the overall performance.
- Technology legacy – a list of all the commitments in terms of contracts and licence agreements. This should, at a minimum, detail end dates, contract periods and costs including the cost of decommissioning any existing sites or services.
- People – a list of all the people and roles that are involved in the current offering, where they’re located (team, region, organisation) and how the service operates.
4) Learnings from others
- Any organisations that have done something similar; other government departments, other sectors, other countries. What they have learnt and where appropriate, what technology they have which could be licensed or re-used (versus building something from scratch). It is also important to show that your offering will not be duplicating anything that already exists.
We recommend that you share your plans for discovery with us as we might be aware of other complimentary or contradictory projects going on elsewhere, The regular health ALB digital leaders group is another useful forum for sharing ideas and identifying opportunities for joint working.
5) Desired situation
- Options analysis – a detailed understanding of the different approaches or technology solutions that meet the user needs identified. You should identify your preferred option and have sufficient rationale for why this is the case.
You should be able to explain both for the development phase and for the service after it has launched:
-The operating model – the main processes and procedures that will be deployed. Consideration as to how your internal team will work with the development team will be important here.
-The team structure – the main roles required both in-house and externally. It is particularly important to identify a designated service manager who will be responsible for the day-to-day decision making after launch. (It is worth noting that GDS run regular, and in-depth, service manager training sessions).
-The costs - both for the development stages and for the ongoing maintenance. Development stage costs in most cases will be broken down by sprint and by the roles/ capabilities required to deliver them. Running costs should include any licences, hosting, support and so forth. We recognise that you may still have some unknown costs at this stage so please state this where appropriate.
-The procurement route – the process you’ll be employing to appoint a supplier. In most circumstances the Digital Services Framework or G-Cloud will be used.
Some of the above may change as the project progresses but it is important that you have some understanding up front so that you don’t have any nasty surprises!
- KPIs – You should start to define your goals and have a plan in place for measurement. The current offering will provide useful benchmarks for you to include. Uptake of the service will be particularly key here.
6) Project plan
- The plan itself – that shows how you will make your proposition a reality. This should outline the time periods for the different development phases (i.e. alpha, beta, live), the number of sprints and the periods of user testing.
- Alpha phase – detail about your outcomes and objectives (i.e. which user needs will be prioritised for this stage), timescales, costs, team structure for this development phase. This overview of an ideal alpha is useful for additional context
Whilst it’s essential for the due diligence to be carried out and documented, you will not need to include all the detail within your spend request. A brief summary of your findings is generally recommended although you should be prepared to expand on this should we (or GDS) have any additional questions.
If you would like to understand any of these points further, please let us know. We’d be very happy to provide more detail and are always on hand to respond to any queries.