I haven’t done this for a while but here is another contribution to my blog series asking experts why they thing large IT projects fail.
The entry below is the 28th so far. It comes from Bill Curtis is chief scientist at software quality firm CAST. He is best known for leading development of the Capability Maturity Model (CMM) which has become the global standard for evaluating the capability of software development organisations. Prior to joining CAST Bill worked at SEI, MCC, GE Space Division and the University of Washington.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Here are the posts already published: Part 1 Brian Randell, part 2 Anthony Finkelstein, part 3 Yann L’Huillier, part 4 James Martin, part 5 Philip Virgo , part 6 Tony Collins, part 7 ILan Oshri, part 8, Robert Morgan part 9 Sam Kingston, part 10 Peter Brudenal, part 11 Mark Lewis, part 12 John Worthy, part 13 Stuart Drew, part 14 Milan Gupta, part 15 from a reader known as Matt, part 16 Fotis Karonis, part 17 Fergus Cloughley, part 18 Steve Haines, part 19 David Holling, part 20 Bryan Cruickshank, part 21 Rob Lee, part 22 Tony Prestedge, part 23 BG Srinivas, part 24 Craig Beddis, part 25 Stuart Mitchenall, part 26 Colin Beveridge and part 27 from Trevor Christie-Taylor.
Here is part 28, Bill Curtis’s contribution.
“Most of the good answers on failure have already been taken by the folks interviewed before me. Let me add an interesting subscript. Some years ago I was involved in one of the largest successful failures of all time. The product worked as advertised and had begun winning competitions. However the company was unable to make a profit and ultimately was forced to sell the business to a competitor. How can success lead to failure?
The successful debacle started with grandiose requirements, a vision of the future that went far beyond anything customers were requiring in their bids. The grandiose hardware architecture required in order to support these requirements was not grandiose enough to support the grandiose software needed to implement the grandiose functionality.
Bear in mind this was quite some time ago when memories and processors actually had real limits. The folks involved were certainly smart enough to manage this problem once it was identified. The only problem was that it wasn’t identified until too late because no one was measuring the code. When we hit the integration test you could watch code flow over the edges of the chip and on to the floor. This should have been detected far in advance, but no one was measuring and analysing code size or quality.
The vast team immediately launched into an emergency re-architecting effort to re-cram code on to the available set of chips by radically slicing and redistributing functionality that was part of the grandiose vision, but not the customer’s requirements.
The effort was successful and the system won the first customer’s competition. However, the architecture was now such a patchwork that adapting it to the requirements of each new customer was an expensive nightmare. So expensive that it surpassed any profit we could make on the sale. We kept winning customers and losing money, leading to the eventual sell-off of the whole mess. The lesson was that there are all sorts of risks in system development – grandiose requirements, ridiculous schedules, inexperienced staff, etc. The only way to detect that a project is headed for failure early enough to change course or cancel it before too much money is lost is to continually measure the project and the product. Failure to measure isn’t necessarily the primary reason that projects fail, but it is a reason that the failure costs so much more than it should have.”