DWP Process Failure

How many times do you have to tell the Government something?

English: Westminster Palace in London, The Gre...
Image via Wikipedia

Recently, my mother died, so it fell to me to inform a number of organisations, including the Department of Work and Pensions (DWP).

I knew that I would also need statements from them of any benefits that had been over-paid, as these would become a debt of her estate, something you need to list when seeking probate.

Encounter One

The registrar told me about a new government service “Tell Us Once”, it seemed someone had (at last) had a good idea. I phoned them that evening, and they were polite and efficient in taking all the details.

I explained that I wanted a written statement of any overpaid benefits, and they suggested that if I wanted to move things along, I should speak to the DWP Bereavement Service – another “good idea” which Pensions Minister Steve Webb is quoted as saying will “cut all unnecessary red tape”.

The Bereavement Service were also polite and helpful, and they said a letter showing what benefits had been overpaid would be sent within a week.

Encounter Two

Of course, a week later, no letter, so I phoned them again. They apologised and said the letter would be out within a week.

This time a letter arrived, but it only mentioned two of the three benefits that I knew my mother had been receiving. The letter instructed me to call them back with any questions, and said that “later” i would get a letter from the Debt Management department telling me how to repay.

Encounter Three

I phoned back, only to be told that the team only dealt with “new” deaths, so I would need to speak to the main DWP contact centre.

I phoned them, to be told that they only dealt with State Pension and Pension Credit and that Attendance Allowance was an entirely different part of the DWP, on a different number.

So I phoned the new number, listened to yet another IVR telling me this was the number for Attendance Allowance, selected the option for “Talk to us about a death” and got routed ….. to the original Bereavement Service.

They helpfully told me to ring the same number but “choose option 3”, which I did, and spoke to someone who could tell me the exact amount of the overpayment, but who could not produce a letter for me, as that was “the job of the Debt Management department”. They did tell me the number to phone, and told me the matter was referred by them to the Debt Management department on the 5th of January (this conversation was on the 19th).

So I made the 5th successive call to the DWP, to speak to the Debt Management department. They were very polite, but could not find any trace of the information on their computer. I told them that it had been referred to them on the 5th, so surely there must be a record of that? Oh no – that was “far too soon” for it to have been put onto their system.

They offered to email the team that “put things on the computer” (presumably by copying from another computer). I asked how long I should leave it before chasing again, to be told a week would be sensible to allow before it might be on their system

And after that, how long to get what I wanted, a simple letter showing how much overpayment had been made? About another month apparently.

This way, madness lies

This whole process has been (of course) irritating and frustrating, but also symptomatic of terrible waste.

Hard to tell from the outside of course, but this feels like over-specialisation, and a system drowning in failure demand

Has anyone else had similar experiences?

More interestingly, has anyone had any experience on the inside who is prepared to comment?

I wonder what John Seddon would make of this?

Why SLAs smell of waste

Image via Wikipedia


There’s quite a lot now on the internet about “devops” – combining development and operations work to increase flow and reduce problems

One of the key features of this approach is the idea that above a certain threshold of estimated duration, all operations work has to be included in the kanban board for visibility and flow management.

For example see these meeting notes from a DevOps conference in Ocean View, June 2011, where Lonely Planet shared their experience of this, with a threshold of 30 mins – i.e. any servicedesk issue which takes more than 30 mins gets moved to Kanban

I had a brief exchange on Twitter with Dominica DeGrandis, one of the DevOps leading lights, in which she confirmed that in her experience 1 hour was the most common point where teams found that the visibility and sharing was worth more than the overhead of putting into Kanban. This happens to be the pragmatic transition point adopted by the team I am coaching.

SLAs are a Problem!

Intuitively a follow up step will be to look at how this approach affects traditional service desk SLAs. I’m not a great fan of SLAs, as they tend to focus on failure and what happens after a failure – I’d rather that a service “just worked” and that resources went into keeping it that way.

I’m particularly disenchanted with the idea of SLAs when they are applied between two departments of the same business, not least because they stimulate the wrong sort of behaviour, in particular the chasing of local optima. The SLA-driven approach also encourages managers on the “consumer” side of the agreement to pay no attention whatsoever to systemic problems of their own making, to the ultimate detriment of the overall firm.

Having just read Bob Marshall’s Marshall Model of Organisational Evolution I can see that the frustrations I am expressing are a factor of the transition zone between the Analytic and Synergistic organisational mindsets.

I find John Seddon another source of stimulating ideas, and his piece on “Why do we believe in economies of scale?”  has some particular insights to how the SLA mentality creates organisational waste.

I humbly offer a few more thoughts to the debate:

  • “Incident management” as a process is focused on failure, and managing the impact of failure rather than removing the causes (and yes I know there is a whole other ITIL process of “Problem Management”)
  • SLAs focus resource on local optima (fix this incident for this user) rather than on the “best value for the whole firm at this time”
  • Incident management systems tend to accumulate backlogs of failure demand which represent inherent waste, and which also clog flow making the work to address underlying causes inherently less efficient
  • Efforts to create a synergistic “OneTeam” approach focused on flow are undermined by too much interrupt-driven work. Integrating the interrupt-driven work into the flow gives a much better sense of how to “add the most value possible right now”

The way I explain this to colleagues is usually along these lines:

The business has invested a fixed amount into IT development & support

Usually (especially in small / medium business) there is  a constraint within the technology team

Therefore the best value to the business from that investment is through:

  • elevation and exploitation of the constraint
  • reducing lead time
  • prioritising based on economic cost of delay

All of which are delivered by a tuned Kanban system.

To make sense of this we need to educate ourselves and our colleagues about the systemic dysfunctions caused by trying to force a system to work faster than the constraints allow. It often takes time – for far too many people from the Analytic mindset the first response is “they just have to work harder”

How about you?

I’d love to hear from other people grappling with these issues – please comment here or tweet me (@Synesthesia)