back to article IBM veep partly blamed Sopra Steria for collapse of £155m Co-Op Insurance Agile project

Co-Op Insurance's £155m Agile contract with IBM for a new IT platform collapsed not only because the insurer kept raising spurious defects but also because Sopra Steria bungled a critical data migration, the Big Blue veep overseeing the project told London's High Court. In court papers obtained by The Register, IBM vice …

  1. lglethal Silver badge
    Facepalm

    Nice attitude IBM...

    "Refusing to countenance any defects at all at Go Live is not normal, and I do not recall another client ever having taken that approach before,"

    Yes because a customer refusing to accept a buggy system at launch is so unnatural!

    1. A Non e-mouse Silver badge

      Re: Nice attitude IBM...

      How dare the customer expect us to deliver what we contracted to deliver.

      1. SImon Hobson Bronze badge

        Re: Nice attitude IBM...

        That's just how I read it - it's all the customer's fault for expecting the system to work as described. Saying that you intend to push "defects" back to a later release is just selling vapourware.

    2. Anonymous Coward
      Mushroom

      @lglethal Re: Nice attitude IBM...

      Sorry mate, had to use the mushroom cloud icon.

      No, its not you but IBM.

      This is a clear indication that large projects performed by outsources are doomed from the start.

      Its part of the death knell for IBM and other big consulting groups which promise the world, but then staff these projects with cannon fodder.

      The problem is that one has to consider the cost of lost revenue due to these cock ups.

      They would have been further along if they did a staff augmentation contract using freelances.

      Oh wait, UK IR35 or whatever that dodgy tax law... never mind.

      1. Gonzo wizard
        Flame

        Re: @lglethal Nice attitude IBM...

        IBM has truly awful day rates and the worst contracts I’ve ever seen for freelancers. I’d rather “rest” than contract for them.

    3. jason_derp

      Re: Nice attitude IBM...

      "Yes because a customer refusing to accept a buggy system at launch is so unnatural!"

      Well, I think it might be a troublesome point because the sort of company that would be requiring such a system right off the hop would need to be something critical like an insurance compan......oh....

      1. Giovani Tapini
        Facepalm

        Re: Nice attitude IBM...

        I would lay odds that nowhere in the contract did it specify the system had to actually work or what that meant, only that it is delivered...

  2. adam payne

    Further, the IBM VP also said that the Co-Op had introduced a new requirement at a late stage for data within the new platform to be encrypted in transit, something he described as "a significant change in approach that seemed excessive and would have required significant changes to be made."

    Why would it not be encrypted in transit?!? it's insurance data that has personal details in it.

    Not sure why this would be seen as excessive, it's data security after all.

    1. Joel Mansford

      Hmmm....encryption

      Well, if the 'transit' is entirely inter-server within a Co-op data centre then ok, encryption probably isn't entirely necessary. However if that data is in any way getting to the client unencrypted then I'd say that's unacceptable.

      I know near-nothing about this case but I could well imagine the contract being silent to encryption in-transit then some techie at Co-op realising that it was unencrypted and shouting a "WTF?!" to which IBM consider this a change in requirements.

      I wouldn't be at all surprised that the scenario in question any of us would have just assumed as a Software Engineer you'd encrypt it.

      1. Anonymous Coward
        Anonymous Coward

        Re: Hmmm....encryption

        "would have required significant changes to be made."

        All I can think is they were relying on the hypervisor to route traffic internally rather than routing it out and back via external switches but thats noddy stuff and IBM has/had some more than decent security architects:

      2. maffski

        Re: Hmmm....encryption

        Not even inter-server. It may be a requirement for inter-process encryption on the same hardware - to protect against man in the middle intercepts for example.

        1. martinusher Silver badge

          Re: Hmmm....encryption

          What's the big deal about encryption? Its not an application level property, its just a substitute layer in interprocess communication ("no encryption" just being a particular form of encryption).

          Methinks they've got their software stucture all screwed up......

          1. maffski

            Re: Hmmm....encryption

            '... Its not an application level property...'

            So how do you know you can trust it?

    2. TDog

      "something he described as "a significant change in approach that seemed excessive and would have required significant changes to be made."

      So IBM's official position is that data does not need to be encrypted in transit. So does that mean they don't lock the filing cabinets in the moving van then?

      1. Pascal Monett Silver badge

        I think more likely that the US version does not have encryption, so putting it in would indeed be a significant change - especially if requested at the last minute.

        Security is not a last-minute bolt-on. Shame on Co-Op for treating it that way.

        1. Anonymous Coward
          Anonymous Coward

          Without knowing more details I wouldn't necessarily assume it's Co-op's fault. It's entirely possible, that they were assured that everything was encrypted in transit. Later, they find out that that encryption is not up to industry standards. Turning around at that point and demanding that it is properly encrypted and having IBM state thats a major change, is all within the IBM playbook.

          So without full info, it's very hard to lay blame either way. IBM do a lot of dodgy stuff in my experience. But then customers are also just as bad at making up requirements on the go. Who knows what happened in this case...

    3. Anonymous Coward
      Boffin

      What no TLS?

      Sorry but encryption is transit for PII/PHI is definitely status quo.

      If IBM doesn't know this then it is further proof that they don't know what they are doing.

      As to a complexity... no, its pretty straight forward to solve.

      1. Claptrap314 Silver badge

        Re: What no TLS?

        This. Encryption in transit is almost trivial to enable if your code is even a little bit sane. IBM's claim that this was "a significant change in approach that seemed excessive and would have required significant changes to be made." Is ********.

        There might, MIGHT be some issues regarding timing. But even that would be pushing it.

      2. PeterM42
        Thumb Down

        Re: What no TLS?

        "As to a complexity... no, its pretty straight forward to solve."

        Yes, but IBM make something simple VERY expensive for the poor mugs who outsourced to IBM.

    4. tip pc Silver badge

      “ Not sure why this would be seen as excessive, it's data security after all.”

      If it was a requirement baked in from the start, as it should have been, then it wouldn’t have been an issue, show horning in encryption with certificates then validating everything at the last minute would have been non trivial and an absolute pain.

      To do ids/ips and payload validation the data in transit must be decrypted inspected and reencrypted. It’s do able but not as trivial as some would make out.

      1. Giovani Tapini
        Mushroom

        Consistent with my observations of some Agile led projects

        Suddenly what used to be basics that you didn't need to specify in huge detail e.g. logging, access controls, upgrade & maintenance considerations, etc, now are ignored unless the customer specified ABSOLUTELY BL**DY EVERYTHING or it wont be done automatically by body shopped drones cut-n-pasting code from GitHub. Then probably re-specifying the same crapola at each level of the storyboard thus also ensuring you get supplied 20 different ways of delivering what should have been system wide features.

        Just do some up-front design work, call it principles so it doesn't feel too old-school to the people involved, and ensure all delivery areas get the same book.

        From what I have seen many Agile projects (at leas the ones at greenfield system level scale rather than feature development) have exhibited behaviours not seen since teasing trainee programmers with exercises that are actually impossible if they had thought about it in advance of train-of-thought coding

  3. Scott 53

    "Data, data everywhere, not any byte to drink"

    That's nor any byte to drink.

    1. Giovani Tapini

      Re: "Data, data everywhere, not any byte to drink"

      Do you need some Nybbles with that drink sir?

  4. Aristotles slow and dimwitted horse

    Crikey, this raises more questions than answers...

    So...

    "IBM's claims that it just needed a little light tweaking. IBM hotly denies that it was unsuitable."

    Having worked on systems for both US and UK insurers, I very much doubt it was suitable. There are quite significant differences in the ways that insurance books are managed between the two.

    "The system is in fact performing as expected"

    In what way? Functionally or non-functionally? And according to who? IBMs assumptions? Or as per the end clients use cases, FRs and NFRs?

    And finally re the data migration, surely IBM would have known about this 3rd party risk or dependency at the beginning of the contract so I'm struggling to understand why they didn't manage it as such : using this as a reason to walk away seems a little weird.

    1. Tomislav

      Re: Crikey, this raises more questions than answers...

      "The system is in fact performing as expected"

      Nobody at IBM really expected it to work so it is in fact performing as expected. :)

  5. Anonymous Coward
    Anonymous Coward

    Lets just say IBM's idea of what constitutes an "SME" is vastly different to what the rest of the world thinks. To find a true SME in IBM is like finding unicorn shit (and getting harder).

  6. Doctor Syntax Silver badge

    Was there no product designed for the UK market that could be adopted with less tweaking. Replace "US market" with "Spanish market" and it starts to sound very familiar.

  7. Brewster's Angle Grinder Silver badge
    Mushroom

    Now I want to see a graph of rejected defects and a graph of accepted defects. If IBM are blameless then the latter should look like a typical S shaped curve. But if that defect list 'grew at a "linear" rate over time' then IBM are just blowing smoke.

    ICON FOR BLOWING SMOKE ---->

    1. lsces

      Poor user documentation?

      ONLY a quarter of bug reports being 'bogus' sounds pretty good to me. On a new system a lot of the time is spent explaining just how it works and if the bug report system is the only way of managing operational questions then the 'triage' is to make sure that the user documentation is brough in line with just how it does work?

      1. flibble

        Re: Poor user documentation?

        It probably depends how good the bug reports are.

        If it was a good bug report, it makes very clear what the alleged defect is, then someone aware of the specification (assuming such a thing existed in this 'agile' project) could close the defect off fairly easily.

        About 80% of the defects I see from customers are "Printing doesn't work in release 4. We checked release 3 and it doesn't work there either." - even though I know release 3 went through a full test where **the same tester** verified printing was working. Defects like that tend to take a ridiculous amount of back and forth to eventually discover that the defect is "printing doesn't work when the printer driver isn't installed" or something equally ridiculous. And then release 5 goes into test and a "Printing doesn't work in release 5" defect gets raised... welcome to my personal hell.

        1. AdamWill

          Re: Poor user documentation?

          Well, sure, but as you say, this is all perfectly normal and par for the course and the expected experience of anyone who deals with bug reports from anywhere. It seems a bit rich that IBM are effectively claiming it's an entirely unexpected thing and a significant factor in the delayed deployment of the software...

  8. SVV

    Agile project

    This sounds nothing like how an agile project is supposed to be done. Whetever methodolgy you are or not using, it has been known for years now that you should get a basic functioning user interface out to users as soon as possible, then start user acceptance testing straight away : this way you catch the "oh no it shouldn't be like that it should work like this" as soon as possible. You should then keep UAT going as the functionality is igradually filled in so that the users don't feel that nasty surprises are being sprung on them and the developers can make sure the system does what is really required in a a way that is intuitive to the users doing their actual jobs with it.

    From the story, this sounds like it was really a waterfall prioject dressed up in fancy agile clothing, and the users only got to test it near the end of the project whereupon they realised far too late that the system didn't meet their needs.

    1. BigSLitleP

      Re: Agile project

      Looks like you got a downvote from someone that doesn't understand Agile methodology

      1. Gonzo wizard

        Re: Agile project

        Or am IBM staffer who’s managed to find a way around the corporate firewall block on reading the mathematical Register.

      2. Anonymous Coward
        Anonymous Coward

        Re: Agile project

        more like someone whos worked at IBM, and understands that all it means is push it out as fast as possible, get customer signoff, charge them and walk away, leaving the customer to pick up the mess.

        Standard IBM operating procedure.

    2. Anonymous Coward
      Anonymous Coward

      Re: Agile project

      It is ok in principle, but don't try to use it for any regulated industry like banking or insurance, or even retail, where you can't have anything in production unless it has passed not only UAT but most importantly Certification (like PCI DSS if you are handling payment cards)...

      Working for a luxury retailer, it was fun to see the US publisher representatives discover that they would have to use specific type of printer for Italy for example (we don't have a driver for this one!!!).

      They were not even aware of the possibility of having a French UI mandatory for Quebec (Canada has another language than English??? There are 3 official languages in Belgium and Switzerland???), when everything was dependent on the country code...

      1. Cederic Silver badge

        Re: Agile project

        Agile is perfectly fine in regulated industries. I've used agile methods and overseen agile delivery and been the customer for agile projects in a credit card company, in a bank, in an insurance company, in other financial services organisations.

        All of them entirely compliant with PCI DSS, entirely compliant with the FCA or FSA, entirely compliant with various DPA and - most usefully - almost all of them successfully delivered.

        The one big failure coincidentally had IBM and Steria involved.

    3. Anonymous Coward
      Anonymous Coward

      Re: Agile project

      > From the story, this sounds like it was really a waterfall prioject dressed up in fancy agile clothing

      No, it just sounds like a balls up all round. If it was a properly run waterfall project then, long before any coding started, there would have been a gap analysis on the US product's functionality versus the UK market's / the Coop's requirements. This would have quickly revealed the size of the problem.

  9. Androgynous Cow Herd

    IBM? Agile?

    Expecting IBM to be "Agile" is like expecting my Basset Hound to sing an Aria.

    I would imagine it was a Waterfall with Agile names like "Scrum master" for the various middle management pogues.

  10. Anonymous Coward
    Anonymous Coward

    how dare they!

    The hide of the customer, firing defect reports back at the supplier.

    Hey IBM, here's an idea, maybe you should make defect free software!

    Forget the Agile crap, which is renowned for producing more defects than product, and leaving the end customer to sort out the mess after you've been paid and buggered off, leaving them to sort out the problems, at their cost!

  11. Henry Wertz 1 Gold badge

    Probably none?

    The insurance co would not decide which bugs reported could be deferred until release 2? Yeah... First off, they probably don't want to use a system that's riddled with bugs and then rely on a release 2 fixing them. Secondly, it does seem like the developers ought to be able to triage bugs on their own pretty well, every system I've seen that's under development it's pretty clear that some bugs are real show stoppers, some are fairly serious, some are really pretty minor and some are "wish list" items. It does sound like this project went a bit off the rails; I'm inclined to think the developers bit off more than they can chew, but it is entirely possible the insurance co. has real messy IT infrastructure and set an unrealistic timeline for this to all get done.

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