Reinventing Project Management
The Adaptive Diamond Approach

Readings from the Book

Read the complete Chapter 1 (pdf p), or excerpts from the book:

  1. Project management is everyone’s business
  2. Even Well-Managed Projects Fail
  3. The Evolution of a Discipline
  4. Hurricane Katrina - an example of a Blitz project



The Book contents:


Acknowledgments ix


PART ONE: A New Model for Managing Projects


1. Why Your Business Success Depends on Projects

2. What Makes a Project Successful

3. The Diamond Framework


PART TWO: The Four Bases of Successful Projects


4. Novelty

5. Technology

6. Complexity

7. Pace


PART THREE: Putting The Diamond Approach to Work


8. Managing Projects for Business Innovation

9. Managing Projects Within the Existing Organization

10. How Markets and Industries Affect Project Management

11. Reinventing Project Management for Your Organization



1. Our Research Steps

2. Project Success Assessment Questionnaire

3A. Building the Contingency Approach to Project Management

3B. Project Classification Questionnaire

3C. Principles and Design of Classification Systems

4. Project Novelty and Traditional Project Management

5A. Empirical Results for Project Technology

5B. Project Technology and Traditional Project Management

6A. Empirical Results for Project Complexity

6B. Project Complexity and Traditional Project Management

7. Project Pace and Traditional Project Management




About the Authors

  •  A 
  •  B 
  •  C 
  •  D 

Project management is everyone’s business

Generally speaking, you can divide your organization’s activity into two categories: operations and projects. Operations involve repetitive, ongoing activities, such as manufacturing, service, and production, whereas projects involve unique, one-time initiatives, such as launching new products, new organizations, or new ventures, improving existing products, and investing in the company’s infrastructure. Projects drive business innovation and change; in fact, there is no way you can innovate, create change, or gain competitive advantage without successful projects. Furthermore, if you think about it, every operational process began as a project that put things in motion.

With high demand for growth and innovation, the share of operations in most organizations is declining and the share of projects is on the rise. This trend began in the early 1900s, and it is accelerating in almost every organization and industry: not only do product life cycles become shorter, but also customers today demand greater variety and more choices, forcing companies to offer more products in almost every market. For example, in 2003 GM offered eighty-nine models, selling an average of fifty thousand cars per model; in the 1950s, in contrast, a single model would sell in the millions.

In addition, market globalization is forcing businesses to respond to local demands and to low-cost competition around the world. Moreover, the information technology (IT) and Internet revolution is not slowing down. Even in stable industries such as banking and insurance, organizations must continuously invest in new IT infrastructure to keep up with growing demand and competition. Each of these trends intensifies the project activity in almost every organization and industry.

Ironically, during most of the twentieth century many organizations focused on improving their operations but not their projects. This trend began with the scientific management principles of Frederick Taylor, which greatly influenced the evolution of efficient mass production systems. The efforts to improve operational efficiency continued for decades with more recent concepts such as just in time, lean manufacturing, reengineering, supply-chain management, and six sigma.

Although operational efficiency remains important, there is a limit to how much you can improve. With time, at least in theory, all companies can reach a similar level of efficiency. For example, think about quality. In the 1980s, high quality was considered an important source of competitive advantage. Not any more. Customers now take quality for granted, rather than view it as a unique advantage. High quality has become a must, and essentially a license to do business. A similar case can be made for organizational efficiency.

No business enterprise can survive if it is focused only on improving its operations. The next untapped candidate for significant improvements in a company’s pursuit of competitiveness is the project activity of the organization.
Projects are the engines that drive innovations from idea to commercialization. But projects are also the drivers that make organizations better, stronger, and more efficient. And because most organizations accelerate toward a project-based world, shouldn’t you ask yourself how your organization is doing with its projects? Are you doing a better job than your competitors?

This situation presents a tremendous opportunity. It is time to unleash the underutilized potential that exists in projects. The premise of this book is that projects matter, more than ever. The good news is that because all organizations—commercial companies, government agencies, educational institutions, and charitable funds—have projects, managers at all levels can play a critical role in turning project management into an organizational competitive asset. The time has come to recognize that project management is everyone’s business.

Even Well-Managed Projects Fail

As the data proves, most projects fail to meet their goals. They do not meet time and budget goals, do not meet their business objectives, or both. Consider the following:

* The Standish Group found that in 2000 only about 28 percent of IT projects were successful. The rest were either total failures or failed to meet business requirements.
* The Standish Group also estimated that of the $382 billion spent in 2003 on IT projects in the United States, $82 billion was a total waste. One-third of the projects that either failed or did not meet business requirements had overruns of 200 to 300 percent.
* Robert Cooper’s studies on new-product development showed that about 46 percent of all resources were allocated to projects that were canceled or failed to yield an adequate financial return. Only one of four products that entered development became a commercial success.
* A study conducted in 1998 by the Bull Computer Corporation in the United Kingdom found that 75 percent of IT projects missed their deadlines, 55 percent exceeded their budgets, and 37 percent did not meet project requirements.

For fifteen years we have collected data on more than six hundred projects in the business, government, and nonprofit sectors in various countries and have documented hundreds of project case studies. Some 85 percent of the projects we studied failed to meet time and budget goals, with an average overrun of 70 percent in time and 60 percent in budget.

Why Even Well-Managed Projects Fail

You may think that projects fail because of poor planning, lack of communication, or inadequate resources; but as the evidence suggests, failure is often found even in well-managed projects that are run by experienced managers and supported by highly regarded organizations. Consider the following:

Denver International Airport was initiated in 1989 to take over Denver’s Stapleton Airport, which had outgrown its maximum capacity. But the project suffered an extensive delay of sixteen months and an enormous cost overrun of $1.5 billion. As it turned out, one component—the automatic bag-handling system—had a higher risk than the project’s other elements, but it was treated as a standard, well-proven subsystem, just like any other part of the project.

The Segway personal transportation system was expected to change the way people traveled, particularly in big cities. With high sales expectations, its builders prepared a substantial infrastructure for mass production. Although the product was well designed and fun to ride, it did not fulfill its business forecasts; sales were short of prediction and, in retrospect, the extensive investment in production capabilities seemed unjustified.

NASA’s Mars Climate Orbiter (MCO) was supposed to circle the planet Mars and collect weather data as well as act as a relay communication station to a second vehicle, Mars Polar Lander. MCO was launched by NASA as planned on December 11, 1998, but after nine and a half months in space, its signal was lost just as it began its final insertion maneuver. The failure was later described as a technical error due to a failure to use metric units in the coding of one of the ground software files.

These projects took place in different industries, were aimed at different markets, and used different technologies. Yet they had one thing is common. They all had highly talented and dedicated managers, the best professional teams, the latest project management tools, and total support from top management. It seemed that each of these projects had every ingredient needed to succeed, but all of them failed to meet their expectations; when managers finally understood what went wrong and why, it was too late to fix the problem. The common theme to all of these failures was that executives as well as project teams failed to appreciate up front the extent of uncertainty and complexity involved (or failed to communicate this extent to each other) and failed to adapt their management style to the situation. The full story of these projects will be told later in the book.

These projects are not unique. We can find similar situations in every organization, where well-managed projects fail to deliver on their promises and end up in disappointment.

Why We Need a New Framework and a New Approach

Many executives believe that if they come up with the right strategy or business plan, their project teams will “get it done” and execute the strategy as directed. As we have observed, top managers frequently look at project budgets as a cost, not an investment, and see project activities as part of operations. They rarely appoint a “chief project officer” or vice president of projects, and their project teams are left on their own with little guidance or help from the top.

Projects teams often try to follow a well-established set of guidelines that has become standard in the discipline of project management. Although the conventional project management body of knowledge forms a good foundation for basic training and initial learning, it may not suffice for addressing the complex problems of today’s projects. . Simply asked, if you apply the standard tools and follow the rules and processes as prescribed, will your project be successful? As we have found, the answer is, Not always.” Often, even if you do everything by the book of conventional project management, you may still fail.

Most project problems are not technical but managerial. When technical errors cause projects to fail, it is usually management that failed to put the right system in place so that these errors would be detected in time. Such problems stem from the framework and the mind-set that drive the traditional approach to project management, rather than from a lack of process or practice. The critical questions are these: Can we help project teams make the right assessment before presenting their project proposals to top management? Can we show executives how to ask the right questions and foresee danger before they make a commitment to a project and before it is too late? And can we guide project teams in adapting their project management style to the circumstances, environment, and task? It seems that managers at all levels need a new framework and a new language to communicate with each other about projects. Our goal in this book is to offer such a framework, which represents a new and more realistic approach to project management.

The Evolution of a Discipline

When you look at the Pyramids, the Great Wall of China, the Greek Pantheon, and even Stonehenge, you realize that projects have been an important part of every civilization. Yet not until modern times did companies begin organizing work around projects; and when tools, techniques, and methods became standard across industries, a new discipline—project management—emerged.

As a formal discipline, project management as we know it was born in the middle of the twentieth century. The Manhattan Project, which built the first atomic bomb during World War II, exhibited the principles of organization, planning, and direction that influenced the development of standard practices for managing projects. During the cold war, large and complex projects demanded new approaches. In programs such as the U.S. Air Force’s intercontinental ballistic missile (ICBM) and the Navy’s Polaris missiles, managers developed a new control procedure called program evaluation and review technique (PERT). This approach evolved simultaneously with the critical path method (CPM), which was invented by DuPont for construction projects. These methods led to current network scheduling charts, which became the standard planning and control tools. Such charts describe the project plan as a logical network of sequential activities, with allocated times for each activity. ---

The Traditional Way to Manage Projects

Typically, you begin project planning by creating a scope statement, which defines the work that needs to be done. The scope is then divided into elements of work, called work packages, which are built hierarchically in a tree structure called a work breakdown structure (WBS). From there, you build an organizational breakdown structure (OBS) and a network scheduling chart; then you allocate the required resources, develop the budget, and lay down many other parts of the project plan.

Every project plan must include, at a minimum, a scope statement, a WBS, an OBS, a schedule, and a budget. Some also include a risk management plan to assess what can go wrong and plan what to do about it. The ultimate objective of a conventional project plan is to complete the project on time, within budget, and according to requirements. ---

Why Conventional Project Management Often Fails

The standard, formal approach to project management is based on a predictable, fixed, relatively simple, and certain model. It is decoupled from changes in the environment or in business needs; once you’ve created the project plan, it sets out the objectives for the project, and the project manager must execute the plan using a “management-as-planned” philosophy. After the project is launched, progress and performance are assessed against the plan, and changes to the plan should be rare and, if possible, avoided. Consider the following two major drivers of project management:

o The triple constraint. Project managers see their job as successful when they are able to complete the project on time, within budget, and within performance goals (or requirements). This has famously been named the triple constraint (or “iron triangle”) of project management. Deviations from the triple constraint are seen as negative signals that must be prevented or corrected.

o One size fits all. Many executives and managers assume that all projects are the same, thus suffering from the “project is a project is a project” syndrome. They expect to succeed by simply following a standard set of activities as outlined in conventional project management books, none of which currently includes guidelines for distinguishing among projects and for selecting the right approach for a project.

In their struggle to keep projects on track, executives and teams get frustrated when they try to fulfill unrealistic expectations of stability. Worse, in their effort to focus the project on the triple constraint, project teams often lose sight of the business rationale behind their projects: that they must satisfy a customer and achieve business results, and not just meet project requirements. And when they try to follow a standard set of rules for all projects, they often employ the wrong approach to their specific project.

The classical drivers of project management are no longer sufficient in the current business environment. The traditional model fits only a small group of today’s projects. Most modern projects are uncertain, complex, and changing, and they are strongly affected by the dynamics of the environment. Virtually every project we studied underwent changes that were unpredictable up front, and none of the projects was completed exactly as planned. Furthermore, as we found, projects differ in many ways, and one size does not fit all. To succeed, you must adjust your project to the environment, the task, and the goal, rather than stick to one set of rules.

In most projects you can no longer assume that your initial plan will hold until the project ends. Changes will take place and plans will have to be adjusted to the change. Sometimes you cannot even build a complete plan for your entire effort. Instead, you must establish a small pilot program to create small-scale prototypes, and include interim milestones to resolve important unknowns before you can commit to the full project, or you must separate an unpredictable component from the rest of your project and treat it completely differently than the bigger, more reliable task. The extent of unpredictability, contingency, and change will be different for different projects. None of these realities is included in the classic project management textbooks or guides.

Hurricane Katrina

Katrina hit the coasts of Louisiana and Mississippi on August 29, 2005, causing the greatest devastation from a natural disaster in the history of the United States. The storm was a reminder that even the most developed society in the world is as vulnerable as other societies, and in some ways more vulnerable. But it was also a wake-up call for government as the sector responsible for the safety and well-being of its citizens. Katrina’s magnitude and scope were beyond the comprehension and perhaps the capacity of a city or state to handle. It demonstrated that when catastrophe strikes, it is the responsibility of the federal government to act swiftly to save lives and property and to get life back to normal as quickly as possible.

Yet the Federal Emergency Management Agency (FEMA) and other U.S. government agencies were slow to respond and act. Critical time passed before any government help was evident in New Orleans, while people, desperate for help, clung to rooftops or scavenged food and shelter. For three days looters and criminals took advantage of the chaos and added terror and fear to the devastated city. It took the government four days to begin acting. At that point, finally, a convoy of military trucks drove through the floodwaters, and the first supplies of water and food reached victims who had waited for days. Thousands of armed National Guard troops also streamed into the city to help restore order.

Anyone looking at Katrina’s relief efforts as a project would conclude that the failure was caused by the government’s inability (or unreadiness) to respond immediately to the crisis at the most critical time, when thousands of people were seeking help and chaos took over. In retrospect, the government learned too late about the extent of the disaster and waited too long to hear from local authorities about what help they needed. In the absence of information, the federal government did not take action; yet during a catastrophe, the first few hours are the most critical. That is when you can save the most lives and have a significant impact on the outcome. The reality is that during those fateful moments there is no time to wait for information or prepare plans.

The story of Hurricane Katrina shows that you cannot treat a crisis like any other project. Typical projects start by making a plan and then taking action to implement it. But in crisis, plans are often useless. On one hand, it would be helpful to think of possible scenarios ahead of time and build contingency plans for any imaginable disaster; it would also help to prepare equipment and people who are ready to respond. On the other hand, when crisis strikes, it is often unimaginable, and you must be ready to act without a plan.

The most important thing is to be there, to take action, and to give local leaders the authority to respond on the spot; above all, you must adopt the habit of improvisation, and this means that you must start doing instead of waiting until you have a plan. These kinds of projects, which we call blitz projects, represent the highest level of pace in the NTCP Diamond model. In addition, however, Katrina relief was the most complex project possible, because it involved an entire city and its people. In the complexity dimension, then, it would fall at the highest end of the spectrum.