Lasting Power of Attorney Beta

Today the Beta version of the Lasting Power of Attorney application has been released. It’s one of the first of the Digital Exemplar services to reach Beta stage, which has made it one of the most interesting and, at times, challenging projects I’ve ever worked on.

I wanted to share some of the lessons I’ve learned on this journey, in case it’s of some help to the other people working on exemplar services across government.

Screens shot of the Lasting Power of Attorney beta

Some background

A Lasting Power of Attorney is a way to appoint someone you trust to manage your money, property and healthcare, in case anything happens to you. We’ve been building a digital service to replace the current application, which comes in the form of a thick pack of forms and guidance.

Paper forms for lasting power of attorney – as measured against a ten pence piece

The first prototype was a simple, standalone proof of concept to show what was possible.

For the Alpha version we carried out user testing, refined and improved the product and built it on a small, fully secure IL3 environment. We also set up a string and sellotape helpdesk and technical support function to support the small, invitation-only group of users. The Alpha ran from November 2012 to March 2013.

For Beta we have improved the product further, built it on an open Application Programming Interface (API), added online payment and turned it into a full scale production service that is open to anyone. For a new digital service this doesn’t just mean bigger servers but also a whole set of people, processes and tools to support the users and the technology.

Compared to some other government services, the LPA service doesn’t have especially high traffic, but there’s a lot of legal complexity (understandably, as it’s a powerful document) for what appears to be, on the surface, a relatively straightforward product.

What we learned

The challenges aren’t in the product, rather around delivering in new ways in government.

Introduce agile early

I’m fortunate to be working with a motivated and talented team of people from the Office of the Public Guardian, Ministry of Justice (MOJ), Cabinet Office and 3rd party supplier Transform. We’re working really effectively together now and when we sit together it feels like we can achieve anything, but it’s taken a while to get to this stage and with hindsight an early introduction to agile would have gotten everyone speaking the same language sooner.

Colocation, colocation, colocation

I say “when we sit together” because the team is spread across 6 sites in London, Birmingham and Nottingham and we’re often in different buildings. We’ve used a load of tools and techniques to make collaboration easier (with varying degrees of success), though the reality is there’s no substitute for sitting together.

Work with IT Teams, not against them

We’ve been working closely with MOJ IT Teams, who have been really supportive. At first we were coming at the problem from different directions, which was challenging for everyone, not least the SRO. However good, early engagement with IT Teams has been really beneficial as well as helping us set a template for future engagement.

Start thinking about legislative change early

Policy constraints mean that we still require a handwritten signature on the LPA document, so the LPA tool helps create a completed PDF form. The form itself is enshrined in legislation, so we weren’t even able to change how it looked, was laid out etc. This interaction between on and offline has been the biggest design challenge, so we’d recommend starting legislation change as early as possible and expect it to take a long time.

Know how procurement works

Working in an agile way means starting to build early so the ability to quickly buy in a development team was really important. We used Sprint II and G-Cloud to buy capability and services, and I’m really looking forward to the new Digital Services Procurement Framework. Even when that’s ready, it’ll be important to understand the frameworks and how procurement works in your department.

If you’re going to fail do it fast

Try things early. Even though we didn’t have to, we took the decision to make our Alpha version of the service as secure as the final version would need to be. This proved to be a lot more challenging than anyone expected but we were all glad that we uncovered the issues early, rather than during Beta.

Looking after other people’s data isn’t trivial

Even though we learned how to make the technology fully secure during the alpha phase, there was still a huge amount of work to do in beta to demonstrate that we were ready to store and manage large amounts of users’ data. Privacy impact assessments and System Operating Procedure documentation take a long time to prepare and involve lots of people. Don’t leave it until the last minute!

Source and involve operations teams early

One of the other challenges we’ve had to overcome has been related to technical support of the service. This is being handled by the new Digital Services Division in MOJ. We’re using modern, DevOps methods here and that has meant recruiting new people which took longer than we expected. If I could do it again I’d make sure we got the operations team sourced and involved early. The payoff will come now as the team has set up some really slick and efficient ways to monitor, develop and deploy improvements, without long-winded and constrictive release cycles.

Always read the manual

I’ve made it my mission to make this product a real exemplar so we’ve fully embraced the digital strategy, using cloud based, open source technologies, user-centred, iterative design, agile ways of working and modern approaches to operations. There is still a good deal of work to do particularly in the area of governance, though on the whole we’ve now met the Digital by Default Standard. It was hard at first as the standard was in development but there is now a wealth of support, help and guidance in the Government Service Design Manual.

Doing things the right way

I used to do IT delivery using waterfall approaches, with off the shelf packages, using Prince II project management.  I’ve learned a huge amount about agile delivery, custom builds and open source technology working on this project. But, above all, I’ve learned that this is absolutely the way to build and run digital services in government.

If anyone’s interested I’m happy to discuss in more detail. It’s good to share.

@chris_mitch