Our 'solution is killing us in a number of areas' IBM said about doomed £175m Co-Op Insurance project IBM's delivery lead on the collapsed £175m Co-Op Insurance IT platform project told a colleague the project was "hurting" Big Blue, the High Court has been told. The claim came amid the ongoing legal proceedings between the two companies in London, England. As reported at the start of the trial, the Co-Op alleges IBM was …
175 million.. spent on what? An insurance company so.. a cutover of all their customer and policy data? Nightly jobs that interface with BACS to take and receive payments? Document production runs? A few web apps to apply for new business and service policies? Just how can any of that even approach $10 million let alone $175 million? Just literally, what the fuck are they spending it all on? It's a life insurance company. With a few million customers.
Project managers, project manager mangers, project manager manager's managers, lawyers, the lawyer laywers, the lawyer lawyer's lawyers, hotel conference rooms with accomodation rather than meeting rooms in house etc.
This would be about right. I spent some time working at the co-operative banking group and we had a 2.8:1 ratio of PM's to Technical/Architectural staff.
We once spent two weeks in meetings with one PM after another in a wankathon-carousel of the same questions being asked about how we could shave time off of the delivery...and they didn't quite grasp it when told to stop dragging us into the same meeting and talk to one another. Unfortunately, their PM's just gave the impression of wanting to thorpedoe the whole project
The Co-Op is a general insurer as well as a life insurer. The comment about aggregator websites makes me think that is what we are talking about here.
Insurance in the US is very different to that in the UK and it is not possible to take a US system, make a few tweaks and find that it is good to go. When IBM thought it was a software company, it knew this. The guys at the Co-op should have known this. So for this fact to "emerge" during the project, then someone (everyone) hadn't done their job properly.
It's not a small job. It's one that requires a great deal of understanding of UK insurance products, sales and business process - and as I said, the UK does it very differently to the US. We're talking about "ERP" for insurance not a billing and printing system.
And to put the cost in context - about 20 years ago, the cost of taking another US system and just doing the changes for UK car insurance (before all the go compares) was about £10M. (that's UK quid),
Now, $175M for a whole set of insurance lines seems a bit generous, but there must be an awful lot of client and subcontractor management in there.
Had they asked me, then I could have done it for less .. erm done it for the same price but with a certainty for delivery as I could have put a team together who had done this before -- and bought my yacht.
LITERALLY this is my solution to everything IT related. Big glass box in the middle of the office with like, 10 suitcases each containing a million pounds. Team of 10 good coders. Literally, that is all anything IT related ever needs. Anyone claiming any IT job requires more than 10 people or costs more than 10 million is a liar.
It's not the IT work that costs, but the documentation and paper trail insisted upon to cover the arses of both parties, even if project is a failure there is enough paper work to ensure a new porche or 3 for the lawyers involved. With a new set of golf clubs, skies or wind surfer for each cultural difference between UK and US business law the toss can be argued over. Wouldn't want the leeches being forced to consume blood would we
Those that are any good are few and far between, and totally swamped trying to prop up offshore. If management took their heads out of their arses they might wake up to that fact.
However, I suspect they are way too busy chasing their bonus though.....
After employing numbnuts like Lennart Poettering and Ulrich Drepper, and foisting SystemD on us I'll be quite happy for RedHat to disappear up IBM's fundament.
Posted from a Void Linux machine (no SystemD and usi g the musl C library in place of glibc).
Innovation Group was brought in by IBM to customise its US-specific white label insurance platform for the Co-Op's use. It rapidly emerged during Project Cobalt that the product needed significant work before it was fit for use in the UK market.
So the software was for the US insurance market and you brought in a subcontractor to customise it for the UK market. Your product, your subcontractor but not your fault....OK good look with that.
That struggles with the concept "rest of the word" and hardcodes stings to read "resume" for "cv", "zip code" for "postcode", and "state" for "country" ...
Best avoided in my experience. That's before you get started on any accessibility issues they will never fix. A few UK companies have found themselves on the wrong end of the Equality Act over that one.
If you could do it yourself, why would you contract with someone else to do it?
Which then leads to the obvious question, if you can't do it yourself, how do you expect to be able to provide sufficient details for someone else to do it?
In fairness to Big Blue here, they're not an insurance company. They're an infrastructure and services provider. Coop need to accept responsibility for having some skin in the game to work out what infrastructure and services they need provided, and making sure they work with IBM to get the desired result.
You can't just throw your entire business model and historical IT infrastructure at a supplier with the expectation that they'll just take care of it all for you so you can wash your hands of it. Then complain when someone who isn't in your line of business doesn't do it the way you think they should.
"In fairness to Big Blue here, they're not an insurance company. They're an infrastructure and services provider. "
You misspelt "They're a sales and financial services company that look to entangle customers via IT projects".
Wrong in so many ways.
IBM had an insurance product, and (I imagine) sold the UK market as a mod which the client would pay for. If the modification was more complicated, usually there's some sort of cost-split arrangement. This gets a resaleable product at a far cheaper price than in-house dev.
The problem in this case is the cash piñata client didn't shut up and pay up while waiting for negociations on the cost-split.
Once upon a time, software selection was done by writing a requirements document. This was then used to get a written quotation from a variety of qualified software package vendors, usually three or four vendors. The vendors were told as part of the bid process that they MUST declare one of defined compliance responses for each reqirement ("Meets in full", "Meets in part", "Requires modifications", "Cannot be met"). The vendors are told that the compliance response will become part of the purchase contract if they win the business.
The buyer then runs demonstrations of each package. The buyer also gets written assessments from companies which are already using the software package, to include comments about how much modification the package has needed.
Finally, the buyer chooses a package (or not).
That was then. Today, it's my understanding that writing a "requirements document" is thought to be not only unfashionable, but useless. This report in El Reg would seem to show that there is SOME merit in old fashioned, unfashionable package selection processes. They may take some time, but perhaps they would cost a bit less than £175 million. Just saying!
@Mark_110
Typical "user story": "I told you lot ages ago that we absolutely had to have <X>. Your idea <Y> is complete c**p."
*
And, of course, the obligatory quote from the Agile Manifesto: "Working software is the primary measure of progress."
*
Why do I think the use of the word "progress" is a joke in this context?
I was involved in one of these large projects, we had about 40 people from all over the company involved in writing the requirements and reviewing the vendor responses. It was between our current vendor and 3 others. In the end our current vendor's proposal was ranked dead last. We put together our recommendation and sent it up the food chain for approval. The CEO picked our current vendor.
Then 6 months later he left to become CEO of another company, the parent company of our current vendor.
Today, it's my understanding that writing a "requirements document" is thought to be not only unfashionable, but useless.
Yep, right up to the point that the IT director and PM realise that project and solution is essentially a truck load on manure dumped in their laps. At that point the review meetings turn hostile.
The Company demands certain functionality
The vendor calmly points out they would be more than happy to deliver that functionality. However, as that was not in the original agreed specs it's a change request and they will need to provide an estimate for delivery. Depending on the estimates, this of course then means either a revised priority list or timeline for delivery.
Rinse and repeat as the IT director and PM work down the list of the recently completed requirements document.
Of course we have an insurance solution. Seriously, off the shelf.
Of course, there are just a few minor tweaks that will need to be made to cater for the UK market. But you are getting a bullet proof, proven solution used by over 30% of the US insurance Companies. You wont regret it, no one has ever been fired for choosing IBM !
This doesn't surprise me.
For obvious reasons anon and being a bit vague here, but...
More than a decade ago, IBM came into my organisation with a brief to do some work, basically replacing some mainframe systems with midrange (Unix-y) systems.
Their final solution included modifying their own COTS products, not just modules or plugins, but complete custom source-code updates, for our organisation as most of the COTS products were only 90% of the way to what we actually needed - even though the contract required COTS software. After ~5 years, they still had only migrated 50% or so of the capability off the mainframe to this 'COTS' software stack. When IBM lost the contract after several years (and a $600 million- closer to 2 billion if internal rumours are to be believed) later, they stopped supporting this customised version of their COTS software, and refused to provide the source-code so we could maintain it ourselves. Since the original contract envisioned all the 'middleware' (e.g. Java Application servers, process servers, brokers, portal servers, etc.) all being COTS products, thus maintainable with standard vendor-support contracts for patching/upgrades, or even relatively easy migration to other vendors equivalent products, the contract didn't include provisions for source-code/copyright transfers.
Since the project never fully replaced the mainframe and assorted systems anyway, and we couldn't maintain these 'replacement' software systems without the source-code (or an inflated contract with IBM to maintain it), it took ~3 years to migrate those functions back to the mainframe that we still had - which has been chugging along beautifully in the years since - and still had to support anyway, because the migrations only ever migrated about 50% of the functionality off (instead of the projected eventual 100%).
Fun times. Not.
Seems stupid of the coop to migrate their whole business to a new system instead of doing it in chunks with the complexity of insurance. However IBM sound like they've completely mismanaged the process, this is a specialist area and best undertaken by a specialist software company. Recently had a similar experience where our companies system was due to be replaced by one written by oracle, three years and millions later they decided to stay with the existing one after all.
Known IBM for a long time and I have also worked on agile projects. I can see a number of reasons why the project has failed.
1.I have seen how most of their managers lie through their teeth in client meetings.
2.Apart from that their staff are picked for projects based on their regional affinity and language they speak (especially in the Indian context) rather than on merit.
3.Most folks think Agile means no deadline to complete work.... so they take it easy.
I have seen many IBM projects fail. This one did miserably.
Waterfall wins here!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
