Pennsylvania sues IBM for fraud over $170m IT upgrade shambles IBM has been accused of fraud for under-delivering an over-budget IT upgrade to Pennsylvania's unemployment compensation systems. The US state's governor Tom Wolf (D) has sued IBM over the upgrade, which saw Big Blue collect millions of dollars in cost overruns on the $110m contract. The contract was issued in June 2006 but …
It is also an issue with many large consulting projects. Organizations typically bring in consultants for projects that no one wants to touch at the organization because the requirements are poorly defined, there is an undocumented legacy system, etc. High risk projects. Rare though is the consultancy that will take a look at a mess which will result in $100 million in revenue and no bid.
Or maybe he has, and has decided enough is enough. I would like to see governments and purchasers of large IT projects start slinging sue-balls at contractors (and contractors slinging sue-balls at piss-poor project management) and bringing some accountability (ooh, that's a dirty word) into these large projects.
" according to the complaint was thus awarded because of Big Blue's representations that it was the only vendor with the type of proprietary databases capable of providing a totally integrated computer system."
So, lack of due diligence or exercise of rudimentary intelligence during the THREE YEAR bidding process.
I don't know if you've ever been thru such a procurement process.
You end up going through several rounds of RFIs RFPs interrogatories and interviews.
In many cases IBM could be helping to write the RFIs RFPs such that they become the obvious choice.
When you have an RFP process that runs 3 years, it requires an investment on the part of the bidding company. Not many companies have the stomach to go through a 3 year process.
When you consider that the state probably has both mainframe and Unix/Linux with some AS400 tossed in, it will end up being IBM or an IBM partner. Again, not many IBM partners can go across the board on these platforms. They will either have to partner or outsource / subcontract specific skills. The long due diligence will source these shortcomings out and force them to drop out.
Its not a fault of due diligence, but a desire for a single vendor to do it all thus a single throat to choke.
Well, I've run into that sort of thing before, in the early 1980s.
I worked for a refrigeration company that bid on and supplied outside coolers for the US Military to be installed at Reyjavik, Iceland. When all was installed and working, I got a call from the Navy: the magnetic door gaskets called for in the specs (written by a competitor) were not installed. I explained our panels were made of aluminum which would render magnetic door gaskets useless, but I might as well as saved my breath. Guess who got to fly to Iceland and install magnetic door gaskets?
"In many cases IBM could be helping to write the RFIs RFPs such that they become the obvious choice."
True. Which is why any smart customer should be very wary if they let this happen.
"Not many companies have the stomach to go through a 3 year process."
I'd say all of "The Usual Suspects" in UK government f**kups would be there.
"When you consider that the state probably has both mainframe and Unix/Linux with some AS400 tossed in, it will end up being IBM or an IBM partner. "
Except that's a problem in Extraction Translation and Loading.
The idea that only IBM has a database that can do what they asked smells like the rankest BS to me.
"Its not a fault of due diligence, but a desire for a single vendor to do it all thus a single throat to choke."
But IRL no vendor can do it all and IRL they farm it out to a bunch of no-name contractors on condition they don't let on they don't really work for IBM/CSC/SAIC/SVC/Crapita/Atoss etc.
Part of the problem is that the existing staff are so overloaded (because they "resourced" too many people) that even if they bring in new people, no one has the time to even train someone to take on some of the load. Don't ask me how I know. And often when IBM claims to have "experts" in a technology, it means they'll ask some tech of they've ever heard of a product, and then declare that person an expert on it. (again, don't ask how I know).
AC because, obviously.
The IT consulting industry, with IBM at the head of the pack, has completed their long promised transformation of IT project processes to the point that failure is now structural, "baked in", thus guaranteeing a never ending supply of failed projects requring a bailout by IBM or one of its peers. All the better if a given project suffers multiple failures, requiring multiple emergency bailouts. The parallel crapification of IT services using many of the same strategies (outsourcing, offshoring, fake integration and continual gutting of the knowledge base) was of course completed some time ago, and has already been accepted as the "new normal" by global executives everywhere. Clearly IBM has every reason to believe the same will soon be true for project work. The Commonwealth of Pennsylvania is tilting at windmills: "Abandon hope, all who enter here".
"Its the norm because most people in IT can't do their job properly."
How many times have you found out that Management or Marketing have made promises for delivery schedules or functional requirements that are impossible to meet?
And of course, it's never their fault when you fail to make good on their unrealistic promises, now is it?
Blame where blame is due.
Con-sultancy management certainly but it's usually the Sales (or pre-Sales) guys in those slick Powerpoint presentations in exotic locations that usually promise the world for $0.02 to the potential marks clients
This sort of s**t always starts with unrealistic expectations.
Usually on both sides.
"And of course, it's never their fault when you fail to make good on their unrealistic promises, now is it?"
The best thing to do when you discover such promises have been made is to start writing your resignation.
You can do it now with a reference or do it later when they're blaming you, but if you do it now you can parachute in later for a large sum, perform a heroic rescue and be handsomely paid.
The failures I see generally start with not understanding what needs to be done and not being able to put together a plan to implement it. It's hard to find people who can get that part right. I'm in the position of trying to find my replacement and it's discouraging what is available.
Well, this is the 3rd major IBM project failure that I can remember from the last year or so, They screwed up something with the census in Australia, they screwed up a payroll system in Canada and now this.
They excel at colossal project failures, they have the best failures :)
Probably contributed to the problem. Most likely on both ends of the contract. The original specifiers had no knowledge of the scope of the project, and as careers go, people came and went. High priced consultants (on both sides) came up with the "right way" of doing things, and it went downhill after that.
Sounds like there were a LOT of cooks making this broth, and spoiled it as they went. Everyone trying to protect their little fiefdom created over many years.
Typical government...
I have worked for several "agencies" in govt over the years and if there is one thing to be sure of....none of them know what they have, what they want, or the level of effort it will take to get it. Dont worry though they want it done in a year, and then are surprised when they fail miserably. Most of the time they cant even define what problem they are trying to solve, and will throw loads of money at the undefined problem. It actually works out in the vendors favor usually because they collect tons of money while delivering a substandard product (not entirely their fault), but since lawsuits are so rare it makes sense to promise the world knowing the customer will muck it up and keep paying for years and years in most cases.
Sorry Mr Wolf, you've confused base incompetence with criminal intent. If you understood what a shambles IBM is, you'd understand that actually planning to defraud you is well beyond their capabilities.
And in my experience, to IBM's defence (choke), projects that go this way typically indicate a thoroughly screwed up customer who can't settle the project scope, can't take responsibility for decisions, thinks all unforeseen issues should be handled by the supplier at their cost.. that's just my opinion. Based on a bit of experience. You know, like 16y working there.
You need to learn US law.
This isn't a criminal lawsuit but a civil lawsuit.
So this isn't anything about a plan to defraud, but about the claims IBM made during the procurement process to win the contract. Its more of a question on their ability to actually deliver the promised solution.
These suits are hard to win and end up either in arbitration or settled out of court. As you point out, scope creep is one issue, however it depends on the contract.
Having written quite a few SOWs and negotiated MSAs, you'd be surprised what goes on.
(Yes, I escaped from the borg many moons ago)
Customer deserves to get shafted. No sympathy for them - and it's clear they're not even clued up to know what they were buying or how it was going to work. It doesn't matter what IBM told them - the customer just isn't qualified to make an assessment of whether it was genuine or fraudulent
Au contraire mon ami.
You have to understand the larger the project, the longer the due dillgence cycle because there are so many moving pieces and when it involves the government, there's a complex dance which is supposed to show that there wasn't any special favors done.
The problem isn't being able to prove that IBM mislead the State during the procurement process, but to show that it was why they couldn't get the job done. IBM will make arguments that it was the State they mislead IBM in their representations. The law isn't black and white but gray. And in a civil trial things can get wonky. It depends on the judge, the lawyers and even interpretations of the facts.
IBM will end up with a slap on their wrist.
The failure here was in trying to get a single throat to choke and relying on internal IT folks to mange the program office.
I would suspect one the major culprits is the state had no defined idea of what they wanted from day 1. Adding to the misery is every mismanager added their own pet project/peeve to what were supposedly the specs The result is a set of specs that probably contradicted itself multiple times with no one at the state taking a responsibility for sorting out the mess.
Also, remember Itsy Bitsy Morons are doing the project so you colossal incompetence on both ends.
Because only they can afford the bidding process.
It's around a million per year in work.
Fujitsu, Capita, Accenture... Etc are others who fail but when no one else can risk a mill or so on bidding you get the same people.
The government in the UK even tried to make their own in house dev company but that's not really working out too well.
That's not just IBM, it's most large consulting companies. It's not all their fault, I've dealt with government customers at the state level and they all have some basic issues that are part of their basic makeup.
1. Their systems are poorly maintained and often outsourced to the cheapest vendor.
2. While the bureaucracy is entrenched, the political climate is subject to wild changes at any time.
3. Nobody is willing to take charge in a large project.
4. They have no idea of the scope or their own systems and have no experience negotiating this type of thing.
5. These fools wanted to use *proprietary* databases? That implies choosing hardware and software that's also just as proprietary. Locking yourself into the tender mercies of IBM is a very bad idea.
6. Allowing a negotiation to go on for three years?
That said, IBM is a horrid employer and their track record on large projects and outsourcing is terrible for a number of reasons:
1. Even the slightest revision of a specification is an "opportunity" to bill extra.
2. They roll in good people at the start and they will roll out to be replaced by whatever they can get cheaply. (They always seem to be losing money on a project from day one.)
3. There's a ridiculous amount of overhead that is part of any project, these guys are more top heavy than most.
4. IBM has become an employer to avoid in the US. People are constantly being pushed out the door and replaced with inexperienced people from some other part of the planet. Imagine being billed for someone experienced at 250 an hour and having him replaced by someone in Malaysia with zero experience. It happens.
5. People to fix troubled projects are becoming fewer and fewer and they are stretched thin. They're also deployed too late. IBM has lost a lot of contracts that way. There are many documented instances of their long term contracts that never get to the end of the contract without being cancelled or penalized. (Easy enough to find.)
Governments are still a lot more effective on "big picture" discussions then they are on accepting responsibility for realistic designs and accompanying time-frames.
It is interesting that the same governments that can order massive dams, canals, rockets to the moon, satellites etc. can still treat software production as if it is something "others" should be creating and using. Ownership is hard if you only want to write high-level plans.
The industry has successfully brainwashed government officials into believing that big bucks can be saved by
(a) contracting everything out
(b) consolidating and "modernizing" government IT; and
(c) getting rid of in-house staff.
Of course this leaves the affected government entities in a hopeless situation when it comes to following through om this agenda.
When a company bids on a project, especially a jumbo-sized project, they are bidding a team. They are showing the customer specific people with demonstrated expertise.
Later a different set of management comes along and decides those people are expensive. They can be replaced with lower paid ones with nominally the same skill set.
Hilarity ensues.
What almost no company acknowledges is that the team put together immediately becomes more valuable when a contract is won. And they continue to increase in value until close to the end of the contract. Acknowledging that works against the company's perceived interest in having a competitive market for substitutable labor, despite having a locked-in contract.
One way to address this is to include a contract penalty for each substitution on the development team. Unless the contractor is taking 100% of the risk for cost overruns, the cost of bring a new developer up to speed, which we can assume is 5-12 months of work, needs to come from the company. That time can't be just billed to the government as if nothing had happened.
Companies are going to scream. They will say it doesn't give them management flexibility. By which they mean employees have some leverage in getting raises, and some protection from being outsourced. In the long run having experienced committed developers helps the project, the customer, and the company. It just doesn't serve the purposes of short-term, cost-cutting managers.
IBMs implementation of the Queensland, Australia governments Health Dept payroll system went $1b over and still doesn't really work properly. Im sure the dept changes spec several times but to sign away their right to sue was the most incompetent thing they did.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
