back to article IBM exec told that High Court evidence in Co-Op Insurance case wasn't 'truth, whole truth, and nothing but the truth'

An IBM exec was accused of contradicting himself at the High Court in London as he testified over the failure of a £175m ($225m) Agile platform contract with Co-Operative Insurance. Graham Perrott, Big Blue's general manager of cloud application innovation consulting, was accused of not giving evidence that was "the truth, the …

  1. Anonymous Coward
    Anonymous Coward

    Old Codger Talks About the "old days"

    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!

    1. Kane

      Re: Old Codger Talks About the "old days"

      Copy/Paste much?

    2. Aristotles slow and dimwitted horse

      Re: Old Codger Talks About the "old days"

      RE : "Today, it's my understanding"

      Then your understanding is mostly wrong - not wholly though, as you do make some valid points in respect to how things operate in regulated businesses. I don't disagree that "Agile" itself (when specifically applied as a Project management or development methodology) has its place as a tool or mechanism to assist with the delivery of large scale Projects and Programmes, but in conversations that I have with peers and colleagues in the ERP sector, we all seem to agree that it should still be used within a well founded and stage managed Waterfall approach that is itself primarily scoped and based on approved requirements and business outcome statements. The problem with Agile overall is that is has sadly been, and remains, a method that has been hijacked by inexperienced sales and marketing types as a buzzword to sell a guarantee of rapid delivery, and has been subsequently used as a method to cut corners where no corners should be being cut. In my experience also, Agile "done right" is a rare thing considering how many different interpretations there are of the method.

    3. Ken 16 Silver badge
      Holmes

      Re: Old Codger Talks About the "old days"

      Maybe once upon a time that happened but it sounds like a fairy story to me.

      Software selection was done by writing a requirements document. It would be very detailed on the bit the people writing it knew and kind of vague on the rest. It would add some operational requirements that varied from absent to aspirational to impossible.

      Every vendor then said they could meet all requirements in full. If not in this version of the software then in the next, probably and certainly by configuration rather than modification. The buyer would then ask for demos and customer references and would see a mock up and read about some customers using an unrelated product from the same brand. Coins would be tossed, drinks consumed, trips to vendor conferences taken and the product that was in the magic quadrant would get the nod, even if completely unsuitable to the job at hand.

      The salespeople got their commissions and leveraged them into a promotion or a change of employer and then the delivery team arrived, read the contract and began cursing....

      Have you fallen asleep yet or should I continue?

      1. Muscleguy

        Re: Old Codger Talks About the "old days"

        The one I'm familiar with was bag in the lab in London. We ordered experimental mice by paper chit. The mice were behind an infection barrier and a photocopier was used to transmit the 'dirty' chit to the clean side. The chits where clipped to the wall waiting but folk walking past would brush them off. An online system was needed.

        Us users told IT it needed to be platform independent, us and another big lab were entirely Mac equipped*. Whiich essentially meant a web portal in the intranet.

        This was all transmitted to the head of Animal Services, a Vet. He contracted his nephew to build it in his bedroom. What emerged was a program which ran on Windoze. So we had to buy a Windoze box and it sat in the office and was only used for animal orders.

        *Back then various bits of software and the then automated dna sequencing system ran only on Macs. The boss had a powerbook with a Dock in his office and was happy for us to use Macs. We had a hi-spec digital video camera on a dissecting scope feeding into the video port on an early Power Mac and we captured images using a public domain plug-in for Photoshop. A DIY system which was much cheaper than bespoke systems.

        1. Stubbly Dude

          Re: Old Codger Talks About the "old days"

          Yes but... in the wider world of application development procurement, passing work on to members of the family are considered a big no-no.

      2. ForthIsNotDead
        Thumb Up

        Re: Old Codger Talks About the "old days"

        Ken,

        Yes. This is the scenario that I recognise!

        The problems are pretty much exactly as you have described them:

        1) The client often does not have a complete picture of all of their own requirements. In fairness, in large projects (e.g. ERP) that would be used by stakeholders right across the organisation, trying to assemble the right collection of knowledgeable stakeholders is like trying to herd cats. Imagine a company that runs it's engineering from Aberdeen, London, Stavanger, and Oslo, and its HR and purchasing from Delhi (like the company I used to work for).

        2) The requirements, become 'written in stone' even when contradicting/impossible requirements are pointed out.

        Agile *can* help in the user requirements elicitation, but you still need to be engaged with the correct stakeholders, otherwise what you get back is a load of assumptions and guesses in some areas, and solid information in other areas. It's a nightmare.

    4. Mike 137 Silver badge

      Re: Old Codger Talks About the "old days"

      "... writing a "requirements document" is thought to be not only unfashionable, but useless"

      More likely nobody is competent to do it any more. In the age of "coding" rather than programming, where key decisions on mechanisms and even functionality are made at the keyboard of the IDE, the word "specification" is from a foreign language.

      1. Stubbly Dude

        Re: Old Codger Talks About the "old days"

        Also, the reality of requirements docs is that by the time they've been through myriad review and approval cycles, the business requirements have often lapsed. There are a lot of toys sitting idle on MoD property that fall into that category. New jeep gets delivered to Army; Army asks, where are the USB charging ports? MoD .. er... when we wrote the spec they weren't a thing. Army - thanks but no thanks.

    5. phuzz Silver badge
      Stop

      Re: Old Codger Talks About the "old days"

      "Once upon a time, software selection was done by writing a requirements document."

      I call shenanigans. No one has ever written a complete specifications document without remembering halfway through the process that oh yeah, by the way, it also needs to automatically produce a csv file which includes information which is only ever stored on a handwritten post-it note on the back of a drawer in a locked office, and this needs to be sent by unspecified means to a third-party who never reply to any of your emails asking, nay, pleading, for some information on what format they require. Oh yes and Alex in accounts needs a particular spreadsheet re-creating, but it has to be aligned to lunar months except when there's more than two vowels in the week...

      A full and complete specification document is a fairy-tale, used by BoFHs to send their PFYs to sleep. No such thing has ever existed, and if it did then our universe would be complete and could be shut down.

  2. Anonymous Coward
    Anonymous Coward

    ...and then there's the "modern approach.....

    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?

    1. Anonymous Coward
      Anonymous Coward

      Re: ...and then there's the "modern approach.....

      Obviously not "working" in this context.

      Smells like the central design was fundamentally different to the way the API worked (snapshot or message-based vs. extraction or batch).

      Someone either flubbed the low-level API architecture choices or chose purity over practicality so everything became a hack on top of a hack.

      It might work, but it'll be (fr)agile.

      Problem is, external interfaces are often the last thing to go in, so issues like these pop up later...

    2. eldakka

      Re: ...and then there's the "modern approach.....

      "Working software is the primary measure of progress."
      I note that missing from that item is anything saying that it has to be useful to the customer working software ...

  3. Pascal Monett Silver badge
    Coat

    "I did not have clarity from my own team"

    So, you were parachuted into an existing situation and you could not manage, despite your impressive title, to get a complete picture of the siuation.

    You then proceeded to restrict the picture to what you understood, and then complained when the customer, incredibly, stubbornly stayed with the fantastical idea of having a working product.

    Well, Mr. Perrott, I'm glad I'll never have to do business with you.

    Mine's the one with the complete specifications in the pocket.

    1. Anonymous Coward
      Anonymous Coward

      Re: "I did not have clarity from my own team"

      To be fair to Mr Perrott - it was IBM. Clarity is not their forte.

    2. Commswonk

      Re: "I did not have clarity from my own team"

      So, you were parachuted into an existing situation and you could not manage, despite your impressive title, to get a complete picture of the siuation.

      Point of order: general manager of cloud application innovation consulting is not an impressive title.

      It is actually bollocks masquerading as an impressive title.

      1. Psmo

        Re: "I did not have clarity from my own team"

        I got a BuzzwordBingoCompleteWarning parsing that job title.

  4. The Nazz

    A more efficient process required?

    I live for the day when one of these Judges says : "STOP! I've heard enough."

    Possibly more apt for a previous saga, by around day 3.

  5. cdegroot

    The A-word

    I learned the hard way that doing "Agile Software Development" with a customer that isn't all in will end in tears. I worked on a project where the customer had requirements analysis done by a third party, and as part of our bid we proposed to shred it and start over. Frankly, the requirements docs were nonsensical and had little bearing on what the customer actually wanted. They agreed, and we drafted a contract where we came to demo every two weeks, they would sign for acceptance of the sprint or not, and with signature two weeks of payment were due (the customer could also bail out at any point in time). Some 30 odd sprints later, we declared the project done and a success, even though it was in no way what that original requirements analysis proposed.

    So cue our unbelief when months later (IIRC half a year) we get a legal summons to finalize the project "according to the original requirements analysis" or else. Apparently someone higher up didn't understand what we had been doing and/or tried to get the org's money back (it was a small government shop). Luckily we had a good paper trail and nothing bad happened to us, but the project was declared a failure by their head honchos and got never used.

    Just saying that while I'm always happy to lambast IBM, I'm not entirely sure that they're wrong in saying "the customer didn't cooperate with this agile thing".

    1. John70

      Re: The A-word

      Frankly, the requirements docs were nonsensical and had little bearing on what the customer actually wanted

      What they ask for and what they want are two different things. That's 99.9% of all requirement docs.

      Just easier to bypass the Project Managers and talk directly to the people that will use the actual thing to get an idea of what is actually required.

      1. Anonymous Coward
        Anonymous Coward

        Re: The A-word

        +1 That was actually drummed into us in a software engineering degree twenty years ago- talk to the users, find out what they want, ask them questions like 'what pisses you off about the current process', 'what would make your job easier'... start with the users, then move to the project managers with what the users asked for, and find out how that fits with the managers needs, and generate user stories (use cases) based on that, and then you end up with a spec that does what the users want and what the project managers want... You can do it with agile, as long as you keep going back to the users. If you just go back to the project managers, you end up with junk that needs rewriting every two weeks, and end up with a minimum viable product that isn't any of those things, because the managers know what they want, but it's usually not what anyone needs.

  6. Anonymous Coward
    Anonymous Coward

    In my experience, every agile IBM team comes with a free lawyer to protect their interests. If their developers were as good as their lawyers they'd be a much more successful company.

    1. Anonymous Coward
      Anonymous Coward

      As an ex IBM PM I call bollocks.

      Delivered many projects (most on time and budget), never resorted to lawyer, never needed to. Not even sure I knew who the lawyers were. Some of the projects were well into 7 & 8 figures as well. Mind you not as good a story as the cockups :)

      Ex IBM as I was keen to get the rather generous redundancy payments.

      I also know Graham from when I worked there, no axe to grind either way. I enjoyed working with him when he was head of Public sector.

      I know it's not half as much fun when facts get in the way of a kicking but hey ho...

  7. eldakka

    Oh now I understand Agile

    a £175m ($225m) Agile platform contract
    It refers to what the contractors/developers have to be to avoid the fallout of the failed - but paid for - project. If they get paid and avoid the fallout, it has been a successful Agile project from their perspective.

  8. Anonymous Coward
    Anonymous Coward

    Here's how it usually goes (and I speak from past experience):

    Customer: I want something. Not quite sure what I want, but I want it and I want it cheap.

    Salesman: Sure.

    Customer: Really? Err OK - a bit cheaper than that. I want a good bonus.

    Salesman: Sure. I'll take whatever commission I can get. <thinking of future sales as the contract is as woolly as shit>

    Customer: Where do I sign....

    Techies 12 months into the contract: You fucking said we'd do what by when? You've only just engaged us because you couldn't find anyone else (mainly because you dumb-asses laid them off or they left).

    Most ex-IBM people out there will probably be very aware of the term 'breakage'. It gets used a hell of a lot.

  9. tygrus.au

    Agile can be used for two cases:

    1) inhouse development;

    2) some ongoing development & support of existing installation (customer asks for features and you have a short contract-develop-deliver-accept cycle).

    Otherwise, they don't know what they need, they don't know what they're getting, nobody knows the costs and we all fight when we don't agree with the results.

  10. Anonymous Coward
    Anonymous Coward

    Nowadays, people should get fired for choosing IBM.

  11. Anonymous Coward
    Anonymous Coward

    Agile v Waterfall?....err no.

    This is about desperate companies selling magic beans to wide eyed and unqualified project managers who will tell their managers anything to 'get on'.

  12. GreyWolf

    Been there...

    I've done some contract work for Co-op Insurance (admittedly not recently).

    It was then (and probably still is) a hotbed of politics with zero business or technical realism (like every other insurance company). Also, they hate contractors like poison. IBM ought to have known that signing a software development contract with them would be a nightmare of Co-op Insurance trying to screw them.

    Moral of the tale: don't contract with insurance companies. If you absolutely have to contract with an insurance company, add Asshole Tax to your daily rate.

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