back to article IBM: Co-Op Insurance talking direct to coding subcontractor helped collapse of £55m IT revamp project

IBM has blamed ex-customer Co-Op Insurance for the crash of a £55m project centring on Agile software development, but admitted the systems it built "would not have" boosted the insurer's top or bottom line anyway. This is the latest exchange in a £130m lawsuit that was first filed by Co-Op Insurance against Big Blue at London …

  1. Doctor Syntax Silver badge

    AIUI Agile involves users talking directly to developers. Presumably in IBM terms it just means removing a couple of links in a much longer chain.

    1. Anonymous Coward
      Anonymous Coward

      AIUI Agile involves users talking directly to developers

      Back in the day, we had developers and we had users. Then, slowly, all the hangers-on moved in - the business analysts, project managers and others who had little understanding of either technology or the business. Soon developers were forbidden from going anywhere near users. Instead of a 5 minute demo with comments about "can you remove that field and add a field for X? Ta.", we're into reams of process, documentation, "change control boards". You have projects with 15 people involved and only one is actually capable of cranking out code.

      Yeah, I'm cynical, but the waste of time and money I see is depressing beyond tablets.

      1. Mr Benny

        "You have projects with 15 people involved and only one is actually capable of cranking out code."

        Don't forget that probably 10 or 12 of them are only there to take the blame when it goes wrong.

        But even if its just you and a manager it can still be a clusterfuck if the manager is a technologically clueless bell-end as I had to suffer for a couple of years. His idea of security was putting the post-it with his password on it in the drawer and his design "decisions" were presumably something he dreamt up while smoking some weed. In the end I just bypassed him and collaberated with the IT director to get the project finished. The manager left eventually to go and do an MBA. Enough said.

        1. Trollslayer

          MBA = Masters in Bollocks and Arseholery.

      2. Tom 7 Silver badge

        RE AIUI Agile involves users talking directly to developers

        I used to demo code that had been developed via sales/management (salem for short) and at the same time demo code that I'd developed working on the principle that there were only a few solutions to the problem we were meant to be addressing and it didnt take more than a couple of minutes talking to the customer to realise the solution offered by salem indicated that they hadn't a clue or thought a shopping list really would benefit from a cloud base blockchain and they could charge a lot to get me to maintain that so I'd let the dog see the rabbit and let the customer get salem to adopt my solution and then pretend to code it.

      3. Valeyard

        the business analysts, project managers and others who had little understanding of either technology or the business

        So... back in your day a developer at the HMRC would know every little piece of tax law, for example? I call BS

        1. This post has been deleted by a moderator

          1. Valeyard

            Re: @valeyard

            my mates? B ark? i have no idea what you're talking about

            What I do know is I worked for the HMRC as a developer and know frig all about tax law

          2. MrPSB

            Re: @valeyard

            Remind me again what happened to the remaining Golgafrinchans after the B Ark had left.

        2. localzuk Silver badge

          What single developer would be developing something that encompassed "every little piece of tax law"?

      4. Hollerithevo


        When I see that the only testing will come at the end of a project, I know already that it will fail. Managers never get that if the development is finished, and you have, say, four weeks to test before it goes live, where is the time (and money) for correcting problems? Why did the project carry on with problems embedded in it? Stop and test, stop and test, let the users go through both structured tests and personal mayhem (to discover the weirdness that you will never find out until Sharon and Tim do what they always do, in defiance of logic or sense), fix and continue. The UAT at the end then just becomes a final run-through and a bit of the demo for the C-Suite. There should be NO surprises at that point.

        1. baud

          Re: UAT

          "Stop and test, stop and test"

          Or even better, have a separated QA team who is testing the builds as they are available and any bug found are quickly fixed (well, depending on impact of the bugs). Also even if the bugs are known before release, they can be documented.

          1. Alan Brown Silver badge

            Re: UAT

            "any bug found are quickly fixed"

            What seems to ACTUALLY happen is that devs get slower and slower to respond to bug reports and then eventually stop caring altogether.

            Of course that could be manglement getting in the way.

        2. Dabooka

          Re: UAT

          All I know is my missus is a product manager and recently has had problems where the lack of BA / QA etc has resulted in the rule of unintended consequences being played out when developers have gone off plan. No bad intentions of course, that goes without saying, but when you are talking about calculating tax for example, you really do have to know (or at least know to check...) every piece of minutiae.

          There's always a running battle between dev time, testing and getting out to market, where the various factions are always the 'hard done to' and 'their managers don't get it', but that is no different to many other sectors. Sure the actual output may vary, but the adage that managers know nothing and developers / teachers / machine operates etc are being held back by meddling incompetence is often little more than a lazy stereotype. The reality is not as clear cut in that.

          Now manager employed solely to hit data targets (such as those found in NHS) is a concept I cannot get behind at all.

          1. Anonymous Coward
            Anonymous Coward

            you really do have to know

            "but when you are talking about calculating tax for example, you really do have to know (or at least know to check...) every piece of minutiae."

            Technically no, you shouldn't have to know every piece of minutiae, just have a bit of clue.

            In Agile, the user story should furnish you with not just the logic you need to implement, but also example inputs and expected outputs.

            You start by writing a test which sets up the example inputs and expects the specified outputs ... then you set about writing code to implement the documented logic. This usually works very well, and not only guarantees that you got your implementation right but also leaves you with a repeatable automated regression test which a continuous build platform can re-run everyone time someone modifies the code.

            However, places where this starts to go wrong, are where -

            a) The developer doesn't set up their test case correctly, resulting in the test case not checking the logic correctly

            b) The developer either thinks they know better or is lazy and modifies the test case data in some way, again resulting in the logic not being checked correctly

            c) The author of the user story only covers the main logic, and ignores edge cases.

            I've seen all of these happen loads of times and it always hurts in the end.

      5. Doctor Syntax Silver badge

        "Back in the day, we had developers and we had users."

        Yup. I was there. I had a strong preference for development tools which would let you lash up a working demo/prototype on the fly whilst talking to the user. It did depend on having good users. I had a colleague who'd put together a demo and then find the users rejected the whole proposed system because they didn't like something about it and couldn't get their heads round the idea that it was intended to refine what it was they wanted.

        "Then, slowly, all the hangers-on moved in - the business analysts"

        It depends on the business analysts. If you get a good one it's great to be ablel to bounce ideas off each other. I've had that a couple of times.

        1. anonanonanon

          Yeah, talking to a user is great, that user has this one field they want to do their task a little easier, maybe it has impacts on others users, that one user don't care, doesn't care that other users don't need that field, it gets implemented, other users look at it, what's it for? now when they tab through they get this extra field where there wasn't one before and it screws up their workflow, what do they put in it anyway? can you just take it away please?

          Or maybe you'll need to make some major refactoring to implement their 'small' change, costing your valuable time, for something that's just not really worth the effort.

      6. Anonymous Coward
        Anonymous Coward

        Don't forget you now have those with "Digital" in their job/department title adding to the problem.

      7. Anonymous Coward
        Anonymous Coward

        Unfortunately the pure user/developer split only works if everyone is reasonable. For anything enterprise based I would absolutely run the whole fecking shebang of process, documentation, and change control.

        There was one historic incident where we threw in some functionality (for free) to an update upon customer request to be nice. There's a quid pro quo here - if someone gives you something for free, if there are any issues you're reasonable about it. There was a mild issue/disagreement about what was requested, the customer denied saying things they absolutely had (probably just verbally, yes - I know), and it created hassle.

        The next time the customer asked for another change the quote was for two days development. 'Why is it so high, previous quotes were less' asked the customer. Back we went with a technical explanation which was at least partially true, but a fair bit of the (not broken down) quote consisted of everything being meticulously documented and recorded so there could be absolutely no disagreement. It didn't include a WDLY time bonus, despite the temptation.

    2. Commswonk

      AIUI Agile involves users talking directly to developers making it up as you go along.

    3. Cavehomme_

      It's not Agile...'s Fragile.

      This methodology has become flavour of the decade and is used way too often for completely inappropriate developments.

      Another example, MS use Fragile for Windows 10 and Office 365 development; I rest my case.

  2. Warm Braw Silver badge

    "Blame the customer" is not new

    Back in the old days, I had a vacation job at an IBM sales office; this was a period when the focus was on shifting iron. The cardinal rule was that if a customer asked if an IBM computer could perform a specific task, the answer was always "yes": the hardware could do it and it was the customer's problem to get the software written and if they'd shelled out for an expensive piece of kit and found the task beyond them, it was their lookout.

    I couldn't presume to say whether such attitudes persist today, but I would have thought that a contract for delivery of software offered rather more scope for creative interpretation if one were so minded.

    1. Anonymous Coward
      Anonymous Coward

      Re: "Blame the customer" is not new

      As someone involved in an IBM-delivered project right now, I can confirm this is still consistent with my experience.

      Big Blue's modus operandi appears to be: put frightfully low effort into planning; assign personnel at the last minute with little-to-no project familiarity; inevitably fail to deliver functionality; miss EVERY deadline — then, only after the proverbial hits the fan, scour email chains for technicalities that they can blame the client for.

      There never seems to be a reply saying "we'll need more than that" when there's still time to fix it, though. Plus, when you try to arrange sorting it out, nobody from IBM is on the call because for some readon they STILL insist on using Lotus Notes which mangles invites.

    2. Anonymous Coward
      Anonymous Coward

      Re: "Blame the customer" is not new

      Has the same thing with their cloud offering. The two salesmen came in, basically said "we're the best, our system can fo anything". We eventually managed to get a trial account out of them, and it was the worst of the bunch (Amazon, Google, Rackspace). My "favourite" feature was our European hosted system migrating to the United States without warning as they'd run out of resources - with a consequent impact on page load times.

      1. Steve K Silver badge

        Re: "Blame the customer" is not new

        European hosted system migrating to the United States

        Wow - Wouldn't that have legal/data custody implications too that the end-client would be very unhappy about?

  3. Anonymous Coward
    Anonymous Coward

    If that's IBM's defence,

    I can only think they got their lawyer from the Co-Op

  4. The agile stoic

    Ermm, I think someone needs an Agile refresher

    Talking directly to the cross functional team doing the work and iterative drops, pretty sure straight out of the Agile playbook...

    1. badger31

      Re: Ermm, I think someone needs an Agile refresher

      That's pretty much what I was thinking. User stories -> Single drop sounds more like waterfall to me.

  5. steelpillow Silver badge


    Agile + single-drop release candidate = WTF

    Did nobody tell the customer?

    1. Anonymous Coward
      Anonymous Coward

      Re: WTF

      Customer should have known anyway that "psuedo-Agile" + single drop release is called " waterfall. Back in the 80's I'd do waterfall and then when deploying/testing I'd be doing what's called agile now.

  6. Anonymous Coward
    Anonymous Coward

    IBM's new corporate statement?

    "IBM ... would not have resulted in any increase in the [Co-Op]'s profitability or revenues".

    After 20+ years of demonstrating their inability to innovate in the IT space, maybe it's time they just made it their new corporate statement?

    Or is that thinking too differently? Like in a way that involves facts.....

    1. Anonymous Coward
      Anonymous Coward

      Re: IBM's new corporate statement?

      IBM innovate by buying (and subsequently destroying) innovative companies.

      1. Anonymous Coward
        Anonymous Coward

        Re: IBM's new corporate statement?

        > IBM innovate by buying (and subsequently destroying) innovative companies.

        Red Hat 5 years from now... not looking good.

  7. Anonymous Coward
    Anonymous Coward

    Both sides are bad

    Both sides seem to have a basic misunderstanding of Agile, the Co-Op for thinking that the software would be delivered in one Big Bang drop, rather than a succession of iterations *each of which delivers value*; and IBM for thinking that they should be a go-between for the user and the developer.

    Neither side seems to have known what they were doing, frankly.

    1. Richard 12 Silver badge

      Re: Both sides are bad

      The Co-Op seem to be claiming that there should have been multiple drops (79), and a payment at each one.

      That looks far more like Agile than the massive waterfall IBM seem to be claiming.

    2. Anonymous Coward
      Anonymous Coward

      Re: Both sides are bad

      Quote: "...Agile...a succession of iterations *each of which delivers value*..."

      When did the Agile community EXPLAIN to the User community that this iterative approach has a significant impact on the users?

      Namely that the BUSINESS PROCESS which is executed by users may need to be adjusted at every iteration?

      So...forms may change, process instructions may change, new processes may be introduced, old processes may be eliminated, and so on. The more dramatic the business process change, the more likely re-training will be needed. And the USERS need to plan and execute these steps, potentially at every iteration. This might be quite burdensome in a regulated industry, say finance or health care.

      Did the users know about this aspect of "agile"? Maybe that's why they thought a "single drop" would be best for them??

  8. Pascal Monett Silver badge

    What a sac of vipers

    This whole project stinks from the other side of the screen.

    The customer doesn't give the data to allow the project to go forward, then doesn't want to look like it's paying for software (wtf ??), then gets all huffy and claims that 25% sales loss is IBM's fault.

    I'm not defending IBM, but if what IBM says is true, that is one shitty customer.

    On the other hand, IBM, please : talking to the Agile team is what you're supposed to do.

    Unless IBM manages Agile with a Waterfall approach ? Hmm, that might explain a few things.

    1. joeW

      Re: What a sac of vipers

      At one company I worked we used to refer to their "Worst of both worlds" approach as the Wagerfall methodology.

    2. Mark 110

      Re: What a sac of vipers

      It doesn't souund like the project was suitable for Agile anyway. Not in the first instance anyway . . . "embarking on re-planning activities that not only adversely affected the project but also frustrated rather than assisted the Claimant's purported aim of vacating its legacy data centre,"

      So if the aim is to lift and shift why are you running an agile project which is good at introducing new functionality. If you want to rewrite and replatform existing functionality as part of the migration then thats big bang waterfall - do an agile thing after to deliver new functionality once you got the hard bit out of the way . . .

      My 2 cents, and I worked on the Coop Bank website replatforming (to IBM) so have some scars.

    3. Anonymous Coward
      Anonymous Coward

      Re: What a sac of vipers

      > ... if what IBM says is true, that is one shitty customer.

      There's very little chance what IBM is saying is true.

      That's the point of their lawyers. To say whatever it takes to minimise damage to IBM, regardless of facts.

  9. Anonymous Coward
    Anonymous Coward

    I'd probably side with IBM on this one

    I know a former employee at Co-op HQ. They described a chaotic hopeless cause of an organisation. This may not read across to Co-Op Insurance, but I rather suspect it does :-(

    1. Anonymous Coward
      Anonymous Coward

      Re: I'd probably side with IBM on this one

      I used to work at IBM and spent a lot of time at the Coop. As I reflect on the experience it's difficult to say who is worse. But ultimately I think it's the Coop.

      They used to have their "Good with Money" slogan on the wall of their canteen. Oh how we laughed.

    2. Anonymous Coward
      Anonymous Coward

      Re: I'd probably side with IBM on this one

      As an ex-employee of Co-op, there are a lot of the people in IT know fuck all about IT. They just sit in meetings all day, every day.

      BBC article about corporate culture:

  10. Anonymous Coward
    Anonymous Coward

    Case dismissed.

    You hired IBM. You got what you deserved.

    At any time before hiring IBM you could have taken the advice of Anonymous Coward Consultancy, which would have said 'Don't touch IBM with a faeces-encrusted 3-metre rod', thereby saving you £54,999,995.

  11. vtcodger Silver badge

    At its heart, the Co-Op's suit claims that software written by IBM subcontractor the Innovation Group had so many "deficiencies" that it was not fit for purpose – and had missed its deadlines.

    Sounds like current "best practices" to me. What are the insurance folks whining about? Surely they didn't expect a working product delivered on schedule?

  12. Anonymous Coward
    Anonymous Coward

    "an excessive number of defects"

    When is a 28% failure rate acceptable?

    1. James Anderson

      Re: "an excessive number of defects"

      There are defects and there are serious defects.

      I have worked on projects which went live which hundreds of defects. But they were along the lines of "Customers title 'Marquis' truncated to 'Marqui' on mail address".

      Had we had any "Orders entered on 29th February are lost" type defects another round of fixes and testing would be required.

      The important question is how many of those defects were "critical" and who decided what was "critic all"?

  13. Jay Lenovo

    If a company spends £55m, you'd think the result (or lack of) would be pertinent to a business's finances.

    Assuming the results were to be revenue nuetral, this was a really expensive case study.

  14. Steve Davies 3 Silver badge

    it all seemed a bit (Fr)agile to me

    I'll get me coat.

  15. vtcodger Silver badge

    At its heart, the Co-Op's suit claims that software written by IBM subcontractor the Innovation Group had so many "deficiencies" that it was not fit for purpose – and had missed its deadlines.

    Broken and late? Isn't that pretty much current state of the art/best practices for every software development methodology? Why did the insurance folks expect anything different? Not that I don't wish them luck with their litigation. AFAICS the only thing that might reign in the rampant overpromising and outright lying by software vendors is being held financially liable for their failure to keep their promises.

  16. Slarti Bartfast

    "showed a pass rate for 72 per cent for the tests that had been run".

    Personally if I issued a release for UAT and it had a 28% failure rate I would expect two things: 1, Massive personal embarrassment 2, The users ending the UAT early due to it "not working". To me that smacks of the devs not doing their own testing and just chucking it over the fence, either due to too much pressure from IBM or laziness.

  17. Zippy´s Sausage Factory

    Co-Op bank were one of the last holdouts for OS/2. Doesn't say much for IBM that a customer of that long standing ends up suing them. Alternatively, doesn't say much for the Co-Op bank that they appointed Andy Flowers as their CEO either...

  18. Anonymous Coward
    Anonymous Coward

    IBM sounds rather like Theresa May trying to blame the Brexit car crash

    on somebody else.

  19. cd

    IBM vs Insurance Company

    Not much to choose from. IBM likely doesn't have anyone left who knows what Agile is.

  20. Vanir

    Must be able to work to deadlines

    Is often on job specs, wishlists. This wish is often accompanied with a requirement that the 'ideal' candidate also has knowledge of and experience of Agile.

    Ah, the perils of user and developer stories not being written in the same jargon. Then there is the contract story.

    Was the contract written to an Agile methodology?

    Too many stories here, non of which is a bestseller.

    Too many deadlines from the sound of it as well.


    Unreachable code.

    1. Anonymous Coward
      Anonymous Coward


      That's the key point - IBM are usually good at focussing on the contract, if the payment milestones differ from what the customer now wants, tough.

    2. Anonymous Coward
      Anonymous Coward

      Re: Must be able to work to deadlines

      Too often sales/management set unrealistic expectations and then need to blame someone else when they are not achieved.

      Definition copied from Websters dictionary which says it all. I prefer the first option.

      1 : a line drawn within or around a prison that a prisoner passes at the risk of being shot

      2a : a date or time before which something must be done.

      b : the time after which copy is not accepted for a particular issue of a publication.

  21. Robert Forsyth

    Just Goes to Show

    I was under the impression (I swallowed their PR) IBM were much improved over days of past, but seem I have wrongly spouting rubbish - I am truly sorry to all those in earshot.

    My more direct experience is, they seem to deliberately choose a less common interpretation of the requirement* - for no financial advantage - just to show stupid the customer is.

    * we can all easily do this, invent an unlikely 'round hole' scenario and let it suffer the 'square peg' requirement.

    My IBM experience was the PC hell/help-desk was moved (outsourced) to a Canadian first-line call centre, I think the requirement was for a polite and English speaking call centre (like in Leeds or Ireland, perhaps). The Canadian call centre was quite good with late evening problems.

    1. Anonymous Coward
      Anonymous Coward

      Re: Just Goes to Show

      IBM are, if anything, worse than they were 10 years and much worse than 15.

      My favourite IBM help desk outsource was when the customer (from the SE of England) had contracted that their call centre be in the UK (allegedly because they didn't want to deal with Indian accents) and IBM helpfully serviced them from Greenock.

      1. Anonymous Coward
        Anonymous Coward

        Re: Just Goes to Show

        They should have demanded their call centre be in the South East then, if it was so important.

        I've lived in both Glasgow and the South East of England (live in the latter now) and stronger accents are equally unintelligible and have their annoyances (plenty of people here in SW London seem to think it's OK to say "we was" or "you was" for example; Glaswegians would say "youse were" etc.).

        Mind you, Punjab and Tamil Nadu aren't exactly the same either.

  22. PaulVD

    Agile waterfall

    It is a new development methodology known as Agile Waterfall. This is also the technique adopted by people who go over Niagara Falls in a barrel, and the success rate is similar.

  23. Anonymous Coward
    Anonymous Coward

    Developers and ego

    This thread is exactly why everyone else looks down on developers - creating something doesn't mean you're God!

    At least tell your service desks how to support it

    Or have you forgotten just how bad users are?

  24. clochard

    History repeats itself

    IBM has always sold hardware and services to clients who don't have the skills to manage software projects. In fact very few companies have the ability to implement any large software projects. Outsourcing a project can work only when the specs are complete and the success or failure lies in the hands of the software company in charge of delivery. Only when this wall of liability is present can the cards be played honestly.

  25. GruntyMcPugh

    No experience of the Co Op but,...

    ... I was Blue for a while, and saw one massive project for a UK charity collapse, largely because IBM had massively oversold the solution, and were creating something far bigger and more complex than was needed. The charity wanted a web site and the infrastructure to host it, IBM managed to interpret that as a P-Series and 16 LPARS (if I recall correctly).

    But as we say in the (non - IBM) office, if we're feeling particularly evil, we give our customers what they asked for,... not what they need. We weren't there when the Co Op had the conversations with IBM, so it's hard to know which donkey to pin the tail on.

  26. Anonymous Coward
    Anonymous Coward

    Contract signed after the Crystal Methodist Paul Flowers left then so being high on drugs can't be used an excuse.

  27. Anonymous Coward
    Anonymous Coward

    Many years ago I went on an IT project management training course for a global financial institution.

    Day one: the tutor explained that the course was to address the problem that "fewer than 20% of IT projects are delivered on time to spec and within budget".

    Several days later: our team's course work case study proposal is ready for presentation to a (real) senior manager. He looks at our proposal, significantly reduces our proposed budget, timescales and development team size then asks "how confident are you that you can deliver on time to spec and within budget". One of our number had a handy tip from a delegate on a previous course: "anything less than 100% confident will mean your team has failed the course". So we lied... Suppose one were to transfer what we learnt to a real project, I wonder what the outcome might be.

    Another related story: 15+ years ago we needed a file output from the mainframe once a quarter as PDF. The "well known mainframe manufacturer's" proposal was $100,000 to write a bespoke "print to PDF" module for the mainframe. I was told "the chairman has approved the expenditure, we just need you to give us a technical sign-off". My proposal: transfer the file to PC and spend $200 on the Adobe PC PDF writer. My management was only too happy to go with my approach and reflected their gratitude by awarding me an annual bonus of $0.00 (I quit that job soon afterwards).

  28. RyszrdG


    I have yet to see any mission critical business change programme deliver successfully using only agile. Sounds like the Co-op was up against the wall and grasping at straws to get its programme delivered and bought Wile Cayote's story. No credit to any party concerned.

  29. Trollslayer

    Is this the IBM

    That sold off the traditional (and profitable) businesses to compete in outsourcing?

    The IBM that made a loss in 22 consecutive quarters?

  30. John Smith 19 Gold badge

    "the insurer appeared to be attempting to include "costs incurred in reliance upon a counter-party"

    Sounds like the bean counters are trying to include potential profits to be generated by the (expected) increase in performance of the system.

    Rather like when a certain gambling den investment bank had it's whole currency dealing operation taken off line when someone had dropped a spanner across two phases of the buildings 3ph supply. They were moved in first (to a small office block) that was being refurbished because the poor darlings didn't like to have their routines disrupted. Sueballs flew through the air that day.

    It'll also be interesting to know if this would have fixed the (alleged) bug in the car insurance quote generation system that let salesman magically move prospects from some crime ridden inner city hell hole to rural Perthshire (or some equally safe place to park your vehicle) and which (allegedly) lead to the phasing out of many (all?) of their direct sales staff. No doubt this alleged bug was unknown to senior sales staff of the time.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like

Biting the hand that feeds IT © 1998–2022