What to do at every stage of your digital project
If you're working on a large digital project, there are a set of tasks you should complete to make sure your service:
- works well for users
- meets the Digital Scotland Service Standard (DSSS)
Large services or projects are typically those who serve a large number of the Scottish public. Your service will likely have a budget of at least £250k. Smaller services, with less budget, should follow a simpler set of tasks.
Getting set up
You must:
- appoint a Senior Responsible Officer (SRO) to your project
- follow Digital Portfolio Office guidance if your project has an estimated cost of over £5 million
- put together the strategic outline case for your project as part of your business case
- start looking at the roles you’ll need in your team
- complete a risk potential assessment
- complete a benefits management plan
Discovery phase
You should:
- develop a blueprint of your whole service, including any offline user journeys
- start researching your users and testing prototypes of your service with them
- check your prototype meets accessibility standards
- set up agile events so your team can collaborate effectively
- check your technology options
- work out how you're going to procure something, if you need to
- work out how to measure the success of your project and your service
- plan what you'll need to publish about your service and how you're going to do it
- plan how your project will manage data - use the data management plan template to get started
- have a plan for raising awareness about your new service and migrating users from existing services, if you need to
Planning for your alpha phase
You should focus planning for your alpha on what you’ll need to do to deliver a Minimum Viable Service (MVS). Your MVS should be a balance of what:
- your users need
- the technology is able to do, given potential constraints around time and affordability
- objectives need to be achieved by your organisation
Typically, some level of compromise between these areas will be needed.
Alpha phase
In alpha, you should build your MVS. This includes:
- building the key parts of your service and testing they work with users
- refining and iterating prototypes of your service - your MVS should already have been tested and iterated with users in your discovery, so alpha prototypes should focus on continuous improvement or testing non-MVS parts of your service
- have been through the procurement process and started drafting your user acceptance testing strategy
Common issues to avoid at this stage are:
- waiting until alpha to set up key discovery elements, such as prototyping or testing your prototype
- if you've identified a procurement need, not opening up your procurement process early enough to get the most cost-effective solution
Beta phase
By the start of beta, a lot of the major parts of your service should be ready to be rolled out to users.
You should start this roll out in a ‘private beta’. A private beta means launching your service to a limited number of users, analysing data and using user feedback to validate what works and iterate what does not.
From your private beta, you should move into a ‘public beta’ when you're confident your service is ready. Having a service in public beta means that anybody can access your service.
If you're replacing an existing service
Keep the previous service running until your new service moves into its live phase. This will give you time to make sure your service is working correctly before making your service the only option for your users.
Planning for live during beta
Your plan for live should include an estimate of the staff and budget needed not just for basic maintenance but continuous improvement of your service. Your plan should also include a prioritised backlog of improvements to work from.
Live
In live, you should continuously refine and improve your service.
To do this, you'll need access to the right staff, such as user researchers, content designers, developers etc.
You should know by the end of beta what initial improvements are needed over the first 6-12 months of live.
Ongoing improvements can include things like:
- adapting to changes in user behaviour
- responding to technical problems
- making your service simpler to use
Ongoing improvement is necessary to stop your service accumulating technical and design debt. If this debt becomes too high, your service will become outdated and a major project will soon be needed to update or replace your service.
To help keep your service up-to-date, you should continuously get user feedback through activities such as asking for feedback on your service's web pages and through usability testing.
You should also regular monitor your service's key metrics for any signs of user issues.