There has been much speculation in recent months about the health of Universal Credit – one of the largest government change programmes currently on the go. Well, the speculation came to an end last week with the publication of an NAO report, Universal Credit – early progress.
Universal Credit was always going to be difficult to deliver; but the hope was that this time government would get it right, after a series of very costly project failures, the National Programme for IT in the NHS being the most infamous. Sad to say that this was not to be.
Despite it’s complexity, Universal Credit has been working to some very tight timescales, with the scheme due to have begun full roll-out this year. A frequent problem with Government change programmes is pressure from Ministers to deliver by a certain date, without taking into account the full scale of the task in hand. We saw this with the agricultural Single Payment Scheme (SPS) in 2005; and we have almost certainly had the same thing going on here – although no one will own up to it.
The DWP’s response to the tight timescales was to introduce an “agile” approach to project management – a term used to refer to a broad range of methods for concurrent, incremental and iterative development, in comparison to more traditional linear approaches.
Unfortunately, it does not appear as if they had anyone around who actually understood the application of these types of methods. Not least, they appeared to be under the common misconception that agile means that you can go ahead and design and build bits of a system, without any real understanding of the whole. This is not the case. At the start of any design and development process you need a high level design – a clear high level view of what the future state is intended to look like. Using agile development techniques, you then incrementally and iteratively design and develop against this view; adapting it as necessary as you travel along the design lifecycle.
This was one of the most important criticisms made by the NAO – the lack of a detailed view of how Universal Credit is meant to work. It appears that DWP was warned repeatedly about the lack of a “detailed ‘blueprint’, ‘architecture’ or ‘target operating model’” for Universal Credit. Well done whoever was doing the warning. Pity that no one in charge took sufficient notice.
Elsewhere, the report gives lots of emphasis on poor programme management and governance. But, if you lack a clear and robust high level design, the best project management in the world will not help you.
Universal Credit seems to have suffered from the usual problem of an over-emphasis on IT – IT driven, rather than IT enabled. This IT-centric view has lead to the common mistake of bringing on board the IT suppliers too early. Too early to have a good idea about what type of technology you need and who might be best placed to provide it. The point at which you are in a position to bring on any suppliers is once you have a high level design in place, and not before.
From the NAO report it’s not clear which technology has been used for Universal Credit, but given the use of the words “inflexible” and “hardwired”, it doesn’t look good. Modern technology is all about flexibility and agility to respond to business change. Something like Universal Credit certainly needs this. I hate to think what they have used here.
In terms of having something, even if imperfect, that might work, again things do not look good. One of the things you think about when developing your high level design and roadmap, is what are the core capabilities you need in place before you can go live with anything. Now you would think that the ability for claimants to make changes to their circumstances on-line would rank up there as fairly fundamental, for a service that is meant to be based on claimants applying for and managing their benefits on-line.
Given that the IT solution does not appear to do any cross-checking either, i.e. the validation and verification of claims to prevent unintended error or fraud, you do wonder where all the IT spend has gone.
Something not covered in the report is the degree to which DWP have engaged and worked with their stakeholders. Universal Credit has a large number of these, ranging from the immediate partner network, e.g. HMRC and local authorities, through to those many organisations that underpin the UK’s welfare system, such as the Citizens Advice Bureau (CAB). The strength of the working relationship with these stakeholders is critical to the success of Universal Credit. Given the “fortress mentality” mentioned in the report, I suspect that this is another area that needs some major attention by the “reset team”.
And finally, but not least, the report makes very little mention of the customer – those receiving the benefits under Universal Credit. The customer very much needs to be in the foreground of the design process, but here they appear to be very much in the background.
Universal Credit will represent significant change for claimants, placing new responsibilities on them. Ensuring that these capabilities are in place is as much part of the project as the IT, or any other part of the system. Little sign of this happening and another area to be looked at by the reset team.
So, in broad terms, if you are a service designer and systems thinker, how would you go about all this?
First, it’s important to recognise that Universal Credit has two primary, interrelated systems. There is the Universal Credit scheme itself and then the associated service. Both need to be designed, against a clear set of design principles, as part of an overall system.
The first step, within a concurrent and agile development lifecycle, is to design the scheme. The complexity of the scheme will drive the complexity of the service. Simplification is key to the success of both.
The principal elements of the scheme need to be in place before you can start concurrently designing the business and target operating models for the service – the Enterprise Architecture high level design. Once this is sufficiently well defined, you can begin further elements of the development lifecycle, incrementally and iteratively, using a range of design techniques, including prototyping and co-creation with customers, suppliers and other stakeholders.
The temporal dimension of the design is very important here. You need a clear roadmap for the scheme and the service – present state to desired future state. Everything will need to flex and adapt as the programme moves forward, responding to the emergent properties of the system and the changing external environment.
All this needs to happen using a multi-disciplinary design team and everything needs to happen with complete transparency. Only through transparency can the best path be found.
Hopefully, for those now in the middle of this, there are enough bits and pieces to re-purpose and get things back on track. I see the reset as a positive thing. So often in the past, people have just carried on digging!