Statutory Debt Repayment Plan Alpha assessment
The report for the Statutory Debt Repayment Plan alpha assessment on the 08 June 2022
Service Standard assessment report
Statutory Debt Repayment Plan
| From: | Central Digital & Data Office (CDDO) |
| Assessment date: | 08/06/2022 |
| Stage: | Alpha |
| Result: | Met |
| Service provider: | Insolvency Service |
Service description
This service aims to solve the problem of…
Provides a standardised/secure digital platform to implement a regulated approach for citizens struggling with debt repayment to enter into a formal debt repayment plan proposed and supported by debt advice organisations and formalised with their creditor(s)
Service users
This service is for;
- Citizens struggling to manage their debts
- Debt advice organisations
- Organisations acting as a payment distributor
- Creditors (FCA & Non FCA regulated)
1. Understand users and their needs
Decision
The service met point 1 of the Standard.
What the team has done well
The panel was impressed that:
- the team demonstrated a good understanding of their users and their needs, showing empathy for citizens in very difficult circumstances
- appropriate and varied research methods have been utilised and a representative sample of users engaged with
- user needs were presented clearly; reflecting real world needs and those created by the service
- the team clearly showed how the design had been influenced by the user needs of debt agencies and creditors
- research has been undertaken with people with a range of access needs and improvements made to the service as a result
- the team recognised the gaps and challenges with their research and were committed to overcoming them
- private beta research plans were clear and appropriate for the next phase, but will need updating and refining when the scope is agreed
What the team needs to explore
Before their next assessment, the team needs to:
- ensure the service meets the needs of citizens. There are multiple interactions which are not visible to the citizen. The team needs to demonstrate what they’ve produced does help citizens better manage their debt and ensure they are empowered to make their own decisions
- ensure the service works for everyone. Focus research on citizens who are vulnerable or excluded in some way to understand whether it meets their needs. For example, do people with low English language skills or cognitive impairments understand the service and what is happening to them?
- mitigate the risks of having a two-and-a-half-year alpha/beta build phase. Users and the context can change quickly, and the team needs to ensure what they’re building doesn’t become outdated or irrelevant
2. Solve a whole problem for users
Decision
The service met point 2 of the Standard.
What the team has done well
The panel was impressed that:
- the team has been working with Creditors to mitigate against one of their risky assumptions. This being that some Creditors tend to reject repayment plans due to lack of information, ultimately affecting the outcomes for debtors
- they are working with other organisations such as Money and Pension services (MAPS) and DWP to increase awareness of their service, and work with them to develop design iterations. They have plans of developing working groups with Creditors and Debt Advisors
- they have designed the service to reuse the information end users have given to Debt Advisors in the Breathing Space service. They have also explored the idea of connected APIs to pull in information for Debt Advisors within the service
- the team has been working closely with policy colleagues and were able to influence change in the legislation by showing user research evidence on pain points
What the team needs to explore
Before their next assessment, the team needs to:
- design the end user facing (debtors) aspect of the service in an accessible way to help the users understand their debt situation easily
- explore how to make the service more transparent for end users (debtors)
- explore where this service would live on GOV.UK, what’s the user journey from GOV.UK? How would Debt Advice organisations find this service? What information would be available for end users (people in debt) to help them become aware of this service and the support they will get?
- continue to engage and work with Creditors, Debt Advisor Organisations, and relevant government departments to raise awareness of the service, drive adoption, and to iterate the service based on user needs
3. Provide a joined-up experience across all channels
Decision
The service met point 3 of the Standard.
What the team has done well
The panel was impressed that:
- the team plans to learn from, and reuse the onboarding process for Debt Advisor Organisations for the Breathing Space service to ensure the user journey into the service is smooth
- the team is planning to integrate online and offline notifications to keep users up to date with progress on the repayment plan. Reusing existing platforms such as GOV.UK Notify for letters
What the team needs to explore
Before their next assessment, the team needs to:
- test the end to end journey, including across channels (online and offline) when applicable. For example, using GOV.UK Notify for letters. Test with Creditors, Debt Advisors, and Debtors
4. Make the service simple to use
Decision
The service met point 4 of the Standard.
What the team has done well
The panel was impressed that:
- the team used the GOV.UK Design System patterns and components to create prototypes that are consistent with GOV.UK and is following best practices and standards
- the team were clear to describe examples of design work that is still outstanding such as the view for the end user (debtors) and the ability to make changes to the repayment plan if the user’s circumstances change
- they showed a clear evolution of the designs showing evidence of it being based on user needs
What the team needs to explore
Before their next assessment, the team needs to:
- research and test a service name that resonates with users. The service name should describe what the user is trying to achieve. This will enable it to be more findable by users. Follow the guidance in the Service Manual about naming your service
- design the assisted digital support model for people who need help doing things online (if applicable)
- develop a support model to plan for when things go wrong or users (Debt Advisors, Creditors and Debtors) need support. Define who will provide that support, and explore a multichannel approach to provide support
- test with participants on different devices to understand the usability of the service
5. Make sure everyone can use the service
Decision
The service met point 5 of the Standard.
What the team has done well
The panel was impressed that:
- the team have identified some pain points for particular groups of people when accessing the service and have designed iterations to the service. For example, allowing users to enter a correspondence address if they don’t have a permanent address. Which could affect homeless people accessing the service
- the service will allow users to reuse their details from the Breathing Space service. Reducing the times users have to input information to government
- the prototype has been tested with users with a range of access needs to inform design decisions
What the team needs to explore
Before their next assessment, the team needs to:
- continue to explore the needs of people that are most affected and vulnerable from being in debt and plan to stop them being excluded by the service
- continue to conduct user research and testing with people with access needs and the use of assisted technology
- design the assisted digital support model for people who might need support using the online service
- conduct an Accessibility audit on your service
6. Have a multidisciplinary team
Decision
The service met point 6 of the Standard.
What the team has done well
The panel was impressed that:
- the team has been able to maintain a core set of individuals that have worked not just on this service since its Discovery phase, but also on the previous Breathing Space service, so they have continuity and consistency of knowledge share
- the team’s plans to expand as they move into Beta are logical and supplement the existing team in the right, key areas of development and performance
What the team needs to explore
Before their next assessment, the team needs to:
- explore whether there is any intention or ability to transition from a supplier led delivery team to one that employs and utilises civil servant capability; appreciating that recent HM Government announcements about the future intended size of the Civil Service as a whole may impact this
- understand that if taking a supplier based approach is the strategic/long-term plan for this service; how best can they get both value for money out of contracts, and ensure that they are not falling into the old trap of locking themselves into a single supplier contract that sees repetitive renewals as the only way to keep the service running
7. Use agile ways of working
Decision
The service met point 7 of the Standard.
What the team has done well
The panel was impressed that:
- the team has been able to apply an agile, adaptive planning and iterative delivery process throughout the alpha phase; where they have tackled their biggest and riskiest assumptions first
- the team has an empowered Product Owner who is able to make decisions around priorities and goals for the service based on not just business requests but also factoring in a range of evidence from user research and performance analytics (once in beta)
- although the project has a Product Board that only meets monthly, they use a proportionality rule to ensure that only those decisions that need to be raised that high do so
What the team needs to explore
Before their next assessment, the team needs to:
- consider that the 2 year time frame for private beta feels long, and raises question marks about whether this is an agile delivery in its truest sense, or whether this is a classic waterfall approach of design (albeit iterative design), then build, then launch. The panel recognises that the team has used its experience of delivering the Breathing Space service as a way of forecasting this delivery time frame, but there is no avoiding the fact that 2 years of development without end to end usage by real end users is a risk. We also recognise that legislation is required to be able to input live data into the service; and that parliamentary time to progress that legislation is minimal; but that shouldn’t stop the question being posed as to whether the 2 year time frame can be condensed in any way
8. Iterate and improve frequently
Decision
The service met point 8 of the Standard.
What the team has done well
The panel was impressed that:
- the team has clearly demonstrated how it has iterated its designs over multiple attempts to ensure that what is built will best meet users’ needs as they currently understand them; and that future iteration based on new research findings will continue to be possible throughout the private beta phase
- the team understands the role that performance analytics will play throughout the private beta in ensuring that iterations and improvements are targeted at the right areas of the service; those that are causing users most difficulty
What the team needs to explore
Before their next assessment, the team needs to:
- consider how much they can expect to continue to learn over the next two years, their intended time frame for private beta, when that period will not include the use of any real data by real end users within the system.
9. Create a secure service which protects users’ privacy
Decision
The service met point 9 of the Standard.
What the team has done well
The panel was impressed that:
- the team used NCSC standards and guidelines in the architectural design
- the service had a threat assessment to understand threat vectors to the service
- the team has plan a for pentests before going live
- the service had a data impact assessment to understand the data risks and had the data classified
What the team needs to explore
Before their next assessment, the team needs to:
- finalise and implement data retention policies
- design role-based access control and data protection appropriate for the user needs and permissions
- design and implement cookies policies
- have a pentest and security review before the service goes live
10. Define what success looks like and publish performance data
Decision
The service met point 10 of the Standard.
What the team has done well
The panel was impressed that:
- the team intends to engage and bring in to the development team a dedicated Performance Analyst who will help them to understand what metrics they need to measure to judge the success of the service and to help capture and interpret their performance data
- the team has a good grasp of not just the SDRP performance data they need to capture to measure success; but also the broader service level data they will need to capture from enterprise management information to understand whether the service is delivering on the policy outcomes and problems it was intended to solve
- the team has plans to publish the data so that they can be transparent and open about how government money has been spent
What the team needs to explore
Before their next assessment, the team needs to:
- consider when is the right time to bring in a Performance Analyst given their private beta isn’t going to start for a further two years and thus there will not be any performance data for the individual to analyse in that time frame. Granted an individual will need to come on board in advance of the first private beta users to help set up the relevant GA tagging and testing; but beyond that, they will not have much more to contribute to the team at this stage
11. Choose the right tools and technology
Decision
The service met point 11 of the Standard.
What the team has done well
The panel was impressed that:
- the team planned to build modern microservice based architecture and infrastructure
- the team was reusing platform and components from the agency and the “breathing space” service
- the architecture was designed to use a mixture of bespoke and enterprise commercial solutions with total costs of ownership in mind
- the team had good understanding of integration to the external systems with open standards
What the team needs to explore
Before their next assessment, the team needs to:
- where suitable, abstract away dependencies (e.g. Experian address lookup and Identity server) to minimise vendor lock-in
12. Make new source code open
The team has not built any production codes (other than the prototype) at the time of assessment. Future codes will live in https://github.com/insolvencyservice.
Decision
The service met point 12 of the Standard.
What the team has done well
The panel was impressed that:
- the team had a plan to open source, and consult assurance teams in terms of their proposal of open sourcing which repositories
What the team needs to explore
Before their next assessment, the team needs to:
- practise coding in the open, with evidence of how they iterate codes in open repositories
- be able to provide justifications against why they open/ close sourced certain repositories
13. Use and contribute to open standards, common components and patterns
Decision
The service met point 13 of the Standard.
What the team has done well
The panel was impressed that:
- the team planned to use GOV.UK Notify to communicate with the users
- the team planned to utilise open standards, including Rest API, payment data, to do system-to-system integration
- the team actively worked on standardising and mapping naming convention and field names across users, business and technology
- the team had started discussion with GDS GOV.UK Account team on adopting the identity solution, with Government Gateway as a fallback solution
- the prototype made good use of the GOV.UK Design System patterns and components
What the team needs to explore
Before their next assessment, the team needs to:
- work with CDDO to understand if there are related financial, debtor and creditor data standards that are applicable to this service (e.g. ISO 21586:2020)
- contribute the learnings and findings back to the data standard community
- share any iterations or learnings to patterns and components in the GOV.UK Design System backlog
14. Operate a reliable service
Decision
The service met point 14 of the Standard.
What the team has done well
The panel was impressed that:
- the team had a thorough DevOps and service monitoring tool pattern
- the team had an established incident management process and offline plan from their experience of developing “breathing space”
- the team had a good plan to use automated tests and quality assurance to assure the quality, performance and security of the development
- the team had technical and data governance in place through Technical Assurance Group
What the team needs to explore
Before their next assessment, the team needs to:
- make sure the monitoring tools and security measures are in place before going live
Updates to this page
Published 30 June 2022