As part of this project, we developed the Calculate Journey Variable Payments service. The service integrates data from Book a Secure Move to automatically price moves on a monthly basis and enable Finance, Assurance and Commercial teams to ensure supplier invoices are correct. Talent Consulting designed and delivered a Journey Price Catalogue (JPC) payment service for the Ministry of Justice. The JPC is a document that describes every allowable combinations of locations where people can be moved from/to and the price for each movement.
When Talent Consulting came to work on the project, the Ministry of Justice’s team were facing several issues. This included the Commercial team not being able to quickly and accurately calculate the S2B payment for a supplier for a given period, solely relying on supplier invoices to dictate payments, and needing to manually add and price new journeys within the JPC, alongside the Assurance and Finance teams needing to manually complete checks and assure moves from the previous month (A total of 5,000 moves a month.)
All the details of moves were collated on a spreadsheet which contained very sensitive information including the names, dates of birth and locations of prisoners. This data was not generated by the MoJ but by suppliers, which meant that some of the information could be inaccurate or could change the pricing significantly. What’s more, the data wasn’t live, and invoices were sent each month at the suppliers’ whim with no assurance that moves or prices were accurate.
From a technical perspective, this project was interesting for a number of reasons. Because integration with 3rd party suppliers was needed, more Big Design Upfront was required than would normally be expected in an agile project. In particular, a RESTful API to interact with the service to book moves was specified and documented prior to suppliers commencing integration work. Being a Government digital project, it also needed to adhere to the Technology Code of Practice, meet the GDS Service Standard and integrate with in-flight services being delivered in the Digital Prison Service area, including the Prison API and Auth Service. Finally, our service needed to be deployed to the Ministry of Justice Cloud Platform and meet the necessary standards.
Our Approach & Challenges
During initial research (Alpha), we understood from stakeholders and future users what the pain points were in the existing products. We created user journeys mapping and what those users would do from A to B in our service and aligned the systems to the user journey, creating a service map recording the different users (whether Commercial, Assurance or Finance), the tasks they’d need to perform, and the systems that would need to work together to make those tasks happen as smoothly as possible. As part of that service map, we logged all the pain points and issues users were having, which became our basis for the MVP and was used to inform what our front-end service should look like.
In order to provide a consistent look and feel for users, we used the same design patterns as the ones we’d created for the Book a Secure Move service and used the Beta phase to go through numerous iterations of the service and getting feedback from stakeholders. Our research objectives during Beta were to uncover requirements, dependencies, opportunities for improved data quality and efficiency, and to test the usability of the Calculate Journey Variable Payments (S2B) service with Assurance, Finance and Commercials teams. To meet these objectives, we employed a variety of research methods:
- Exploratory research of the wider service, past findings and data on the transition from PECS3 to PECS4
- Focus groups / individual user interviews conducted to understand the processes, workflow, users and user needs
- Biweekly action calls conducted to evaluate the interactivity and understanding of our solution and to rapidly iterate and review
- Remote user testing (due to COVID restrictions) was conducted to ensure users’ satisfaction with the service
- Training was conducted, user guides distributed, and a follow-on Q+A session conducted before the end of the project handover
The technology stack used for this project was Ruby on Rails for the API and Node for the front-end user interface, according to the client’s preferences. From the start, we ensured that open standards were followed. The front-end node application used the GDS front-end toolkit embedded in the Ministry of Justice’s Form Builder project. We paid a lot of attention to ensuring the service was accessible despite it being an internal (non-public) service. The backend Rails application followed both JSON-API standards and Open API Specification.
A good decision made early on was to have only a single API that both our user interface and suppliers integrated with. Because of the time delay with suppliers commencing their integration work, this meant we could specify and test our API with a real-world application, discovering and addressing issues as we iteratively rolled out our service, which made for easier integrations with others.
To enable us to address design decisions which benefited from evolution, we needed to introduce versioning into the API. This was relatively easy for our front-end to do, as we were fully in control of development and deployment of both the front-end and the API. However, although versioning had been agreed with suppliers in general terms from the start, in practice they had their work cut out integrating with the original API let alone have the capacity to change their implementation to support a new version. Therefore, we had to be extremely judicious in our use of versioning, always preferring non-breaking changes and supporting the original version of the API.
To facilitate integration with suppliers we ensured that we had accurate, up-to-date documentation using Swagger for interacting with the API and also high-level documentation (in the GitHub wiki) explaining principles, events and workflows. We also wrote many acceptance / assurance tests which we collaboratively worked through with the suppliers. We communicated with them over Slack and Google Hangouts, finding that even in the somewhat waterfall world of supplier integration, flexibility and agile ways of working are still very beneficial.
Results & Feedback
- The service removed the need to manually check all standard moves, allowing teams to focus on more complicated moves
- The service allows correct pricing and payments to suppliers on a per move basis, taking the guesswork out of supplier invoices
- The Finance team no longer needs to assure pricing and can now focus on forecasting and budgeting
- The Assurance team no longer needs to review Standard moves created by the Authority; standard moves make up approximately 95% of total moves undertaken each month
- The service highlights which moves need approving by the Assurance team
- The service maintains the JPC for the Commercial team
- All the sensitive information is now completely secure
- 97% User Engagement score
The service is now being updated on a daily basis, and we have passed on any ideas for future improvements to the HMPPS team.
Learn more about the different projects we’ve worked on
Get in touch
Talent Consulting Manchester
Talent Consulting Birmingham
Talent Consulting Bristol
Talent Consulting London
134 Edmund Street,
B3 2ES, UK
T. +44 (0) 117 332 0824
2nd Floor, Old Exchange Buildings,
29 – 31 King Street
M2 6AD, UK
T. +44 (0) 117 332 0824
Ground Floor, The Quorum,
BS1 3AE, UK
T. +44 (0) 117 332 0824
1-2 Bear Gardens
T. +44 (0) 117 332 0824