Guidance for every stage of your project

You must follow governance processes when setting up your project. This includes following:

• Senior Responsible Officer (SRO) guidance when appointing an SRO for your project
• Digital Portfolio Office guidance if your project has an estimated cost of over £5 million
• putting together the strategic outline case for your project as part of your business case - get help putting together your strategic outline case

Designing your service

If you do not have a user-centred design background, speak to a senior designer in the Scottish Government or your organisation before starting your business case.

Some early things to consider include:

• looking at whether you can save money and time by [reusing existing Scottish Government platforms or services](reuse technology article when published) when building your own service
• getting in touch with service teams or organisations who have developed services that have any similarities to yours - they're likely to have user and business insights that will help inform and develop your business case and service

Resourcing and recruitment

You'll need to start setting up your discovery team.

Procurement

If your service is likely to involve procurement of a digital service, or procurement of any digital element or platform, you should get in contact with a procurement officer as soon as you can. Alerting a procurement officer and exploring what support you may need can save you money later in the project.

At this stage of the project, you should:

• not be deciding to procure a specific technology solution
• prototype your service, investigate what works with users and gather their requirements
• look at reusing existing digital platforms or services, where you can, rather than procuring an external solution

There are a number of things you'll need to have in place for discovery, that you'll continue to develop through alpha, beta and live. Get help setting up:

- agile events

- User Research

- Service Design

- Content Design

- testing with users

- prototyping

- measuring the success of your service

By the end of discovery, if you've set up all these things correctly, you'll have at least an outline plan for what your alpha and beta will need to focus on.

Planning alpha

Typically, the discovery for a high number of digital projects will reveal that an ideal service, for reasons such as cost and time pressures, cannot be delivered by the end of beta. 

Therefore, a lot of planning for alpha focusses on what is needed to deliver a Minimum Viable Service (MVS) to users. Your MVS is the key essentials that you must deliver in order for all your users to be able to complete their journey through your service.

Developing a blueprint of your service in discovery will help you to identify and deliver your MVS through alpha, beta and live.

By the time you get to alpha, you should already have a good sense of what the key parts of your service look like, and what you'll need to do to build them ready for live. 

Common issues

A common issue with the alpha phase of a project is that so much work is carried over from discovery that alpha is effectively a continuation of discovery.

This happens when service teams:

• move to alpha before completing discovery, often due to time pressures (this may be unavoidable in a crisis, but you should only move to alpha when ready)
• do not properly set up key elements such as user research or prototyping, meaning discovery work continues into alpha

You should only move to alpha if:

• you have identified your Minimum Viable Service (MVS) and key service parts
• you are refining key service parts with users, rather than prototyping them for the first time
• you are ready to build key parts in code or have clear requirements for procurement
• no major parts of your service still need to be prototyped

If you realise in alpha that you’ve moved to alpha too soon, or something major has changed in terms of your project scope, you should go back to discovery.

Planning for beta

By the end of alpha, a lot of the key parts of your service should be built or nearly built. You can still refine these in beta, but you should be preparing to get your whole service ready to be used by real users, in a limited way. This can be by launching your service to a small group of users in a 'private beta'.

For anything not built and ready to use, you need a plan to build it in beta before private beta.

In beta, you should start rolling out your service to real users.

You should:

• still be iterating your service based on user feedback
• have a plan for how users who (cannot complete your digital service can still complete your service) [link -assisted digital]
• think about how you migrate users from an existing service to a new one
• plan for how the live service will be run and continually improved

You can start out in a ‘private beta’. This is where you invite a limited number of people to use your service. Use their feedback to validate what works, and iterate or plan improvements for what does not.

Once you are confident you can run the service at scale you can move into a ‘public beta’. A public beta means anyone can access your service.

To ensure your service works effectively, gather data to measure its success in public beta. As you collect data, you should use the evidence to iterate and improve your service, or plan iterations as part of continuous improvement of your service in live.

If you're replacing an existing service

Keep the previous service running until your new service moves into its live phase. This helps to manage risk and reduces the impact of any issues on users.

Planning for live

Planning for live should be included in your business case. Your plan should include:

• an estimate of the staff and budget needed, not just for maintenance, but for continuous improvement
• what ongoing tech and cyber security support you’ll need

This is also an opportunity to use systems thinking. Systems thinking helps solve problems by considering the whole system and its individual parts. You can scale up successful elements or reuse them in other parts of your organisation. The Digital Scotland Service Standard ‘Use and contribute to shared digital practices, processes, components, standards, patterns and platforms' contains information on how you can do this.

The live phase is when your service is operating in a business as usual (BAU) manner. It’s where you spend most of your time and money. 

The purpose of live

In live, you refine your service. In beta, you decided how to sustainably run your service and now live is where you build on it. A sustainable service is one that has a plan, performance data and the right resources that allow for improvements throughout its lifetime.

Resources could include:

• staff for ongoing support
• design support, such as user researchers and content designers
• help for users who cannot access your digital service

At the start of your live phase, you should know what continuous improvement is needed, what budget you’ll need and your plan for resourcing these requirements.

Improvements can also include things like:

• adapting to changes in user behaviour
• responding to technical problems
• making the service simpler to use

The live phase is about going further than just essential maintenance, for example only fixing bugs and updating software. If you only fix issues as they arise, your service will accumulate technical and design debt. This means small usability problems will build up, making the service harder to maintain and use over time.

You should also:

• have a plan for continuously getting user feedback in the live phase 
• do this through activities like asking for feedback on your site’s pages and usability testing 

You should be measuring the success of your service and deciding where to focus your improvement work using indicators like performance metrics, user feedback and web analytics. 

Continuous improvement

Ideally, your live service should aim to meet the Digital Scotland Service Standard. These standards can also help you identify areas of improvement for your service in the future.

Change is inevitable and services must adapt. Good continuous improvement means making small improvements regularly. This approach helps avoid the need for large scale transformation projects in the future.