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 …
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.
"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.
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.
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.
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.
"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.
"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.
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.
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.
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.
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.
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.
"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.....
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.
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??
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.
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.
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.
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?
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"?
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.
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.
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.
Warning:
Unreachable code.
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.
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.
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.
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.
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.
... 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.
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).
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
