Ntcp framework for project risk management

C H A P T E R

3

THE DIAMOND FRAMEWORK

TO GO BEYOND the conventional practices of project management, we must begin by recognizing that one size does not fit all. Unlike operations, which are repetitive, each project by definition is unique. Every project represents a new experience, addressing a new problem with a new constellation of management challenges, and the management pro- cess is never a matter of repeating known steps and procedures.

Because individual projects are unique, managers and executives need to understand the ways in which projects differ from one another and the importance of fitting the right organization to the right project. Not un- derstanding these differences, in fact, can often endanger a project and even lead to failure. Consider the following story.

The FCS Project

FCS was a third-generation fire control system developed by a well-known defense contractor in Israel. The main challenge for the FCS project was to improve the hit accuracy of weapons mounted on moving vehicles. (1)Because the contractor was experienced in building components and subsystems for similar previous genera- tions, its executives assumed that they had the capability to com- pete for an entire system. After a competitive bidding process, the company won the contract.

The major technical innovation in the FCS was a new stabilization technique, which promised to improve performance substantially.

38 A NEW MODEL FOR MANAGING PROJECTS

However, it would also require the use of technology that was totally new to the company, as well as an entirely different operational doctrine.

Nevertheless, company managers assumed that they could man- age the development of this new system in the same way as their previous, less comprehensive projects. They also assumed they could use existing modules, with minor modifications, as building blocks for the new system. In addition, they assumed that once they had developed, tested, and validated all the subsystems, it would be a straightforward matter to assemble them into a func- tioning integrated system. Based on these assumptions, they put together a team in the way they always had, and they set about the new project with the same general mind-set and methodology to which they were accustomed.

However, most of the engineers working on the program had no experience with the crucial new stabilization technology. Further- more, none of the team members had built entire systems, with responsibility for overall performance to meet the system's end-user expectations. On top of that, the whole project was new to the cus- tomer, and this meant that the ultimate performance objectives (and minimum requirements) were somewhat uncertain. The plan was to start delivering initial units after sixteen months and to begin full-scale production in three and a half years.

It soon became clear that the original project schedule was un- realistic. The project plan was therefore rewritten—twice. Still, the project steadily fell behind. After the first year, the company initi- ated emergency procedures and started to funnel additional re- sources to the program. Yet it took two full years for company managers to realize that the whole program needed to address two major problems, which lay outside the scope of the original plan altogether. By this time the crisis was full blown.

The first problem was that developing the stabilization technol- ogy would require much more time, because the new units needed additional design cycles to accommodate greater technological uncertainty.

The second problem was more profound: a complex system does not simply function as a collection of subsystems. The program needed an extensive period of system integration, together with the development of a new combat doctrine. Those activities were not part of the original project plan.

A drastic change in project management style was needed. After the intervention of top management, new systems engineering and

THE DIAMOND FRAMEWORK 39

integration groups were added to the team. In addition, the com- pany mobilized specific hand-picked experts, including external consultants, to help the team in its efforts. And top management involvement became much more extensive, with daily briefings and almost instant reporting of new problems and solutions. This change resulted in a breakthrough, and it led, after thirty-eight months, to the delivery of the first fully functioning system. Pro- duction started after five years, with a final delay of twenty-one months and cost overruns of almost twice the original budget.

Why Organizations Need a Framework

The executives of the FCS project had to learn a painful lesson. In retro- spect, if they had correctly assessed the project difficulties ahead of time, they would have instilled the right approach from the start. What the project managers lacked was a model for systematically assessing project uniqueness and understanding the key dimensions by which the new proj- ect differed from those in their previous experience.

But how can we refer to a framework, a model, or a common template if each project is unique? Are we not condemned to telling idiosyncratic stories about each new undertaking? Is there any way of establishing a coherent methodology that can be applied systematically to a wide range of projects?

The answer is yes: each project is unique, but not in every respect. When we survey a wide range of projects, we may find considerable variability— but also quite a number of common features. Indeed, as you will see, the variability itself follows certain patterns, and this means that we can develop general methods for handling various types of projects. This characteristic variability has not been captured so far in the current project manage- ment literature and is not part of the common body of knowledge.2

Project managers are often among the most creative leaders in an or- ganization, perhaps explaining why they have gravitated to this role. They have learned that they must solve their own problems, often without guidance from higher-level executives, and they still must get the job done within a limited time frame. When they don't find a solution in the text- books, they invent their own.

But what practitioners often lack is a perspective of sufficient generality; any given manager will participate in only a small number of projects in the course of a career. The contribution of scientific discipline is there- fore to extend and generalize the relevant principles beyond the scope of

40 A NEW MODEL FOR MANAGING PROJECTS

limited individual experience. In our experience, what managers need most is a model to help them identify differences among projects, classify their own projects, and select the right approach for the project.

This chapter presents the NTCP diamond model that is used through- out the book as a practical framework for addressing the variability among projects. Although the diamond model may not be the only way, it provides a workable solution and a starting point for most projects, or- ganizations, and managers. Let's begin with a look at how to assess and classify the project at hand.

How to Distinguish Among Projects

Projects differ from one another in many ways. They can be distinguished by technology, size, location, risk, environment, customer, contract, com- plexity, skills, geography, and many more aspects. But projects also have a lot in common. Every project has a goal, limited time and other re- sources, and a project manager or leader, and projects typically develop budgets, schedules, and organizations to determine who does what. The question is how to combine the common and the different elements into one model that allows managers to classify their projects and choose the right approach for each project.

To classify a project, you can employ three leading drivers: the goal, the task, and the environment.

• Goal. What is the exact outcome or product that this project needs to achieve? What does the end product do? The project's end prod- uct should be seen in a broad sense: it can be tangible or intangible, a process, a business, an organization, a system, a marketing cam- paign, or even an educational program.

• Task. What is the exact work that needs to be done? How difficult is it? How well known is it? Have similar tasks been done before? How complex is it, and how much time is available?

• Environment. The project's environment includes the business environment, the market, the available technology, or the specific industry. It may also involve the external economic, political, or geographic environment, as well as the internal environment in the company: the culture, the people, the skills, the procedures, and any other projects competing for the same resources.

Our objective was to build a context-free framework that would not depend on the industry, technology, or specific organization and would be universal enough to capture the wide spectrum of projects. In our re-

THE DIAMOND FRAMEWORK 41

search we tried to understand the underlying dimensions that make one project different from, or similar to, another in ways that can tell us how to manage projects more effectively.

Drawing on classic contingency theory, we concluded that we can de- fine three dimensions that characterize each project: uncertainty, com- plexity, and pace. (Appendix 3A discusses how classic contingency theory can be applied to projects and how these dimensions emerged. Appendix 3B includes our research questionnaire on classification and appendix 3C discusses the conceptual basis for classification systems.3) Uncertainty refers to the state of our information about the project's goal, its task, and its environment; often this information is sketchy and incomplete, espe- cially at the outset. Complexity is a measure of the project scope, reflected in characteristics such as the number of tasks and the degree of inter- dependency among them. And, of course, pace relates to the time dimen- sion and the existence of "soft" or "hard" deadlines that drive the work.