Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL

Introduction > Project Management in the World of Information Technology

Project Management in the World of Information Technology

Here’s another interesting misperception: Hollywood thinks the information technology (IT) world is much, much better at project management than it is.

In preparing this book, I visited with 22 motion picture executives and producers from studios such as Warner Bros., Paramount, Legendary Pictures, Parallel Entertainment, Universal, Intermedia Films, and others. When I told these industry professionals about the theme and purpose of this book, they all gave me funny looks at first. I explained that I wanted to better understand their methods for staying on schedule, staying on budget, and delivering a product that firmly represented initial specs, and that I was after this because my industry—the IT industry—had problems doing that. When they asked how bad the problem was, I low-balled the answer each time: “We’d like to operate consistently at no more than, say, 10 to 15 percent over any of those thresholds.” Frequently, jaws dropped; sometimes only the eyeballs bulged a little. But the response was always the same. Bill Fay, president of Legendary Pictures, summed it up succinctly: “We’d never get by on numbers like that.” In Hollywood, running even 2 or 3 percent over is going to require a lot of explaining on someone’s part. I didn’t mention that more than a few industry studies put overall IT performance regularly at 30, 50, even 100 percent off the mark.

When we IT professionals hear stories about Heaven’s Gate and Waterworld, we probably laugh like everyone else, but inside we probably wince a little too. Those of us who work as project managers or program managers in one capacity or another can easily relate to stories of runaway or misguided projects, either from secondhand knowledge or from firsthand experience. Because project management sits at the heart of project activities, it is the project managers who must deal with the initial fallout that comes when project controls dissipate, and who must then continually work under those conditions to mitigate subsequent effects. My own experience in the industry bears this out. In working with companies like Pitney Bowes, BellSouth Science & Technologies, MCI, AT&T, GTE, CIBER Defense Systems, Macy’s, Kohl’s, American Healthcare, British Petroleum, Johnson Controls, and others, I have seen a distinct pattern: Project performance is highly variable. The ability of a technology organization to develop a product in sync with budget, schedule, and functional expectations is soft at best.

But why is it soft? And how soft is it? To answer these two starting-line questions, let’s begin by putting them in the proper context: the unprecedented success of the technology industry.

An American Success Story

Today’s IT professionals—project managers, executives, technical experts—are part of the most successful social and technological revolution since the Industrial Revolution of the 1770s. In the span of a few decades, a single generation has transformed the world. Information flows, communication channels, integration points, exchange avenues, commonality of form—these are the hallmarks that solidify a working civilization. And because of the recent and rapid advances in technology, these markers have never been more plentiful or more efficient than they are today. What’s involved here is not just inventive or innovative technologies but integrative technologies, the work that corporate American IT shops engage in on a daily basis to shape the needs of business, commerce, and culture.

That’s a big job, and to be honest, the industry hasn’t had a lot of time to learn it. Computers as a business tool have been with us in earnest only since the late 1950s. Back then, only the biggest or the most transaction-intensive–type companies used them. They were complex, mainframe systems, very expensive and very unwieldy. In the 1960s, computers got a little smaller and a littler smarter; less expensive, mini- and midrange systems became available. During this period, a wealth of prepackaged, generic-type software solutions had been developed, so automation spread throughout most of the Fortune 500 landscape, from accounting departments to shipping and receiving to sales and marketing. At the time, these data processing operations typically fell under the management venue of administration and ended (most usually) at the office of the organization’s chief financial officer (CFO). In the mid-1970s, the microcomputer was developed, and another real change began to evolve: Little businesses began to automate, and big businesses began to distribute their computing resources even more widely, setting micros on the desks of more and more workers. By the mid-1980s, the IBM Personal Computer had washed over corporate America, and a new third party software applications industry had been born. Users who once sat quietly at keyboards in front of “green screens” now swished mice around pads, keyed in Lotus macros, printed fancy documents, and asked for more. The “personal” side of computing usurped a great deal of computing’s “business” side. The Data Processing Age now gave over to the Information Age.

This really was a business revolution, a true paradigm shift. It’s conceivable to draw a line down the middle of the year 1982 to mark the divisions BPC and ADP—“before personal computing” and “after data processing.” This year could also be seen as the birth of modern IT project management: The vast success and popularity of the new computing brought with it a vast array of new needs, and those needs quickly turned into new projects—lots of new projects. The Nickelodeon revolution that ushered in the new movie industry was indeed impressive for its day, but even that was nothing like this scope of change.

Managing the Projects

All of this was rapidly changing the shape of corporate America. New IT shops were now being blocked onto organizational charts, new CIOs were being appointed, and new computing capabilities were spreading throughout the organization. The growth of the IT industry over the last 25 years or so has been phenomenal. In 1982, it was sized at about $400 million; today, it is sized at just over $1.3 trillion.[1] Perhaps more significant is the size of the IT customer base. Data processing concerns were once centered on a few select groups within an enterprise. Today IT touches, almost without exception, everybody in the enterprise. (The same thing happened in the movie business. In 1905 there were zero theaters showing movies in the United States. By 1930, there were 97,000. In the same time span, movie attendance went from zero to 300 million annually.[2]) The single thing that came out of this was work, a new kind of work: the development of business automation solutions now and for the first time within an organization. Perhaps the least-anticipated element of this new paradigm was the volume of work. IT shops were born from the get-go as project shops—not out of vision, but out of necessity.

[1] Matt Asay, “IT Spending Set to Fall,” C/Net Magazine, February 11, 2008.

[2] David A. Cook, History of Narrative Film, W. W. Norton & Co., 1996.

As quickly as it became evident that the size and throughput of IT would trend for the foreseeable future as a northbound line, continuing to grow, so did the need for more active project management become apparent. Previously, project management on technology projects had been more of an administrative and internal coordination function: A look at project management in a discipline like construction will show pretty much the same thing. That’s not to say that those job roles are free of complexity or the need for analyses and proactive positioning. But they do operate in environments that can be considered (at least to some extent) predictive. What project management faced in the new paradigm of technology development was that traditional needs for cost, schedule, and quality control were dumped with little preparation into an arena of change in which speed-to-market, feature flux, business missions, competitive positioning, and multiple agendas all required the same high level of attention.

The result was three-faceted:

  1. A lot of work got done; the industry’s success is testament to that.

  2. In doing that work and in meeting that business mission, a method of production (in some places overt, in others covert) evolved.

  3. Embedded within that method was a high degree of chronic waste.

The third point is the kicker. That’s the catalyst for this book, as it’s been the catalyst for many, many books about technology strategy, management, development, and deployment. IT people readily acknowledge the problem of a high level of waste. A common misperception, however, is that the source of this waste is project management—but that’s confusing the point of measurement with the point of generation. The real issue is not that project management needs to get a handle on things so that things will run smoother. The issue—explored in this book—is that the source of the problems is an inherent organizational design that, in the domain of IT, is immature with respect to product development. (After all, at 25 you might be super smart and irrepressibly energetic, but how mature can you really be?) Good project management is a maturing discipline in any organization; it helps make an organization more mature. In IT shops, it can help make the shops more responsive, more effective, and more accountable. The key, then, is not to fix project management. It’s to introduce more project management.

The Cost of Success

This is not a book designed to bash project management, or to paint upper-level technology management as being soft or short-sighted. Nevertheless, although the success of IT across the business landscape—its ubiquitous proliferation and its undeniable effectiveness—is readily visible, it’s important to acknowledge that this success has been accompanied by a kind of production-predictive deficiency. (IT people have a hard time saying up front how their projects are likely to turn out.) This awareness is essential because of the fundamental importance of IT within today’s business enterprise: Because IT has become such an integrated part of business strategies, business tactics, and business operations, its effectiveness can no longer be separated from the business. Today, a reasonable claim might be that as goes IT, so goes the business. That level of integration, considered along with the required investment of capital and resources and competitive positioning, leads to an inescapable conclusion: If IT shops are not operating within practical ranges of efficiencies, the bottom line for the business will suffer.

Here’s a quick survey across 25 years of performance.

  • In 1982, the insurance company Allstate set out to automate all of its office operations using the new technology of micro computing. Management set a 5-year transformation timetable and gave it an $8 million budget. But six years and $15 million later, the offices were a long way from being automated to any appreciable degree. Management reassessed and reestablished a new budget. What had begun as $8 million was now set at $100 million.[3]

    [3] Steve McConnell, Rapid Development: Taming Wild Software Schedules, Microsoft Press, 1996.

  • In 1988, the financial institution Westpac Banking Corp. decided on a strategic initiative to redesign its information system’s data and work flows. This major effort was engineered against a 5-year timetable, an $85 million budget, and an expanded workforce augmented by hundreds of technology specialists. Three years later—mid-1991—project expenditures had topped $150 million, with little to show for it. With no assurance of future success and with nothing to salvage from the effort, Westpac management decided to cut its losses: It canceled the project cold and eliminated 500 development jobs.

  • In 1994, the Standish Group released its infamous Chaos Study. Through surveys of Fortune 500 IT shops, the study concluded that the average IT project ran 189 percent over schedule and 222 percent over budget, with 30 percent of planned functionality missing in delivered products. Nearly 30 percent of all projects begun were canceled before completion.

  • In 1997, KPMG conducted a survey of Canadian IT performance. In working with 1,450 companies, it found that 61 percent of all projects failed in some degree to meet performance expectations. Greater than 74 percent overran their schedules by 30 percent or more. The report concluded that annual unbudgeted project expenditures probably approached the $25 million (Canadian) mark.

  • In 1998, a study by Peat Marwick found that about 35 percent of 600 firms surveyed had at least one runaway software project for that year.[4]

    [4] Robert Charette, “Why Software Fails,” IEEE Magazine, September 2005.

  • In 2001, a Robbins-Gioia survey looked at big project performance in the realm of enterprise resource planning (ERP) implementations. Here is how 232 respondents described their projects: 51 percent said they were unsuccessful. Of those shops, 56 percent had a project management office in place, but only 36 percent of them reported success. A 2001 Conference Board survey that looked at the same area worked with 117 companies and found that 40 percent reported ERP implementations that failed to achieve business goals within the first year. On average, implementation costs were 25 percent over budget. Only 34 percent of shops were “very satisfied” with how the implementations turned out.

  • In 2004, the Standish Group released its new Chaos Study. What it found was an improvement over the 1994 results, but the numbers still showed real performance issues: Only 29 percent of projects could be described as unqualified successes; 53 percent of projects could be described as challenged or seriously compromised; 18 percent failed completely—canceled or not used. The average schedule overrun was now 84 percent (better than 1994, when it was 164 percent). The average cost overrun was 56 percent (better than 1994 at 180 percent). That same year, Computerworld Today reported that one third of all IT spending went to repair botched projects. Supporting the Chaos results, Deborah Weiss of the Meta Group found that 72 percent of all IT projects were either late, came in over budget, lacked functionality, or were never delivered.[5]

    [5] Siohban McBride, “Poor Project Management Leads to Higher Failure Rate,” Computerworld Today, October 15, 2004.

  • In 2005, the giant English food retailer J Sainsbury had to write off an investment of U.S. $526 million in an automated supply-chain management system because the massive project stalled midway through. Integration issues caused Sainsbury merchandise to get stuck in the company’s warehouses. As a result, the inventory was not getting through to many of its stores. Sainsbury, now without a system of any kind, was forced to hire about 3,000 additional clerks to stock its shelves manually.[6]

    [6] Jeff Attwood, “The Long Dismal History of Software Project Failure,” Coding Horror Ezine, May 15, 2006.

Three things to note about these stories: First, the stories recount big failures and big findings. That’s intentional. It’s simply more interesting to read about big failures than about smaller ones. Second, the numbers don’t really add up: The study data and numbers don’t consistently agree. Are projects on average 25 percent over budget, or is it 110 percent? Is schedule slippage endemic at 12 weeks or 54 weeks? There’s probably no way to really know.

Third, and perhaps the real point, all of the data point in the same direction. The numbers may not agree, but they do seem to beg the same question: How far off the mark do most projects fall? (Versus over or under the mark.) Specific, pinpoint conclusions may be risky with these data, but the general conclusion is pretty obvious. Most managers may never have been involved in a $500 million chargeoff, but they probably have seen the smaller kind in action. Perhaps of deeper concern is the degree of acquiescence that may have grown around those trends. The industry has a tendency now to accept slippage as part and parcel of the package. A summary look at the bottom line might encourage reexamination of this tendency. This year, IT expenditures will exceed $1.4 trillion worldwide. Of all projects initiated, 5 to 15 percent are likely to be abandoned; 20 to 40 percent are likely to run well over budget and schedule. On this basis, compromised technology projects have the potential to cost the economy $60 billion to $70 billion.[7]

[7] Robert Charette, “Why Software Fails,” IEEE Magazine, September 2005.

  • Safari Books Online
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint