Skip to main content

Private Beta

Aims of the Beta Private phase

Core goal: build your service on a small-scale for testing

In this phase you build the service and run a test with a limited subset of users prior to launching the full service in Beta Public. Whilst this you should carry on with the research, testing and prototyping you did in Discovery and Alpha.

During Beta Private you should: - Build your service - Continue to test your service with users - Continue user research on areas you need to know more on, building further prototypes and carrying out user testing - Launch your service to an appropriate subset of users

Core team

  • Delivery Manager
  • Product Manager (ideally provided by the business, if not by DDTS)
  • User Researcher
  • Interaction Designer
  • Content Designer
  • Service Owner (usually provided by the business)
  • Developer
  • Business Analyst
  • QA / Tester

The following roles may need consultation or included as part of the core team, depending on the needs of the project: - Technical lead - Service Designer - Architect (data or technical) - Performance Analyst

Run the team in whichever way works best for yourself and the team. However the normal approach is to run a Scrum team with two week sprints. The usual setup should include stand ups, retrospectives, backlog refinement, sprint planning and show and tells every two weeks.

Key work

  • A built digital service based initially on Alpha prototypes, iterated according to ongoing research, design and testing
  • Operational implementation of the offline or back office elements of the service agreed with the business to ensure it can be administrated
  • Private Beta environment releasing that service at an appropriate point to a subset of users for testing
  • Preparation for Public Beta deployment including environment setup and engagement with the GIO service design team.
  • Plan for service maintenance
  • Beta Private assessment to allow you to move into Beta Public
  • DDTS Stage Gate 4 (Readiness for Service) approval to allow you to make your service live and available to the public.

Templates (WIP)

  • TBC

Operational requirements

Domain registration

You will need to contact GDS’s domain management team to get a GOV.UK domain registered for your service. They will require a completed beta assessment to finally hand over the domain to you but you should start working with them long before your assessment. Data protection Your DPIA needs to be updated and maintained through the beta phase and through the lifetime of the service. Your data protection contact will help you with this.

  • For Environment Agency deliveries: DataProtection@environment-agency.gov.uk
  • For all other Defra deliveries: data.protection@defra.gov.uk

Whole life costs calculator (WLC)

Review your whole life costs calculator (WLC) at all assessment points. This aims to calculate the ongoing operational costs of the service. You will still need to iterate this until the team is stood down and the WLC is signed off fully.

  • Overview of the WLC process
  • Team inbox: wholelifecosts@environment-agency.gov.uk

Cloud Centre of Excellence (CCoE)

You will need to carry on progressing through the Cloud Centre of Excellence route to live in order to get dev and test environments set up if you haven’t already, and subsequently to get pre prod and prod environments set up. It is worth noting that from initial engagement to final setup of production servers will take a minimum of 3 months for a very simple service (at least on the Azure side). You will expect to have dev, test, pre prod and prod environments, each of which will take a couple of weeks to build and they will only be built one after another. You will also have to attend two CDRB (Cloud Design Review Board) meetings, one before starting dev and one before starting pre prod.

In order to move from building the service into live you will need to work with the Cloud Centre of Excellence to design your cloud infrastructure prior to it being built. You will also need someone to get the full solution design signed off by the Technical Design Authority. If you do not have a developer or solution architect on your team with the necessary skillset to do this, you will need to request solution architect resource to assist.

  • The CCoE Sharepoint site
  • An overview of the route to live ### Technical Design Authority In order to progress through your second Cloud Design Review Board (CDRB) meeting you will need sign off from the Technical Design Authority. This is led by John Bridgen and is managed by Glen Fernandes. You would expect your technical lead to lead on this for you. They will need to complete a solution design and present and justify this. This is known as Architectural Design Authority (ADA) in Major Projects.

Penetration and accessibility testing

Not really admin as such but you will require both a penetration test (aka IT Health Check) and accessibility test before going live. Penetration testing will need to be carried out annually after going live. We have a contract with Commissum for penetration testing and usually use DAC for accessibility testing. As we don’t have a contract with DAC you will need to get multiple quotes if it is going to cost over £5k but usually it doesn’t.

Requests for change (RFCs)

Once you are live you will need to complete an RFC for every change to pre prod and prod environments. A standard change takes 10 working days from submission so it is good to get into a rhythm with these. Typically I would complete an RFC at the end of a sprint and have a deployment done at the end of the next sprint but if you are confident in your process and want faster turnaround you will need to complete an RFC for a sprint at the start of that sprint. Contact change management for help with this.

Assurance requirements

Beta Private assessment

You will need to contact the assessment team to set up your Beta Private assessment.

  • GDS Service assessment Sharepoint

Business case

If you have required a business case before beta then this will need updating and finalising in the beta phase.

Some parts of Defra require business cases and some do not. If required, this should be produced by a business contact, or where there is none available, produced with significant impact from the business. At this stage, the business case should be high level.

  • Guidance for producing business cases

DDTS Stage Gate 4 (Readiness for Service)

You will now need to complete DDTS Stage Gate 4. This establishes whether new IT systems/ways of working are ready to handover to the business, and that the solution is robust enough for implementation.

  • Overview of Stage Gates
  • Stage Gate template with guidance for each gate

Integrated Assurance and Approval Plan (IAAP)

Continue to update your integrated Assurance and Approval Plan (IAAP). This is a living document that will be updated throughout the lifecycle of the project, and aims to capture how your delivery will be assured by DDTS.

  • IAAP template

Service Design & Service Transition

If you haven’t already, you will need to engage with Service Transition, which sits within the Group Infrastructure and Operations (GIO) capability in Defra. They are responsible for ensuring the architecture, operations and maintenance of your service are properly reviewed before implementation. It is key to engage them early to ensure that you can get the necessary go ahead before any parts of your service go live.

You will likely engage with the Service Design team (to look at architecture, design of your service including wrap around support and operating model) and Service Transition, to assure key milestones for your service.

If you haven’t already, you will need to attend a GRIP meeting (GIO Resource and Information Planning) to present your delivery and the high level information you have at this point. You will be assigned a Service Designer and a Service Transition contact to help guide you through the process.

  • Contact the Pipeline GIO.Service.Pipeline@defra.gov.uk to request to attend a GRIP meeting and start this process

Spend control

All digital projects need to pass through the DDTS spend control pipeline. Once your currently approved spend is used, you will need to go through this process again. Typically you will need to submit your case with supporting documentation, and it will get reviewed and approved at a PAB meeting.

  • Spend control sharepoint site
  • Assessment criteria for GDS spend control

Project online

Continue to:

  • Maintain basic information about your delivery including key contacts
  • Update the high level timeline of when you roughly expect your delivery phases to be
  • Update at least monthly to give red / amber / green ratings for finance & progress

Add your financial forecasting for the spend control approval you’ve got, replacing forecasts with actuals on a monthly basis