The Art of Project Management

he New Zealand government recently did a study of why large information technology projects fall down. The report reminds us that ours is not the only government struggling with how to deploy technology. Still, despite the concerted efforts of great minds, public and private, we continue to read about large-scale projects that are years late, dramatically over budget and even scuttled after billions of dollars have been spent.

The problem of managing project budgets is so large-by some estimates, as much as a third of our information technology investments is wasted-it has drawn the attention of many experts. While no single article or book has all the answers, there seems to be consensus on several points.

Projects vs. Production

By definition, a project is a one-time effort to build or modify a system, physical or procedural, that often redefines what an organization does every day. Thus, it diverts or competes for resources and management attention normally devoted to producing whatever the organization is set up to do, whether it's building widgets or processing claims.

The skills and tools used to manage operations and production are different from those needed to manage a project. One does not use PERT or GANTT charts to manage a production process, and the concepts of unit cost or production quality control techniques have less application to managing a project. For many executives and organizations, a large project is a once- or twice-in-a-lifetime undertaking that is unfamiliar. Sometimes operations management and project management look similar, but they are fundamentally different. Building 100 identical tract houses is a production process, but building a custom house is a project.

Because a project involves building or modifying a system, something the organization has not done before, it means taking risks. In theory, one can break most projects into tasks that have been done before independently, and then estimate the total cost or time involved. But even if each of the pieces at the smallest level is knowable, what happens when you put them together is not. Managing risk means:

• Understanding the probability of an unexpected result.
• Putting in place controls that will alert management to problems early.
• Having a plan and the will or courage to deal with that contingency.

Rep. Steve Horn, R-Calif., chairman of the Government Reform and Oversight subcommittee on government management, information and technology, has asked why government's $4 billion or $5 billion failures could not have been $4 million or even $400 million. The answers are complex, but key among them are executives who aren't paying attention or are afraid to admit there is a problem. The challenge, if the project is going to fail, is to fail early.

Technology Isn't the Culprit

Few agency problems entail untested technical concepts. The challenge is more often the organizational or physical setting in which the technology is deployed. Many experts agree that most large system failures are due to management's inability to plan and direct resources, including people, toward some organizational objective.

A pitfall of large information technology projects is looking at problems as technology-related rather than management-related, prompting executives to stay away and then rely too heavily on the judgment of technicians. Even when problems are technical, Kapur says, many technical staff believe so strongly in the power of the technology that, like river boat gamblers down to their last chips, they are convinced that the roll of the dice will bring salvation.

However, just because a problem isn't technical doesn't mean it isn't complicated. One size rarely fits all.

Now that federal agencies have gotten past merely automating known processes within existing organizational boundaries for the sake of speed and efficiency, the challenges get harder. Large projects often entail new inter-organizational relationships and profoundly affect the customers.

The concept of socks is universal, but one size or style won't cover the range of feet or weather conditions. The concepts of project management are similarly universal, but the tools and techniques vary depending on size and complexity. Robert Alloway, a member of Horn's staff, says an organization that slavishly follows a standard project management manual is likely to get into big trouble. At a minimum, projects with organizational complexity require substantially more executive direction. Many of the decisions are political, not technical.

One way to size up a project is to rank its size and technical complexity on one axis and the number and range of interested or affected parties on the other. Kapur and Alloway have developed tools to help managers measure complexity. If a project is high on both the substantive and organizational complexity scales, Alloway suggests breaking it up into separate pieces.

Kapur surveyed participants at the Government Technology Leadership Institute, produced late last year by the Brookings Institution, the George Washington University, the National Performance Review, the Senior Executives Association and Government Executive, to measure the level of project management skill and executive support in their organizations. The results were startling. Only 17 percent of those surveyed said IT projects in their organizations had support from and consistent involvement by an executive outside the IT organization; 10 percent said they had none at all. Just 16 percent said their organizations had well-designed project manager skills development programs. Kapur says those percentages are well below what he sees from similar audiences in the private sector.

Kapur says he believes it is tougher to let a project get out of control in the private sector. One reason is that performance measurement information is more readily available and part of the culture. If an investment cannot be shown contributing to sales or production or other set measures, the executive in charge is willing to walk away from the project. The 1993 Government Performance and Results Act holds the hope of creating a measurement culture that will give federal managers the metrics they need to make such hard decisions. Another reason private sector projects are kept in check is keen competition for scarce investment money, Kapur says. If a project is not panning out, other managers are eager to claim the resources for higher return projects.

Less stigma is attached to trying and failing in the private sector, unless one does so repeatedly. I wonder whether the executive who pulled the plug on "New Coke" would have done so had it been a public sector project and he faced an ugly congressional hearing.

Wake-Up Call for Executives

The strong message from Kapur is that large projects most often fail because the responsible senior executive relegates the hard day-to-day work of managing to others. Executives often think that once they have approved a concept and a budget, the project can become someone else's problem. When they see the project officer in the hall, they may ask, "How's it going?" But they really don't want to know.

Managing an IT project is tough, especially in the early stages, which are fraught with bad news or at least uncertainty. That is precisely when senior management attention and support are most needed.

If you see yourself in this picture, you need to get out. There is lots of help out there, but only if you are prepared to invest the time and intellectual energy.