EDS settles Tax Credits claim for £71m

It's not the move to the other house that should concern us so much as the move into companies that want to use their connections and influence in government; many of them before they have even left Parliament. Passing lucrative defence contracts to their otherwise useless son is another benefit available.

And if the public reject them, or they act dishonestly, they can always go and become Governor of Hong Kong or Commissioner of the EU.

To Michèle's point. The law is in place so it isn't a case of optionally implementing the Tax Credit Scheme.

The waste issue is different.

they enact laws that cost an arm and a leg to implement, and often they can't even get that right. Then they moan about not having enough money to do what they think they are supposed to do, so they increase taxes. And after a shortish career they move to the other house and gain an attendance allowance and/or a nice indexed linked pension.

Then they wonder why the british public think them irrelevant and choose not to vote.

All these are arguments are missing the one important point. The tax credits system whether manual or computerised does not work and will never work. No matter how the person/the computer who uses it, is it will never give the correct answer.

Instead of arguing on whether the manual system comes before the computerised system and vice versa, should not we put pressure on our existing govenment to scrap the whole thing....

I hear of pensions holes which needs to be filled but has anyone shown concerns on the cost involved by all these enquiries/debates into these micky mouse policies to find out why they don't work. All these government projects which go over budget..(The new Wembley stadium swimming pool for example).

NO one seems accountable for all this waste of money. It is not government money it is our/my money they are wasting...

This is what we should talk about...

Hi David,
Thanks for the clarification, but unless I've misunderstood I still think I disagree with your main premise. Surely the key message is to get the requirements properly defined, and manage the process of scope creep if the requirements begin to be changed by the client. Any good consultant get's that done and manages that process - it's normal in many (all?) projects. Managing the scope and expectations is essential if you are going to ensure the client gets what he/she expected, with everybody satisfied and happy with the results (and the bills!). Whether there is an existing process to be improved, or a new process being defined is a separate issue.
David Terrar
mail: dt@d2c.org.uk
web: http://www.d2c.org.uk and http://www.twinfield.co.uk
blog: http://www.businesstwozero.com

david (carter) and dennis make an interesting point. David says that the tax credit system requirements kept changing and that "it is simply impossible to write software when the client is constantly changing their mind". dennis says "I do believe the responsible consultant has a duty to point the way when it is clear the client is asking for or suggesting something that doesn't have a hope in hell of staying in scope or being delivered."

although EDS have settled the tax credit claim, that does not admit responsibility, and cynically this could be seen as a downpayment on future contracts. To answer dennis's point about duty, the game for consultants in this market place is to get through the door, and it would be plain daft to expect requirements to set in stone over the typical life of a large project - the world is constantly changing. To answer dennis's and david's point about the inmposibilities, there is a simple technique to manage change from baselined requirements, and it is a shame that the government, along with others, seem incapable of invoking these techniques. But this is hardly the consultants fault, and even culpability would be difficult to prove.

david (terrar) makes a good point about systems design saying "there are plenty of places where technology is the trigger for a business process improvement, which could not have been practical with a manual system". but this is only partly the answer. There is often a reluctance to ditch legacy systems, and projects are usually iterative on existing systems. It takes a brave sole to think outside of this box, but this is a source of strategic advantage to organisations based in more forward looking cultures.

David, Dennis, You are misunderstanding my point about process here. I am not arguing that a computer system should simply replicate an existing manual system. What I am saying is that a pre-requisite of automation is that a good manual system must already be in place. If it is not, don't automate at all.

To illustrate, let's take this episode as an example. Our friends in the government decide they want to introduce a system of tax credits. They decide how they want it to work, embody this in a bill, and get a law passed by Parliament.

With the law passed, they go to HMRC and ask them to put this new law into practice. And they give HMRC a rulebook which says how how they intend the new system to work. Let's call this Rule Book Number 1.

HMRC then try applying the new system. What happens is that lots of cases come up which the politicians haven't thought of ("undetected gaps in design", as they are called.) The powers-that-be make a decision on the case, and the rule book gets revised. The Rule book now goes through several editions. Finally, all the possible cases have occurred and with Rule Book version 3 or 4 we now have a system that works.

Where HMRC went wrong in the Tax Credits project was that they tried to computerise Rule Book Number 1 (the "how we think it's going to work in theory" version). It should have been Number 4 (the "how it actually works in practice" version).

This goes off topic and then comes back so please be patient.

For those interested, EDS Fellows recently established a blog style site. Their not currently commenting on certain project failures (understandably) though I think you might find they will talk about the issues around big ticket projects at some stage in the not too distant future.

The reason I believe this is because I had an interesting conversation today with Charlie Bess one of the Fellows.

I'd torched EDS efforts as poor. Charlie provided an eloquent response and we subsequently engaged in a fascinating though confidential discussion.

Which proves that the small man CAN have a voice at the big man's table. Provided the big man is prepared to let them speak. In this case EDS scores 10/10 for me.

Will Paul Stobart or any of his senior people step up to a similar looking plate?

And to David's point - I'm 60% there with him. But I do believe the responsible consultant has a duty to point the way when it is clear the client is asking for or suggesting something that doesn't have a hope in hell of staying in scope or being delivered. Either that or withdraw from the job and explain why. That's 10%

Isn't the reality that at a public sector level, there really isn't any public sector IT or IT management as it has almost all passed into private hands? The expertise therefore to manage large sale projects doesn't really exist. Therefore, I'd argue there is an even stronger case for greater transparency and accountability at the private level. That's another 10%

Where I disagree with David is in his narrow defence of process. As we're seeing with new technologies, things that had no process in the past can now become part of process. That's a major exception to David's thesis. 10%

In many integration projects, the object is to discover processes and process redundancy. Kinda blows a large hole in David's arugment because this is not about turning over manual to automated but developing best practice processes that CAN be automated. A fundamental difference. 10%

Where I really disagree though is the implication that computerisation directly replaces existing. That is a zero sum, zero ROI case because he's only talking about speeding things up and assuming some level of perfection in manual processes. That is nonsense. If you are thinking in those terms and believe it to be true then you wouldn't take that course at all - you'd offshore. 20%

I'm not misunderstanding David C's original posting. I just disagree, for all the reasons stated and more. But only because I apply a different methodology to these problems.

Whilst I agree with most of what you are saying,

"You shouldn't attempt to computerise anything unless there is a mature manual system already in place."

is that really realistic for something brand new?

I take your point

David
I completely disagree with the last paragraph of your second post, and I completely agree with the last paragraph of Dennis's post. Now you've compounded it by reiterating your argument in your third post.

Your saying no technology based process is valid unless there has been a manual system in place and bedded down for years? Come on, that's ridiculous! There are plenty of places where technology is the trigger for a business process improvement, which could not have been practical with a manual system. How about material requirements planning in a complex manufacturing environment - totally impractical to do manually once you are making more than a few multi-level assemblies. Or Internet based supply chain management solutions, and loads of other examples. A good consultant with experience of practical business process improvement can do wonders in streamlining processes, save significant sums for clients, and not by replicating existing manual systems. I know, because I have years of experience working alongside my business partner who is one of the best I've seen, and you only have to talk to any of his (our) clients.
David Terrar
mail: dt@d2c.org.uk
web: http://www.d2c.org.uk and http://www.twinfield.co.uk
blog: http://www.businesstwozero.com

Tom, the National Audit Office report says:

The new tax credits represented for the department a major challenge in an area of work which was relatively new to them. The level of the problems caused to tax credit claimants and employers as the system went live demonstrated that there were undetected gaps in the design of the testing regime for the new systems.

In other words, there were lots of things which HMRC hadn't thought of which only came to light when they started testing the software.

It's the job of HMRC, not EDS, to say what what the system should do. This must be defined in writing and then frozen before EDS write a line of code.

If HMRC couldn't do this in the first place, no blame can be attached to EDS.

In this particular case the tax credits legislation was so new that it would be impossible to write a full spec anyway until it bedded down. If they had any idea of what they were doing, HMRC would never have tried to computerise the tax credits system in the first place.

You shouldn't attempt to computerise anything unless there is a mature manual system already in place. Over the years the manual system winkles out all the possible anomalies, special conditions etc. You can then write your spec confident that the new computerised system will cover everything.

David - Do we know that to be the case?

RichardR,

"isn't that unrealistic for a brand new system"

Absolutely, it is unrealistic. Therefore HMRC should have rejected the whole idea of computerising the Tax credits system.

Computers are enormously efficient but very inflexible. Pencil and paper isn't so efficient but is very flexible. In the case of a brand new system you should start with pencil and paper. As all the things you didn't think of come to light, it's easy to modify a paper system, whereas a computerised system may have to be totally rewritten.

When the system has finally bedded itself down after a couple of years you can then think about automating it. But if you automate before an efficient manual system is in place you simply "speed up the mess". David

Personally I believe that the only way to reach a fair settlement for the taxpayer is to scrap the whole tax credits system.

It has been an absulute nightmare for most claimants and the only ones who have really benefited are those "clever" people who thought of it in the first place and those who keep investigating where the system has gone wrong.

It is about time some heads should roll.

Tom, the original design EDS were given probably was perfectly feasible. The problem is that once the project was under way the civil service started changing it.

Whatever EDS's faults may be, it is simply impossible to write software when the client is constantly changing their mind. The root cause of all these government IT fiascos is that the civil service is incapable of coming up with a comprehensive specification before the coding starts.

There was a front page article in last week's Sunday Times about delays in the £6bn NHS project for the same reason. Billions more of taxpayers' money will continue to be poured down the drain because of the gross incompetence of the civil service.

Richard Mannion says "EDS are an easy target. They weren't responsible for designing the system. They computerised what they were given."

So when did EDS say "This cannot be done, so we will not take on the contract, and save you several million pounds of UK taxpayers' money"?

If they knew it couldn't be done, they should not have taken the job.

By the way, do we know how much we paid EDS in the end?