IT guys (and gals) are the lifeblood of our company and of our clients’ companies — which is why I pay attention to articles that pass along wisdom about the IT profession.
Because IT pervades nearly everything we do in a networked economy, the nature of many IT projects is that they are big.
And big is not necessarily beautiful when it comes to IT projects.
“The key lesson for chief executives is not that big IT projects always go wrong, but that one underestimates their complexity–and their power–at one’s own risk.”
Summary article by Caron Carlson in FierceCIO and original article by John Naughton in The Guardian.
Emphasis in red added by me.
Brian Wood, VP Marketing
——–
Ouch. Do big IT projects always go wrong?
A look back at “The Mythical Man-Month” and the challenge of the big software project
“Why Big IT Projects Always Go Wrong.”
That headline is from an article in The Guardian, in which writer John Naughton admonishes chief executives everywhere to expect minimal success from large-scale software projects.
Drawing on the 1975 book, “The Mythical Man-Month,” as well as more recent research out of Oxford, Naughton warns that only half of an IT project’s anticipated benefits are likely to be achieved, and that the project will probably go 40 percent over budget.
Naughton calls “The Mythical Man-Month”–by Fred Brooks–“one of the seminal texts in the literature of computing.” As he recounts, Brooks headed up the project that created the operating system for IBM’s (NYSE: IBM) 360 line of mainframes. When the project ran far over schedule, IBM assigned more programmers to it, resulting in further delays. This led Brooks to conclude that the more programmers you throw at an IT project late in the game, the longer the project will take.
“Basically because a big software project involves two kinds of work: the actual writing of computer code; and co-coordinating the work of the dozens–or maybe hundreds–of programmers working on different parts of the overall system,” Naughton writes. “Coordination represents an essential but unproductive overhead: and the more programmers you have, the bigger that overhead becomes.”
Indeed, coordination is an essential overhead, and that is true for projects out of IT, HR, marketing, legal, product development and any other place where large-scale, concerted efforts are underway. It may be ironic that companies have made heavy use of IT to slash overhead throughout their operations, and yet overhead is still necessary for successful IT.
The key lesson for chief executives is not that big IT projects always go wrong, but that one underestimates their complexity–and their power–at one’s own risk. As Naughton himself notes: “In the end, [Fred Brooks’ team’s] job was done. The death march ended, OS/360 was delivered and IBM went on to make a lot of money from it.”
http://www.fiercecio.com/story/ouch-do-big-it-projects-always-go-wrong/2013-04-24
———
Why big IT projects always go wrong
Fred Brooks’s 1975 book The Mythical Man-Month is essential reading for any company boss about to embark upon a costly software project
In 1975, a computer scientist named Fred Brooks published one of the seminal texts in the literature of computing. It had the intriguing title of The Mythical Man-Month and it consisted simply of a set of essays on the art of managing large software projects. Between its covers is more distilled wisdom about computing than is contained in any other volume, which is why it has never been out of print. And every government minister, civil servant and chief executive thinking about embarking on a large IT project should be obliged to read it – and answer a multiple-choice quiz afterwards.
How come? Fred Brooks was the guy who led the team that in the 1960s created the operating system for IBM’s 360 range of mainframe computers. This was probably the largest non-military software project ever mounted, and it was of vital strategic importance to IBM, which then completely dominated the computer business. It also turned out to be vastly more complex than anyone – including Fred – anticipated, and it rapidly metamorphosed into a kind of death march.
The project fell further and further behind schedule. But because IBM was a rich company and OS/360 was so important, it was able to throw more and more resources (ie, programmers) at the task. But as it did so, the problems got worse, not better. At which point Fred Brooks had his epiphany: he realised that every time he added a programmer to the team the project fell further behind.
In the end, however, the job was done. The death march ended, OS/360 was delivered and IBM went on to make a lot of money from it. Brooks, for his part, resigned from the company, became professor of computer science at the University of North Carolina in Chapel Hill and then sat down to write the book that made him famous. His aim was to distill into a set of elegant essays everything he had learned from the OS/360 experience. The striking title came from his epiphany – the realisation that man-months are a hopeless metric for assessing the size of a complex software project.
Why? Basically because a big software project involves two kinds of work: the actual writing of computer code; and co-ordinating the work of the dozens – or maybe hundreds – of programmers working on different parts of the overall system. Co-ordination represents an essential but unproductive overhead: and the more programmers you have, the bigger that overhead becomes. Hence Brooks’s law: adding manpower to a late software project makes it later.
Over the years, fragments of Fred Brooks’s wisdom have percolated into the consciousness of ministers, civil servants and chief executives. But only fragments. In Britain we are wearily familiar with the long, dreary catalogue of botched or outlandishly expensive government IT projects. This is not just a public sector problem, however. Research conducted by two Oxford academics and published in the Harvard Business Review suggests that the private sector has almost as much difficulty managing big software projects, and that some such projects have even endangered the survival of the companies that embarked upon them.
A case in point was the venerable clothing manufacturer Levi Strauss. In 2003 it was a global corporation, with operations in more than 110 countries but with an IT system that was an antiquated, “Balkanised” mix of incompatible country-specific systems. So its bosses decided to migrate to a single SAP system and hired a team of fancy consultants (from Deloitte) to lead the effort. “The risks seemed small,” wrote the researchers. “The proposed budget was less than $5m.” But very quickly things fell apart. One major customer, Walmart, required that the system interface with its supply chain management system, creating additional work. During the switchover to the new system, Levi Strauss was unable to fulfill orders and had to close its three US distribution centres for a week. In 2008, the company took a $192.5m charge against earnings to compensate for the botched project — and fired its chief information officer.
The Oxford researchers examined more than 1,400 big IT projects – comparing their budgets and estimated performance benefits with the actual costs and results. The average project cost $167m and the largest a whopping $33bn. The researchers’ sample drew heavily on US-based projects but found little difference between them and European projects. Likewise, they found little difference between private companies and public agencies. One in six had a cost overrun of 200%.
The message is clear: if you run a big company or a government department and are contemplating a big IT product, ask yourself this question: can your company or your ministerial career survive if the project goes over budget by 40% or more, or if only 25-50% of the projected benefits are realised? If the answer is “no” go back to square one. And read Fred Brooks’s lovely book.
http://www.guardian.co.uk/technology/2013/apr/21/fred-brooks-complex-software-projects
