Whether you are a current supplier on the DOS framework or you are planning to become one in future, we strongly recommend you check out two crucial documents: the Government Service Design Manual and Digital Service Standard. You will have to adhere to these as a supplier!
Unsurprisingly these documents are not a 5-minute read. As we mentioned there are 18 standards, the Manual consists of eight parts and each part has numerous sections. In this blog we will cover one of the most important standards and sections we feel Digital Outcomes and Specialists suppliers should pay particular attention to: point 4 of the Digital Service Standard ‘Use agile methods’ and the corresponding Agile delivery.
What are these documents anyway?
The Government’s Digital Service Standard came into play in 2014, it was created to help the Government create user-focused digital services. All public-facing services must meet the Digital Service Standard. The Service Standard originally contained 26 points but feedback from various departments meant that it was revised to just 18 in 2015.
The Service Design Manual is aimed at helping government teams create and run great digital services that meet the Digital Service Standard. The Manual is basically a set of guidelines that provides a shared understanding of how to go about achieving digital transformation that meets the set standards. This in turn ensures that every new or redesigned service is of a consistent and high quality.
Why is agile better for Government services?
As a supplier on Digital Outcomes and Specialists, it will be important to understand what it means to work in agile stages, specifically in: Discovery, Alpha, Beta, Live or Retirement stage.
DOS is a framework for agile delivery and if you cannot go agile or don’t understand how it works, chances of winning business are close to nothing.
Agile is by no means the only way to do things, but using an agile approach for Government services makes sense because:
- Technology is rapidly advancing
- Policies are amended and updated frequently
- User needs change and evolve
What happens at each of the phases?
Discovery Phase
The Discovery phase is the bit before you start building a service. You need to gather your user requirements and find out what other services exist. In Discovery, you start to map out your user journey by researching who your users are, the people you’ll need to deliver the service and any technical requirements you might have.
The Discovery phase usually takes between 4 – 8 weeks and at the end you should have the broad scope of your project, have your user needs and know what your minimum viable product (MVP) is.
Alpha Phase
The Alpha phase is the next step from Discovery. The Alpha phase is all about building your MVP from identifying the potential risks of your service. By the end of the Alpha phase your team should be happy that moving onto the Beta phase will work.
However, you may find that at the end of the Alpha phase you decide that the service should not progress to Beta because:
- User needs are already being met
- It will cost too much
- A new Alpha or even Discovery is needed based on the findings from testing the first prototype
Beta Phase
The purpose of the Beta phase is to build a working version of the service based on your findings in the Alpha phase. The version of the service built here must be able to handle real users and work on a large scale.
Live
After Beta, it’s time to go Live! This phase is the opportunity to keep improving your service based on feedback and ongoing research.
Retiring your service
The service that was built may need to be retired, possibly because user needs have changed, requirements have been refined or Government policy has been updated. Although this seems like the last step, it is just as important as the first. The user needs to be considered just as much at the Retirement phase as at the Discovery phase.
We’ve all heard the word agile and most of us have taken steps to be more “agile.” But when talking about the public sector technology landscape, it’s more than just a set of principles to aspire to; it’s a required methodology for software development and project management. When done right, it results in public-facing services that have been built with the users in mind from day one – services that deliver a solution, are accessible by those who use them, and work at scale. Simply put – suppliers shouldn’t be diving in the deep end thinking about the end-result when they’re in Discovery phase. Take it step by step and be part of watching a great service grow from the ground up!
Why is this important to DOS suppliers?
Well, other than the commitment suppliers will have to make when getting on the Digital Outcomes and Specialists framework, the phases are important to understand for two reasons:
- Firstly, on DOS the opportunities will be advertised at each phase of the project. For instance, ‘Crown Marketplace – Supply Teacher Services Beta’. This already gives suppliers a good indication of whether they might be interested in the opportunity based on the initial work that’s been completed. It also prompts some vital questions for suppliers to be asking at the clarification stage, for example, who was the supplier that carried out the Alpha phase? And will an incumbent be bidding on the opportunity?
- Secondly, some services require a Service Assessment. Service Assessments are mandatory if your service belongs to a Central Gov department, if it needs to get spend approval or if it is rebuilding a new ‘transactional service’. If your service does need to be assessed it needs to be carried out at the end of Alpha, private Beta before public Beta and again before it goes Live. If it doesn’t pass one of the assessments, you’ll have to get it reassessed before it moves into the next phase.
There you have it. If you haven’t already checked out the Service Design Manual make sure you do so before applying for any Digital Outcomes framework – or the Digital Specialists and Programmes route to market. Don’t leave your planning until the last minute!
