Change in LAA Digital
We’ve been going through a large period of change in the LAA Digital team. We’ve shrunk down from a team of 125 to a team of 75 people; moved from project based, mostly waterfall delivery and into three teams focussed around the journeys of our users. All so we can become more user-centred; doing less but delivering more.
Whilst this ‘transformation’ is never really something that ends, we have achieved a lot in a short space of time (just over a year). This is something we are proud of and we want to start shouting about our achievements more.
“But we can do robotics, right?”
One of these achievements stemmed from a previous ‘robotics’ project. This solution proposed to layer Robotics Process Automation (RPA) on the front-end of one of our biggest and most important systems, to automatically carry out processes on behalf of internal caseworkers.
Whilst there could be a place for this kind of solution, we learnt that this is not one we want to advocate in this instance. Instead of plastering over the cracks of unnecessary processes within a system, we wanted to fix the problem at source whilst keeping our systems more supportable and easier to change.
Solving the problem
As a lean product team of 3 people, we took forward 4 hypotheses that we developed with our users. These were assumptions that we wanted to test to see if we could viably remove aspects of caseworker process, which made sense both from a business and technical perspective.
Collaborating with users and stakeholders, we were able to validate 3 out of 4 of our hypotheses (the 4th was fixed by process change instead of digital change). As a result, our third party supplier developed the changes we proposed in less than 2 weeks, meaning we could quickly move on to acceptance testing and releasing the value out to our users. This change saves the casework team around 36 hours a day and allows caseworkers to focus on making decisions instead of carrying out a cumbersome process.
What did we learn?
Outcomes over solutions
We can work with the users of our services to identify their needs and desired outcomes instead of starting off with a proposed solution.
Sometimes elements of waterfall delivery work
Because we work with a third party development team on one of our systems, requirements were expected upfront. This can be ok if you work in a lean way: answering questions quickly and being able to unblock issues at pace.
We should simplify and optimise our existing systems and processes before thinking about adding additional complexity
Automating processes or removing them all together was significantly cheaper than using Robotics Process Automation and it fixed the problem instead of covering it up.
Don’t forget to sign up for updates
Interested in joining us and working on things that matter? Check out our latest vacancies at Digital & Technology careers