PPUD Replacement

Looking back at the 9 months I spent on this project, it was definitely a new experience, and a little bit of a crazy one. We first set out on this project knowing that it was going to be difficult, but we never thought about how difficult it would be. The project itself was about replacing the legacy system PPUD, which had now turned into this monolithic monstrosity. It’s original purpose had long been forgotten, and users had millions of workarounds to do whilst trying to do their job as caseworkers in public protection. 

dxw worked on this project during the discovery, alpha and now beta phases of the project. But due to the pandemic and insecure budgets floating around, there were big gaps between the phases, and this affected beta a lot. There were four services which were recommended in order to replace PPUD: Manage a Recall, Manage a move to and from hospital, Manage a Parole Review, Manage a complaint or fatal incident. These were the main tasks which were carried out on the system by caseworkers in the MoJ or so we thought. 

In our inception phase, we did a ‘mini discovery’ on Manage a recall to help our shared understanding as a team and to kick off the design and build phases of the project. The inception was four weeks long. We did a lot of exploratory research including: journey mapping, user interviews, and even some usability testing with alpha prototypes. We ended the inception by starting to build new prototypes based on the ones made in alpha. But because the alpha was done long before this phase started some business changes had happened, so we essentially needed to start again.

This need to ‘start again’ really affected the design team as we had a lot on our shoulders. We had the pressure to quickly do a lot of research to find out about how caseworkers did their jobs now, what improvements we could make in the new system, their needs and goals. And then the pressure of quickly designing something new, making it intuitive, testing it with users, then passing it onto developers to build. We were not given the time we needed, testing with the first few prototypes was always going to take the longest as we were still learning about everything. But we pushed through, making sure that we kept the product as simple as possible, and continued testing it with users as they know so much about how the process of a recall works. Our main problem as a team was that we had to do a discovery, alpha and beta at the same time. 

Whilst we were doing the work for the Manage a Recall service, we also had to look at the other services we were building, as there was an impending deadline and we had to replace the entire system of PPUD by this date. So we did our mini discovery into Cross Border Transfers, which deals with offenders going to their home country or offenders returning to the UK. The discovery was very successful and we learned a lot about their work processes, what they use PPUD for at the moment and what they would need for the future. Again it was exploratory research, we mapped as-is journeys, to see where we could improve the process; and conducted user interviews to understand the perspectives of caseworkers and their managers.

With our heads held high, we had the next mini discovery to conduct, Manage a Parole Review. This was very different from the Cross Border Transfer team’s process, their team is made up of about 10 people all working together. The Parole Board is a massive body, with 20 user groups identified, and they were all using the PPUD system for all sorts of different tasks. We were also only given a month to conduct research with the Parole Board so we had to dive in quickly. We met with 3 groups a week, doing sessions that were half user interview half journey mapping session, we had to quickly find out about everything they did, how they used PPUD and map out their process so we could improve it. It was a huge task and overwhelming for the team. We were receiving so much knowledge and couldn’t keep up with it. By the time we finished speaking to everyone, we realised we didn’t have quality research data, only half answered questions. We knew that we were not able to do this properly under these circumstances. We also learned that the service which was recommended would not work for the other workflows the Parole Board needed to do.

At the same time, we needed to keep iterating on the ‘Manage a Recall’ prototype, test it and make more improvements. There was too much work and not enough time. And we also had to reduce the effort on this side of the project too, by reducing the amount of research we did. We only tested with 2 people and then synthesised that research. But we knew as a team that this way of working was not sustainable. 

We raised our concerns to the stakeholders and the responsible senior people on the project. We had a few workshops and retros, and others within the business realised how big this project was. This was probably the leading cause of our problems, was that not everyone realised how large the project was and how big the weight was on our team. We also made a large bird’s eye view of the project scope calling it ‘PPUD on a page’ just so people could visually comprehend the scale of the project. 

Luckily, we were able to get this project de-scoped. We stopped doing the mini discoveries, and we could concentrate on making the Manage a Recall service an intuitive and usable service. From this point, we were able to design and test things properly without ‘cutting corners’ so that we could deliver something on time. We could test our product thoroughly with users and find out more about their goals, pain points and praises for the product we were building. We also had time to research about the other types of recalls which we were going to build on in the future. The product is also becoming a great success, although it is only in beta, we are getting a lot of positive feedback from stakeholders and users about it. Our most successful metric is that a recall used to take end to end 80-90 mins to process, and in our product it only takes 15-20 mins! A huge success! This means that caseworkers could process more recalls in a day, and spend their time doing more important tasks rather than doing workarounds in an old system.