Progress insufficient to allow progression to live stage

The GDS document praised the progress that had been made on the project, such as putting users first and undertaking user research, but went on to list reasons why the request was denied.

According to GDS, there was no clear indication of who the service manager actually is and the responsibility seemed to be shared across numerous people.

It was also found that a project board agreed requirements for development and there was uncertainty surrounding whether there was any flexibility in approving requirements outside of this process.

Besides this, GDS said that there was no access to an in-house user researcher or design support, causing concern about how the team could quickly design/test/code without this in place.

The lack of digital analytics in place was also picked up on, which is an issue because it means measuring how the service is performing is difficult.

Another reason the Border Force project was not allow Live Digital By Default status is because it couldn’t provide evidence of assisted digital user research and that running the service requires the co-ordination of eight different suppliers.

Progress to be made before project can go live

“It is very encouraging to see the efforts the in-house team have made so far to align with the development methods outlined in the service standard,” claimed GDS.

“GDS recommends the team continues this approach by working towards a beta as the ‘next step’ of this service development,” it added.

GDS also highlighted the need for the Home Office to ensure the team covers all the roles require to take the service from beta to live.