Building Customer-Based Project Organizations

Cover Page i Building Customer-Based Project Organizations Page ii This page intentionally left blank. Page iii ...

Author: Jeffrey K. Pinto | Pekka Rouhiainen

35 downloads 1239 Views 2MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Cover

Page i

Building Customer-Based Project Organizations

Page ii

This page intentionally left blank.

Page iii

Building Customer-Based Project Organizations Jeffrey K. Pinto Pekka Rouhiainen

Page iv Copyright © 2001 by Jeffrey K. Pinto and Pekka Rouhiainen. All rights reserved. Published by John Wiley & Sons, Inc. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4744. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 605 Third Avenue, New York, NY 10158-0012, (212) 8506011, fax (212) 850-6008, E-Mail: [email protected]. This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If legal advice or other expert assistance is required, the services of a competent professional person should be sought. This title is also available in print as ISBN 0-471-38509-3 (cloth : alk. paper) For more information about Wiley products, visit our web site at www.Wiley.com

Page v

For our wives, Mary Beth and Liisa, with sincerest love and gratitude.

Page vi


Page vii

PREFACE Businesspeople and readers of the popular press are bombarded with a host of new books proclaiming that project management’s time has come. Authors cite evidence from Fortune magazine (proclaiming project management the top career choice for the coming decade), company after company has adopted project management techniques, growth, professional project management organizations have proliferated in the past five years, and innumerable articles have appeared in both the popular and academic presses extolling the benefits of project management. For project managers and project-based organizations, it seems the good times have arrived. Right? Well, unfortunately, the answer is still unclear. There is no question that project management has received a great deal of attention in recent years. The number of firms using project management has risen dramatically, the number of consultants serving the sector has multiplied, and with them, so has the number of problems confronted by project management organizations. Problems? How could that be? With all the hype being generated, new “how to” books coming out every month, and so many organizations now speaking the language of project management, what kind of problems could there be? Let us briefly consider some of the evidence: Magazine and newspaper articles, as well as recent studies by a variety of consulting firms and academic researchers are suggesting some disturbing signs that the trend toward project management has not come without serious obstacles and counterevidence.

Page viii Information technology projects continue to fail at astounding rates, approaching 65 percent to 70 percent. Firms that have recently adopted project management as their panacea are looking at long lists of overruns and schedule slippages in these ventures and are quietly, but seriously, rethinking their operating strategies. Surprisingly, the same thing seems to be happening within the industries that have long traditions in project management. For example, most of the deep-water, oil drilling units that were under construction at the end of the 1990s showed considerable delays and budget overruns. Researchers are increasingly decrying the lack of “competence” in project management by so many companies that have jumped on its bandwagon. In short, the promised land has not yet been reached. In fact, for some firms, Nirvana seems to be actually receding into the distance. Why are these problems occurring? Just how serious are they? Might they not be the expected side effects of any new technology that has been adopted too rapidly, without the proper training and supporting corporate culture? These are all good questions that are at the heart of the problems we are facing. If the technology is good, what then is the source of the problems? No one answer is possible. There are many sources of difficulties faced by project-based organizations. Misunderstanding of the techniques (what they will do and what they will not do), lack of resources and systematic training in project management practices, misunderstanding of project management’s role by top management, unwillingness to commit to its goals by functional department heads, . . . the steady drumbeat of problems continues. We are not offering an analysis of whether or not project management works (it does), or whether or not it begets problems (it certainly does). By and large, this discussion would beg the larger question and miss our key point: Problems illuminate prospects. This is not a book about project management problems, but project management opportunities. Our fundamental purpose is not to

Page ix point to the problems that exist with project management as it is currently being practiced by a majority of organizations. The far more intriguing question has to do with the opportunities the steady move to project management creates for those companies that have achieved success in their operations. And this is the encouraging message that we hope all readers take from this book: In an arena that contains its share of project failures, there are also numerous examples of success. How are the firms that make project management ‘‘work” doing it? What is the secret to their success, a success that offers them a real competitive advantage in the marketplace? Where do the real opportunities lie? We believe that the key lies in refocusing our goals toward the customer. Many companies using project management develop severe myopia, focusing exclusively on internal operations and project development. They lose sight of the customer, the person, organization, or market for whom the project was originally intended. In our research, consulting, and business experiences, we are astonished by the number of firms that seem to forget this most obvious of points: Who is the client? This is not to imply that customers are purposefully ignored (although that does occasionally happen), but in the long-run, their customers’ concerns just do not seem to matter that much when they are competing with the activities of the project company. “If you build it, they will come,” is a line from the Hollywood movie, Field of Dreams. How many of us work for organizations that have a similar, Field of Dreams optimism when it comes to new product development? “If we build it, they will come” may sell movie tickets, but it will sell precious few projects. We recognize that our charge that there is a lack of customer focus is liable to raise a few eyebrows. Every individual we have ever worked with will resolutely claim that their company is “customerfocused.” And yet, when we start examining the evidence more closely, it leads to some uncomfortable, yet inescapable conclusions

Page x regarding their true level of commitment to the client. Does your organization reward its project managers and teams for speed to market or level of sales? Budget adherence or minimal customer startup difficulties? Achieving technical specifications or gaining repeat orders due to long-term relationships? In short, is your organization pushing the internal measures of success at the possible expense of the real goal? One thing we know: People act in ways that maximize their rewards. When we complain about a lack of involvement with the customer or excessive bickering across functional departments, is it due to the reward systems we have put into place and the tacit signals we are sending about what really matters. Where do the customers fit into this equation? Tom Peters, in his landmark book, In Search of Excellence, got it right a long time ago: It’s all about taking care of our customers. If we do not, someone else will. This book is our attempt to suggest ways in which project organizations can get it right. We need to clearly articulate the “right” goals that should be motivating our project management. The first “right” goal has to be an emphasis on establishing and maintaining long-term relationships with our customers. More and more global firms, including General Electric, Ericsson, Nokia, and many others, are taking a long-term look at where the balance lies in creating a healthy climate between suppliers and customers; what is referred to as the supply chain. In managing our supply chains, we start thinking in terms of stakeholder relations, efficiency, and long-term responsiveness. Our goal becomes servicing our chain rather than snapping up short-term profits at the expense of long-term profitability. This book came about as a result of years of working with and observing project-based firms that have been successful through careful management of their customers and suppliers. As a result, we have been able to formulate some principles that apply across businesses, work equally well at managing relationships within

Page xi organizations or between separate firms, and hold the key to success over time, in which past customers keep coming back for more. Building Customer-Based Project Organizations offers organizations the key to redefining the focus of their mission, recognizing (perhaps for the first time) what their primary goal must be. In this way, they become more efficient, more responsive, and far more profitable. Doing it right consists of doing right by our customers. JEFFREY K. PINTO PEKKA ROUHIAINEN

Page xii


Page xiii

ACKNOWLEDGMENTS We

would be remiss if we did not recognize the contributions of numerous people who worked behind the scenes in helping us complete this project. Risto Neuvo, managing director at Aker Rauma Offshore in Finland was a key catalyst for the formulation of our ideas. This book would never have happened without his enthusiastic support. Jeanne Glasser, acquisitions editor at Wiley, was an equally enthusiastic and energetic supporter and was the key to this book ever leaving the drawingboards. Many of our good friends have contributed to the ideas that we developed in this book. Special thanks go to Pekka Laxell from Aker Maritime Inc, Professor Markku Pirjeta of Tampere University of Technology, and Ellen Coopersmith from Decision Frameworks in Houston, Texas. For our families, Mary Beth, Emily, AJ, and Joe (for Jeff) and Liisa, Jukka, and Tapio (for Pekka), we reserve the biggest thank you of all. J.K.P. P.R.

Page xiv


Page xv

CONTENTS Chapter One Why a Customer-Based Approach Matters

1

Chapter Two Background: The Challenge of Project-Based Work Chapter Three What Is Project Success and Failure? Chapter Four Project Critical Success Factors

61

79

Chapter Five Managing the Supply Chain for Projects Chapter Six Value Chains and Projects Chapter Seven Project Stakeholder Analysis

103

127

143

Chapter Eight Creating Customer-Based Project Organizations

161

33

Page xvi

Chapter Nine Putting the Model to Work: The ARO Story 175 Chapter Ten Building the Customer-Based Project Organization Index

211

193

Page xvii

Building Customer-Based Project Organizations

Page xviii


Page 1

CHAPTER ONE WHY A CUSTOMER-BASED APPROACH MATTERS During

the decade of the 1990s, project management came into its own. Firms who had never considered the use of project-based techniques have embraced the process enthusiastically while seasoned project management organizations have continued to refine their practices. Professional societies, such as the Project Management Institute and the International Project Management Association, have grown at incredible rates, adding to membership rolls that already stand at historic highs. Project management has become the operational technique of choice in companies as diverse as electronics, information systems development, construction, banking and financial services, insurance, heavy and light manufacturing . . . the list goes on and on. What are the underlying reasons for this explosive growth and interest in project management? Why is a technique that two decades ago was generally thought of as only useful for construction, aeronautics, and very few other industries suddenly taking the business world by storm? Why is book after book being published extolling the benefits of project management? Why are consulting firms proliferating and companies lining up to board the

Page 2 bandwagon? The short answer is that these people are recognizing what many savvy firms have long known: Project management offers a unique combination of opportunities and challenges that, properly met, create a tremendous competitive advantage in the globalized marketplace. Consider the current state of business, both in the manufacturing and service sectors, and how project management can help organizations address its challenges. We have only to take a cursory look at the business world to detect some strong trends, including: 1.

Shortened product life cycles. The good old days when a company could offer a new product and depend on years of competitive domination are gone. Increasingly, the life cycle of new products is measured in terms of months or even weeks, rather than years. We have only to look at new products in electronics or computer hardware and software to easily understand this trend. We are seeing similar signs in traditional service sector firms that have also recognized the need for agility in offering and upgrading new services at an increasingly rapid pace.

2.

Small product launch windows. Another issue concerns the nature of opportunity. Organizations are very aware of the dangers of missing the optimum point at which to launch a new product and must take a proactive view toward the timing of product introductions. Put another way: While reaping the profits from the successful sale of Product A, canny firms are already plotting the best point at which to produce and launch Product B, either as a product upgrade or as a new offering. Because of fierce competition, these optimal launch opportunities are measured in terms of months. Miss one, even by a matter of weeks, and many products become also-rans.

Page 3 3.

Increasingly complex and technical products. ‘‘The world today is a lot more complicated than it was in my day.” We hear this refrain all the time. And yet, there is a large element of truth in it. The world is more complex. Products are more complicated, technically sophisticated, and difficult to create efficiently. The public’s appetite for “the next big thing” continues unabated and substantially unsatiated. We want bigger and better, more bells and whistles, larger (or smaller), faster, and more complex than the old model. Firms constantly upgrade their product and service lines to feed this hunger. That causes nightmares in design and production as we continually seek to push out the edges of the technical envelope. Unless companies find a way to maintain control of the process, this “engineering for engineering’s sake” mentality can quickly run out of control.

4.

Huge influx of global markets. In our undergraduate economics courses, we learned the nature of choices. These choices, often called the “guns or butter” decision, were based on a zero-sum assumption of a fixed pie. The fixed pie said that there was only so much to go around. Choosing more guns meant less butter was available. As we enter the new millennium, we see a pie that continues to expand. The global economic climate is not one of shrinkage or even zero-sum stability; it represents incredible opportunity on a scale never before imagined. During the stock market boom of the 1990s, it was routine for firms to be valued at 70, 80, even 90 times projected future earnings. Analysts took a look at the potential for future development and drew the obvious conclusions: There is a gold mine out there for the companies that can exploit it. Project management firms, aiming at market agility while keeping a disciplined hand on costs and development times, are ideally poised to reap the benefits of the global marketplace.

Page 4 5.

An economic period marked by low inflation. The economic mood in the developing countries remains highly favorable. One of the key indicators of economic health is the fact that inflation has been kept under control. In the United States in particular, low inflation has been one of the triggers for the continued economic expansion and stock market boom of the last decade. Unfortunately, low inflation has a challenging side effect for business; it limits their ability to pass along cost increases in order to maintain profitability. Jack Welch, former CEO of General Electric, took a hard look at this problem recently and suggested that when wages are added in, we are actually in a period of deflation, in which prices are diminishing. The implication is that successful companies of the future will be those that increase their profits through streamlining internal processes, saving money by “doing it better” than their competition. Project management is a tool to realize these goals of internal efficiency and profit in a low inflation time.

6.

General requirement for higher profit from investments. In the highly technical world of Internet companies, the investors are looking for better and faster return on their investment. For the industry, this means that there is no time for staying idle, firms have to act fast when they see an opportunity. From the project firm’s point of view, this means greater need for flexibility in developing projects faster under greater uncertainty, often learning more about the opportunity while doing. In general, project implementation has to take place in a shorter time than it used to which means using a larger number of suppliers and subcontractors. Maintaining high standards for safety and quality while at the same time employing methods such as multiple working hypothesis and concurrent engineering, sets great and often conflicting requirements for the project management.

Page 5 Oil field developments are a good example of this last phenomenon. As more and more of the word’s oil is found in the ultra-deep water, the money involved in both oil exploration and development has achieved epic proportions while the risks involved have increased proportionally as well. Basically, the “distorting lens of deep water” requires higher dollar decisions to be made quicker and with less information than ever before. As a result, the industry has turned to the use of decision tools, such as decision analysis, to make better decisions faster, recognizing the range of possible outcomes. This has led many oil companies to seek flexible field development solutions soon after discovery, rather than delay by gathering more information and “optimizing” their development solution. The petroleum industry has finally recognized that no matter how much information is gathered, the final performance of their oil fields will always be unknown until the last drop of oil is produced. Hence, flexible solutions and improved decision processes are changing the way oil companies run their business. These are just a few of the reasons why project management has become so popular in recent years. Project management is more than just the latest management fad. There is enough evidence of success to recognize that it really does deliver on its promises . . . sometimes. The fact is, however, that for all the apparent logic behind the use of project management and the success stories that we experience or read about, it is by no means a perfect picture. A disturbing trend mirrors the increased use of project management. The degree to which new projects, and in some cases industries, are failing is alarming. Let us consider some recent research examples, just from the information technology sector, regarding the viability of new projects currently being developed: l

A recent study of over 300 large companies conducted by the consulting firm Peat Marwick found that software and/or hardware development projects fail at the rate of 65 percent. In

Page 6

l

l l

other words, 65 percent of these companies reported projects that were grossly over budget or behind schedule (up to and over 200 percent), employed technologies that were nonperforming, or all of the above. Perhaps even more distressing, over half of the top managers interviewed considered these results ‘‘normal.”1 A study by the META group found that “more than half of all IT projects become runaways— overshooting their budgets and timetables while failing to deliver fully on their goals.”2 Applied Data Research surveys report that up to 75 percent of software projects are cancelled.3 The Standish Group found that of approximately 175,000 projects costing more than $250 billion each year, almost 53 percent will overrun their initial cost estimates by an average of 189 percent. Most of these projects will be delivered with less than 75 percent of their original functionality. They conclude that the average success rate of business-critical application development projects is a miniscule 9 percent.4

What is going on here? This was supposed to be the golden age of project management. At a time when literally hundreds of firms are adopting project management techniques, we are showing the kind of results that would scare off many risk-taking CEOs. Critics of these results could argue that high failure rates are in the nature of the business—anything that offers high profitability for taking risks must have a significant downside as well. And yet, although there is an element of logic in this argument, it is not satisfying. Are failure rates of up to 91 percent simply the law of the free market or is something else at work here? In a recent book, a noted project management researcher and author, Dr. David Frame, decried the lack of competence in our project-based firms.5 Dr. Frame knows whereof he speaks: As director of certification for the Project Management Institute for

Page 7 many years, he has had a ringside seat to the explosive growth in the field. He has also observed the classic failure of function to follow form. We adopt project management as a competitive tactic without providing sufficient training for our managers or time for the necessary cultural shifts in support of the approach. His arguments offer an important perspective in the debate: Is the technique at fault or is it our inability to successfully implement the technique, performing all the steps that effective implementation implies (i.e., training, coaching, phased-sequencing of steps, and culture reshaping)? This book offers an extension to Frame’s argument. “Competence” in project-based firms lies not only in getting the process right, but also in knowing the elements comprising the correct process. Many firms experience problems with their project activities because they are unintentionally rewarding the wrong things, unwittingly encouraging people to make the wrong choices, mistakenly focusing on inaccurate measures of project performance. The key lies in getting the initial project focus right: It is only when we have the correct goals picked out that we begin to see our people working their projects in an appropriate manner. What is the “correct” focus? From our years of experience in researching, consulting on, and managing a wide variety of projects, we are convinced that the correct focus remains squarely on the customer. Whether that “customer” is an external market opportunity, a one-shot industry client, or a group internal to your organization, the goal is the same: creating a focus in which the customer takes center stage, critical decisions revolve around their needs, and project managers and their teams are rewarded for the manner in which they satisfy their prime customers. This book is an effort to refocus on the proper target. Too many organizations adopt project management for its cost control discipline, using limited budgets and carefully constrained schedules as a way of maintaining optimum operating discipline. There is nothing wrong with recognizing these benefits of project management.

Page 8 The problem is when these controls become an end unto themselves, when the focus, at first subtly and then more overtly, shifts to project management as an internal control mechanism. Such an “inward” look creates huge potential and realized problems for projects in the marketplace. When we seek to satisfy internal controls of time and budget exclusively, we get what we pay for: projects that often have little attraction for a wide external market. Consider one example: a Fortune 500 computer manufacturer where, during the 1990s, all new projects were initiated by the hardware engineering department. These projects rarely were the result of interaction with the marketing function; after all, what can they possibly tell us about computers? In adopting this Field of Dreams mentality (‘‘If you build it, they will come”), the company went through several years of declining sales, reorganizations, layoffs, and unattractive product offerings. They had refined their internal operations to a fine edge, they hit their launch windows, they kept a lid on costs, and they steadily slipped toward Chapter 11 reorganization.

CREATING A CUSTOMER FOCUS Customer focus is an expression that we find today among the core values of many companies. But how often do we think about what these two words really mean? In refocusing our operating philosophy externally, the floodgates open to a variety of profound issues. More to the point, we find that these words generate a follow-on set of questions as we begin to explore their meaning in greater detail. What does it mean to be customer focused and what do we do differently when we are focused on our customers? Why do we have to be customer focused, anyway? Finally, can we afford to be focused to our customers and their needs instead of being focused on taking care of our business, or is that actually the same thing?

Page 9 In this book, we use the term Customer-Based Project Management (Figure 1.1).6 The customer focus is rapidly emerging as the cornerstone of successful project-based business for a variety of reasons, some of which directly follow from our earlier discussion. Consider, for example: l

l

l

Huge increases in global competition. The rapid increases in information processing and telecommunications have allowed companies worldwide to conduct business in real time across the globe. Organizations that previously had a clear sense of the competition are discovering new rivals almost weekly. Increasing demands for cost-consciousness. In a time of economic stability (low inflation), profits continue to be generated from improvements to internal operations. Organizations that become lean and efficient will thrive; the rest will fail. The need to minimize risk. Both parties—the project organization and the customer—have a strong vested interest in keeping risk manageable. The greater the sense of commitment to the development process by all stakeholders, the greater the likelihood of lowering risks for everyone. Figure 1.1 Implementation: Customer Focus and Customer-Based Project Success

Page 10 It is important to note that customer focus does not mean we are referring exclusively to project firms dealing with external clients. Even within an organization, projects are created with a customer in mind. An upgrade to the firm’s information system would involve numerous internal clients. The creation and implementation of a new operating philosophy will have an internal customer base. Certainly these obvious examples of customer focus tend to refocus our attention externally, as in the case of build-to-order construction or engineering projects, new product introductions, and so forth. Nevertheless, our experience points to the fact that a customer-based project management philosophy is fundamentally powerful and compelling regardless of the relationship of the customer to our project team and parent organization. Having a customer focus means shifting from a goal of maximizing our profits in one project by optimizing the utilization of our resources to a goal of superior service to the customer to maximize the value of the customer’s project by meeting the jointly agreed project goals. It also implies our willingness to adapt to changes in the customer’s goals during the project development. In other words, shifting from suboptimizing the short-term profit in one project to optimizing the total value of the customer’s project, thus ensuring a relationship that maximizes the developer’s profit in the long run. The focus here is key. If my focus is short-term, aimed at wringing every last possible dollar of profit out of a project at the expense of clients, subcontractors, and other relevant stakeholders, I am deliberately sacrificing long-term opportunities. On the other hand, if I approach all customercontractor relationships as potentially long-term and mutually advantageous, I may willingly make short-term decisions that will cost me money in order to maximize the overall value of the project to the client. I do this, however, in the interests of building and maintaining a long-term relationship. The point is simple: If our sole concern is profit this quarter, then by all

Page 11 means, we should engage in any confrontational and antagonistic behavior necessary to hit our profit goals, even at the expense of client satisfaction. If I seek a healthy relationship with a stable customer base over the long term, I will make the appropriate trade-offs to ensure it remains healthy. Figure 1.2 illustrates a number of points about the nature of customer satisfaction and how we can anticipate and positively influence it. This example uses a build-to-order construction project. This project time line is simplified to demonstrate only three stages: sales, execution, and operation. Further, the contractor has three distinct goals to address: (1) the product that is to be delivered, (2) the project itself that will produce the product, and (3) the relationships with the customer. Note that product and relationship concerns already exist at the starting point and continue after the project has been terminated, while project management issues come into play at some point just prior to the contract signing and end at the delivery point. When we follow the three stage life cycle, we can observe some common side effects of each of these stages on contractor-customer relations. Sales refers to the organization’s activities aimed at selling the client on the project. All marketing activities, engineering Figure 1.2 What Is Customer Satisfaction in Projects?

Page 12 demonstrations, and financial qualifications are included in this process. As a result of the intense wooing of the customer, the customer satisfaction curve is highly positive. By the contract signing stage, both parties (contractor and client) are in a very positive mind frame. Ironically, almost immediately after the contract signing, the honeymoon has a tendency to end. The parties begin arguing over contract terminology, promised deliverables, schedule, and money, as well as a host of other issues. Predictably, the customer satisfaction curve takes a swing downward, relations become soured, and a general air of mistrust begins to infect the project development. Finally, as the project ramps up toward conclusion, relations take a similar upward trend in anticipation of successful contract completion. This happens simply because the job has been done and a certain level of customer satisfaction is necessary to get the project delivered. The next fly in the ointment occurs during the final delivery stage. At this point, the users get involved and start to operate the product. The readiness of the operators to use the product depends on the level of user involvement during the project and the quality of the user documentation and training that has been provided. Often these things are overlooked or given less rigorous attention that results in problems with operator satisfaction. However, as the operators learn to use the new systems, the level of satisfaction goes up and reaches the final level. The end result is, hopefully, a successfully completed project leaving all parties happy. The dramatic swings in relationship and customer satisfaction are due to the short-term horizon adopted by the typical project organization. Relationships are defined to start at the point a Request for Proposal (RFP) is let and are assumed to conclude when the project has been delivered. Every action is discrete and when, concluded, nonrecurring. The obvious problem here is that by the time the project is completed, relationships may have become so soured between the firms that the likelihood of future business is impossible. This

Page 13 represents a classic problem of winning the current battle while losing the long-term war. When we define project success in terms of our ability to gain every last dollar from an adversarial relationship and when we have to threaten to revert to legal remedies and threats of liquidated damages because of noncompliance, we are creating an atmosphere in which it is impossible to work together with the goal of providing the client maximum value. In contrast, an approach that focuses on customer satisfaction has the objective of operating within a much narrower range of client attitudes (Figure 1.3). Rather than allowing the satisfaction of the customer to go through the various peaks and valleys across the project’s development and transfer, a customer-based project management philosophy is aimed at maintaining consistently high levels of customer satisfaction. This is partially possible because we are usually able to predict in a contractorclient relationship where the high and low points are likely to occur. Consequently, we can take proactive steps to manage the points of likely tension to ensure that misunderstandings do not build up to the point where a Figure 1.3 Acceptable Variation of Customer Satisfaction

Page 14 cooperative relationship becomes adversarial. The message comes through to the customer as well: We are committed to doing everything necessary to ensure your satisfaction.

IMPORTANT CONCEPTS It is necessary to identify some common themes early in our discussion because we will be using them throughout this book. Although most of us have an intuitive understanding of these terms, they form the backbone for our discussion and must be clearly understood.

Project Success Definitions of successful projects can be surprisingly elusive. How do we know when a project is successful? When it is profitable? If it comes in on budget? On time? When the technology we are developing works? When we achieve our long-term payback goals? It is ironic that project management continues to have great difficulty in identifying a mutually acceptable and encompassing definition of success. Perhaps our difficulties in defining success are similar to Justice Potter Stewart’s oft-quoted description of pornography (“I know it when I see it”). Most of us naturally gravitate toward the historical definition of the triple constraint in project management; that is, the classic definition of a project’s goals as comprising time, budget, and performance: l l l

Time. Did the project come in on or before established schedules? Cost. Did the project get completed within the budget guidelines? Performance. Did the finished project operate according to specifications?

Page 15 These three criteria have more recently been joined by a fourth: client acceptance. Client acceptance argues that projects that have been developed according to the triple constraint have a potential to miss the most important hurdle of all, the acceptance and use of the project once completed. In the old days, when project management was primarily a construction and heavy industry technique, the overwhelming reason to use it was to maintain internal organizational discipline in expenditures of money and time. Under those assumptions, a triple constraint made perfect sense. It was focused internally on efficiency and productivity measures, it provided a measure for personnel evaluation, and it allowed the cost accountants to keep a clear handle on expenses. Unfortunately, more recently, the triple constraint has come under increasing pressure as an inadequate measure of project success. Including client acceptance as a fourth criterion of success has some obvious benefits. First, it refocuses corporate views outside the organization toward the customer. Who cares if we are efficient if all we produce is a lemon? Second, it recognizes that the final arbiter of a successful project is not the cost accountant, but the marketplace. Projects are only as good as they are used, either to improve the activities of other parties or to open new avenues of revenue for the company. Finally, client acceptance requires project managers and their teams to create an atmosphere of openness and communication throughout the development of the project. Consider the following example: By the late 1970s most American auto makers had hit the skids. We were losing market share in huge chunks to foreign car makers, we were making a shoddy product, and we were no longer appealing to modern standards of taste. In this system, a “successful” project (a new car) could be introduced, only to fall flat on its face in terms of sales. Ford Motor Company finally got the right idea by scrapping the old methods for design and car development. They went back, literally, to the drawing board and reengaged in a dialogue with their customer base,

Page 16 including surveying old customers who had switched to buying other brands. Through intensive interviews, focus groups, and a willingness to listen to what people were telling them, Ford created the Taurus, a radical departure in design from previous models. The Taurus has been a wildly popular car for Ford, spearheading their move in overtaking General Motors as the most profitable auto company in the world during the 1980s and 1990s. What was the key to this success? Clearly, a willingness to reorient their focus toward the customer. In the same way, other project management organizations have begun viewing client acceptance as more than just an addition to the triple constraint, but as ultimately the necessary condition for project success. Another model of project success traces its roots back to earlier work from the 1970s in the field of management. The proponents, Randy Schultz and Dennis Slevin, argued that successful implementation of a new system, project, or method within a firm required passing three equally important hurdles: technical validity, organizational validity, and organizational effectiveness.7 Technical validity asked a simple question: Does the system or project work? Is it a good technical solution to the problem the company faces? If the answer was yes, the project was said to be technically valid. The second measure, organizational validity, is concerned with ensuring a fit between the needs of the client and the project: Is the project appropriate for the client? A project may be an excellent technical solution to a perceived problem and still is not used because it is not right for the client. For example, proposing a highly technical solution to a communications problem where the client base has no technical training or aptitude may make technical sense, but simply not fly in the face of workforce limitations. Finally, organization effectiveness asks the bottom-line question: What positive impact has the project had, either on the organization’s profitability (in the case of a new product) or the improvement of their operations? Organizational effectiveness is predicated on the

Page 17 natural assumption that the project is being pursued to show positive outcomes.

Success Framework With the measures in place, let us consider a model of project success that we will refer to throughout this book (Figure 1.4). The customer-based project management framework described in Figure 1.4 is a house that is built using several elements. The foundation is the standard that ensures the basic quality of the process of producing and delivering the product to the customer. International standards of quality, such as ISO or QC, are well recognized around the world and have become a form of competitive advantage for firms that have achieved the certification. Without quality as the foundation, it is impossible to consider other meaningful notions of success. Everything else builds on this foundation. The first floor is the infrastructure that is needed to physically produce the different elements of the project. This includes design Figure 1.4 What Are the Basic Elements of Customer-Based Project Success?

Page 18 and engineering suppliers, materials and components suppliers, manufacturing suppliers, logistics services suppliers, and so on. In general, the infrastructure covers all the elements that are needed to make the project physically happen. From the project developers’ point of view, it does not make a difference who owns the infrastructure resources, whether they are owned by them or provided by others as an outside service. The key to effective control of infrastructure resources is supply chain management. Supply chain management gives us an understanding and control of the resources we have in place to make the project succeed. If, in our clients’ evaluation, the infrastructure is substandard or critical elements are missing, it gives them a strong reason to look elsewhere for their work. We will be addressing the various components of the supply chain and showing its link to effective project management in following chapters. The second floor is the project management that is needed to run the different elements of the infrastructure and to pull everything together to deliver the product to the customer. This includes the people, as well as the systems and procedures. This step in the success model requires us to take a critical look at our project management processes, control and administration systems, and people. One of the critical shortages in this new era of project management is a dearth of personnel trained in project management techniques, as well as a cadre of trained project managers. The third and top floor of the model is the customer relationship management that is needed to ensure the technical and organizational validity and organizational effectiveness of the final product. This includes the people, systems, and procedures that are needed for the initial definition of the product based on the customer need, as well as adapting the necessary changes in customer needs that are likely to take place over the life of the project. Furthermore, this level includes the feedback systems and procedures that are needed to communicate the status and the changes in the project to the

Page 19 stakeholders in both the project developer and customer organizations to facilitate decision making. Based on our definition of customer-based project management, the project organization should shift their focus from maximizing profit in one project by optimizing the use of resources to offering superior service to customers to maximize the value of the customer’s project. In making this proposal, we are suggesting an approach that violates one of the basic rules of all business enterprises: concentrating on making profit. To be willing to forego short-term profit, the contractor has to be sure that it makes sense in the long run. This simply does not happen without good customer relationship management. In this approach, the customer and the contractor have to understand one another well. The initial project goals and the success drivers, as well as any changes to them during the project’s development, have to be comprehended by both parties. This is why supply chain management is so important: Changes to the project affect not only the contractor organization, but they have a ripple effect through the supply and distribution chains as well. Without proper supply chain management, it is impossible to respond rapidly to changes in the project with minimal disruptions not only to operations but to the operations of the supply chain members.

Product Thinking One term that needs greater explanation is product thinking. Product thinking is the result of conceptualizing the fundamental product we offer another organization or market. The product can be based on hardware, software, service, or a combination of these. To understand the concept of product thinking, it is necessary to view it from the perspective of the customer. That is why organizations marketing consumer products devote so much time and money to conducting consumer surveys, focus groups, niche penetration analysis, and so forth. The ability to sell a product that measures up to

Page 20 customer expectations requires us to look at the project from the customer’s perspective. In the world of global business and tightening competition, only those firms that excel in mastering the details of their business can be highly successful. For project developer firms, this means a great challenge through requiring continuous learning and process improvements, usually in very complicated business environments. This is where product thinking comes into the picture. It helps the firm to focus on the details that are critical for their success. The project firms that adopt the concept of product thinking can more easily build their quality standard, supply chain management, project management, and customer relationship management—the successful framework in Figure 1.4. Figure 1.5 presents the product as a combination of the product concept and the delivery process of getting the physical product to the customer. The customer is weighing two separate considerations in deciding whether or not to award us the job and then in evaluating our performance. First, the customer is keenly interested in the product concept that we are offering. Here the concepts of technical validity, organizational validity, and organizational effectiveness come Figure 1.5 What Is Product Thinking in Projects?

Page 21 into play. Is our project technically competent or does it rely on a new and previously unproven technology? Are we proposing an excessive or risky solution? Further, does the product concept we are proposing fit in with the image the organization has of itself and its operations? Are we matching our product concept to the customer or are we foolishly expecting customers to alter themselves to fit it? Finally, does the product concept offer the opportunity for enhanced effectiveness? How do we know? What information or evidence can we offer to allay their concerns about the result of implementing the project? These first elements are based on anticipating the customer’s concern for the product concept itself. Beyond that, it is also necessary to recognize their concern for the way that the product is delivered to them. A highly important project that is poorly implemented can do the project developer firm great harm in the eyes of the client. This element is referred to as the delivery process. The delivery process involves the other set of criteria that customers weigh in deciding how to evaluate alternative proposals and ultimately, their satisfaction with the project’s implementation and contractor performance. Among the chief concerns of customers relating to the delivery process are the issues of schedule and budget adherence.

Project Risk Risk refers to the degree of uncertainty that the client is willing to undertake in contracting to have a project implemented. In simple terms, the forms of risk can be categorized as health, safety, and environmental (HSE) risks; schedule risks; cost risks; and other risks. Risk results from several factors. Among these are the lack of information about the project organization itself (How reliable are they? Can I trust their estimates and promises?) and about the product concept due to technical complexity (Is it proven technology? Will it work as anticipated? If it doesn’t, how much will

Page 22 it ultimately cost me to make it work?) or other forms of unanticipated risk (threats of economic downturn; new, more attractive product introductions by competitors; technological breakthroughs; and so forth). Risk can be categorized as: Project Organization l l l

Contractor reliability. Will they perform as promised? Contractor viability. Will they be here next year? Contractor expertise. Do they know what they are talking about?

Project l l l

Will the technology work as intended? Is the technology upgradable? Does the project suit our needs?

External Impacts l l l

Are there threats of economic downturn? Will the need for this product dry up? Will competitors introduce a later generation or more sophisticated product?

These are just some of the relevant risks that firms must take into consideration when evaluating the delivery process for a product. Combined with the notion of the product concept, they paint a comprehensive overview of the challenge involved in selling a client on a proposed project. Equally importantly, we need to recognize that the mix of factors considered by the contracting firm will change when dealing with differing firms and project opportunities. The inherent risk associated with a project is a direct function of the relationship the two groups or organizations have formed. When I have a positive relationship based on trust and a record of

Page 23 strong past performance, the relevant risk associated with new ventures is much smaller than circumstances in which risk remains high. What is the message here? Creating an effective product results from a demonstration of both a strong product concept and delivery process. We sell the customer on our ideas through paying attention to their need for a top-notch product, including optimal project delivery. To illustrate, consider the two examples: When we are intent on purchasing a basic consumer product we usually choose the product based on its price, quality, performance, and other relevant specifications. We don’t think very much about the process that went into producing it. We might be interested in where the product was made, or how environmentally sensitive the production process was, but in general, as consumers, we are mainly interested in the physical product itself and its performance. In the case of large projects involving significant investment, on the other hand, the situation is very different. Certainly the product concept (along with its degree of technical validity, organizational validity, and organizational effectiveness) is important. However, a large investment project is always a sum of a great number of elements that all have to come together in a certain schedule and cost framework to form the final product. In most cases, managing these pieces and the interfaces between them is impossible without focusing on the processes that produce them. Here the quality of the process very much dictates the quality of the outcome. The process may include design and engineering, purchasing, manufacturing, testing, logistics, commissioning, and start-up. It may also include a great deal of development work to make the new elements of the product concept perform as planned. In this kind of project, the customer typically carries out an extensive risk analysis involving a detailed evaluation of the delivery process. The result of this analysis has a significant effect on the decision to whom to award the contract.

Page 24

PROJECT LIFE CYCLE Project life cycles indicate the logic supporting the development process for that particular project. There are two ways to view the life cycle: (1) as a discrete function of internal development, and (2) more holistically, as involving elements of customer and supplier relationships as we track the overall process from contracting to installation. First, consider a simplified model of the project life cycle as a function of its internal development only (Figure 1.6). In this life cycle, we identify four distinct phases of the project’s development: Conceptualization, Planning, Execution, and Termination. l

l

Conceptualization refers to the initial goal development and technical specifications for the projects. The scope of the work is defined, the necessary resources are identified, and the important organizational contributors or stakeholders are signed on to the process. Planning is the stage in which all detailed specifications, schematics, schedules, and other plans are developed. The work Figure 1.6 Project Life Cycle Stages

Page 25 packages are broken down, individual assignments are created, and the process is delineated. l

l

Execution is the actual work, system developed, product created and fabricated, or other projectbased activities. Termination involves transferring the completed project to its customer, reassigning the project resources (people, money, physical plant), and formally closing out the project.

These stages are the way-points at which the project team can evaluate their performance and the project’s overall status. This life cycle is relevant only after the contract has been signed. It begins with project development, the creation of myriad plans and schedules, the work of project development being performed, and the completion of the project and reassignment of personnel. When we evaluate projects in terms of this life-cycle model, the key determinants of success often relate far more to those traditional, internal metrics of time, schedule, and performance than under the alternative model. In the second-life cycle model, we consider the whole project life cycle starting with initial response to a client need or RFP, sales contact, mutual needs assessment between the client and the bidding companies, bidding process, contract award, project development, delivery, installation, and operation of the completed product. That is, the second model includes the original four-stage life cycle plus several additional activities related to both front-end and back-end operations. Figure 1.6 gave an example of this large-scale project life cycle. This model, which mirrors a number of situations from new product development to construction and engineering support services, is becoming increasingly prevalent. Further, it is easy to see that when the project life cycle is evaluated in this larger sense, a wide variety of external relationships with customers, suppliers, and distributors come into play. Clearly, the implications of the larger project life cycle suggest that greater challenge of running projects when all the relevant external stakeholders must be considered as well.

Page 26 Project management is no longer a simplified (albeit very challenging!) internal development process. Now it requires highly complex scheduling and coordination of the activities and deliverables of an assortment of suppliers. It also involves a much larger project team, including salespeople, support services, logistics, quality assurance, and administrators. Life-cycle planning ultimately presents a much more difficult challenge to the project organization because we are linking it directly to an organization’s supply chain. Project management becomes impossible without effective supply chain management.

GAINING THE CONTRACT In an external project, under conditions of competitive bidding, the process of achieving a contract can be extremely difficult. In most cases, price competition is fierce. As we have noted previously, it is not unheard of for one company to literally buy a contract to keep their employees working, sacrificing any possibility of profit to stay in the business during down cycles. How can effective project-based firms compete under intense global pressure? How do we get a project contract? The basic corner stones of a contract between the customer and the contractor are scope of work, project execution plan, price, and commitment (Figure 1.7). Deciding what is the magnitude, level of detail, and order of priority of these elements in any particular contract depends very much on the situation. In some circumstances, the key feature the customer is looking for may be simply price. The customer may view alternative project options as essentially interchangeable, that is, undifferentiated. When one option is basically as good as the next, it is usually appropriate to look no further than price in making a contract award decision. General Electric Company has a sterling reputation for the efficiency of its global outsourcing operations. For many of the products it outsources, it looks for the optimal price and awards the contract on that basis.

Page 27 Figure 1.7 What Are the Basic Elements of a Project Contract?

In other organizations, projects, and circumstances, price decisions are not sufficient. Boeing Corporation, the world’s largest manufacturer of airframes, has a highly sophisticated outsourcing operation that involves establishing long-term linkages with relatively few, high-quality subcontractors. These subcontractors must prove their commitment to the Boeing quality model by allowing the aircraft manufacturer’s quality staff onsite, in order to instruct the subcontractor in the expected process for developing the subassembly parts. Price matters, but of equal importance to the Boeing personnel is the evidence of commitment to their quality model. In another example, consider the operations in the oil industry where an oil company contracts with a firm to deliver an offshore facility worth hundreds of millions of dollars. This kind of contract is backed up with an extensive amount of preparation work and documentation including detailed definitions of scope, price, schedule, and a detailed project execution plan. You would assume that such preparation would take care of all customer concerns. However, even here the commitment from the contractor team to meet the jointly agreed goals is still an important factor in making the project happen. This is often emphasized in team-building sessions and commitment statements signed by all project team members.

Page 28 These examples provide evidence of the expanded role that project management has taken, from the old, internal focus to an enhanced, large-scale approach that requires a far greater degree of global thinking than many organizations are used to considering. The key, as we will demonstrate in the following chapters, lies in creating an attitude of supply-chain thinking on the part of our organization. Managing the process now means managing a far larger scope of project than has been the case in the past for many companies.

COMPETITIVE PRICE When considering how to determine a competitive price for a project, a number of factors must be considered. Figure 1.8 illustrates the nature of cost and price competition for a project contractor competing for business. Bid price is subject to a number of diverse factors, including fixed and variable costs for the project firm, competition and market price Figure 1.8 What Is Competitive Price?

Page 29 pressures, customer expectations, desire to sacrifice short-term profit to create a long-term relationship, and so forth. In fact, most project organizations engage in highly sophisticated cost accounting to first determine which projects are worth bidding and then to determine how much they can bid and still realize a necessary return on capital. In some industries, project bidding is so intense that continual turnover of companies is the natural state as firms discover their inability to remain competitive due to changes in market conditions. The project organization that adopts the philosophy of customer-based project management has to build and implement the foundation and three floors of the framework house (see Figure 1.4): quality standard, supply-chain management, project management, and customer relationship management. This is an effort that involves investment both in our personnel and systems and does not come cheap. A reasonable question could be asked: Isn’t this going to put the contractor in a very unfavorable position in price competition? In other words, will the investment in this philosophy pay off or will it only price me out of range of competitors? If we merely consider the price that we are able to quote the customer, we most likely are going to be higher than some of our competitors just because we understand our cost basis well and also have to get a higher return on our initial investment into the systems we have developed. However, when the risk-weighted assessment of the customer’s project cost is made and the necessary contingency is added to the price of each contractor, the one with the customer-based project management approach should come in lower and be competitive. Remember, all project bids factor in a contingency to cover the unexpected (i.e., risk). In our case, the customer’s risk-weighted assessment will show a higher bid price but will almost certainly show a significantly lower risk weighting and risk-weighted cost due to the commitment to a higher quality standard resulting in higher quality of our overall operation in

Page 30 comparison to competition. This point is important and we will revisit it throughout this book. A customer-based approach to project management is predicated on establishing and nurturing long-term relationships with a customer base. That focus helps us to better understand the total cost, schedule, and risk impact of our product as part of the customer’s process. It further creates an opportunity to offer a competitive price, based on a lower risk product than our competition. A goal of offering optimal service to your clients is inimical to milking every last drop of profit out of a contract, usually at the expense of your customer. The key, as we shall demonstrate, lies in convincing our customer base that in a long-term relationship paying a reasonable price for a high-quality product will be more than offset by the savings gained in the down-stream operations during the product life cycle.

OUR APPROACH This book develops a new model for project-based management, one that is focused on customer satisfaction, not at the expense of internal efficiency, but as a complement to it. To successfully develop this theme, we use supply-chain concepts. Supply-chain management is based on identifying and managing all stakeholder relationships in the company’s supply chain; that is, identifying all suppliers, customers, and subcontractors and developing a coherent, overall plan for maintaining effective business relationships with them. Customer-based project management is only understandable in terms of an organization’s overall competitive and operating position. In subsequent chapters, we examine the nature of successful project management in today’s business environment. We argue that a customer-based approach to project success is at once both easier and more complex than current understanding of the term. For example, we include a discussion of a relatively new concept, the quality chain, to expand our thought process away from simple

Page 31 project development to the larger issue of the strategic use of projects as a method to gain competitive advantage in the marketplace. Quality chain thinking requires companies to think in terms of how and where they can best offer value to their potential customer base. This operating philosophy is beneficial because it starts shaping and refining our thinking in terms of what we do best. What types of contracts should we be competing for? What geographical or regional areas are we most capable of supporting? What types of projects can we derive the greatest profit margins from, relative to our competition? These are some of the questions that naturally follow from an understanding of project management within the quality chain. Customer-based ideas for project management are new and require companies to think outside traditional approaches. That offers readers either intense discomfort or highlights entirely new levels of possibility: There is very little middle ground here. The good news is that these ideas have been proven to work, they are not just the result of sterile theoretical thinking. Several organizations we have either worked for or consulted with have put these approaches into practice with highly successful results for them and their customers. That is the key point: What is being offered here is win-win project management. Not profit at the expense of the customer but mutual opportunity and payoff for all parties to the process. It is our belief that implementing these ideas will lead many tradition-bound project organizations to looking at projects in an entirely different light. In this new model, we can chart an approach that makes the customer an equal partner in the process.

NOTES 1. J.K. Pinto and I. Millet. (1999). Successful Information System Implementation: The Human Side, 2nd ed. Newtown Square, PA: Project Management Institute.

Page 32 2. G.K. Kapur. (1998, May). ‘‘Don’t Look Back to Create the Future.” Address given at the Frontiers of Project Management conference, Boston. 3. CIO. (1995). November 15, p. 5. 4. See note 2. 5. J.D. Frame. (1999). Project Management Competence. San Francisco: Jossey-Bass. 6. B.T. Barkley and J.H. Saylor. (1992). Customer-Driven Project Management: A New Paradigm in Total Quality Implementation. New York: McGraw-Hill. 7. R.L. Schultz and D.P. Slevin. (1979). “Introduction: The Implementation Problem,” in R. Doktor, R.L. Schultz, and D.P. Slevin, eds., The Implementation of Management Science. New York: NorthHolland, pp. 1–15.

Page 33

CHAPTER TWO BACKGROUND The Challenge of Project-Based Work This chapter is a short primer in basic project management terminology and processes. It is aimed at the novice project manager or the manager whose organization is contemplating its first movements into project-based work. We avoid the assumption that readers are universally savvy in running projects and naturally understand the points we are making. In the case of new project managers, this chapter provides the necessary background on the setting and processes of project management that make it such a challenge. Those reading this book who are acquainted with project-based work can use it as a refresher or skip it. In an increasingly interwoven and fast-paced corporate world, projects have become the engines of growth for most companies. Whether the company regularly employs project teams or creates them to address immediate crises or market opportunities, the use of projects and cross-functional teams continues to proliferate. Wherever we look these days we can find teams of people working on projects, headed up by a project manager. Indeed, the use of project management is now a worldwide phenomenon, operating

Page 34 in companies around the world. This substantial increase in the use of project teams represents a mixed blessing for most companies. Research and anecdotal evidence demonstrate the tremendous flexibility and improved time to market that project-based work allows modern corporations. However, many companies that are starting to use project teams for the first time are also discovering the concomitant constraints that project-based work offers. Among these many constraints are those that are: (1) structural—relating to the way project teams are established and exist vis-à-vis the traditional functional hierarchy, (2) technical—consisting of the determination that the organization possesses the necessary training and technology to efficiently run their projects, and (3) behavioral—suggesting that many project-related problems encountered by organizations are the direct result of human interactions, often due to the newly created cross-functional teams and different operating philosophies and goals held across various departments and levels in companies. The balance of this chapter addresses some of these key issues while offering a primer of important terms and concepts in project management. Most of us understand implicitly what terms such as project or life cycle mean. However, we must devote some time and attention to reexamining and formally defining these and other important terms so that we have a common body of basic knowledge of the key terms and properties of projects. As we continue to use terms such as project management throughout the course of this book, we use the meaning that we explain here.

WHAT IS A PROJECT? Although we see or read about impressive examples of projects every day, actually defining a project is sometimes not easy. The monumental engineering feat known as the Eurotunnel (or Chunnel), the successful bid for the 2000 Summer Olympic Games by the city of

Page 35 Sydney, the great pyramids of Giza, and the Panama Canal are all well-known examples of projects. On a less grand scale, the completion of a team project at school, writing a term paper, decorating the house for a Christmas party or a visit from family, or a weekly shopping trip to the grocery store are all examples of projects that we engage in on a daily, almost routine, basis. While vastly different in form, time frame, and objectives to be accomplished, each of these examples, whether great or modest, shares some common properties that define the nature and character of most projects. To be meaningful, we need to consider definitions that are general enough to include a range of organizational activities that comprise project functions. At the same time, the definition should be narrow enough so that we are able to focus specifically on those organizational activities that both managers and writers can agree are project-oriented. There is an excellent definition of projects from the Project Management Body of Knowledge published by the Project Management Institute: A project is a temporary endeavor undertaken to create a unique product or service.1

Using this definition, it is possible to isolate some of the important characteristics underlying projects.2 Four common characteristics of projects include: 1.

They are constrained by a finite budget and time frame to completion; that is, they typically have a specific budget allocated to them as well as a defined start and completion date. Further, their budget may often represent a significant portion of the resources of the performing organization.

2.

They comprise a set of complex and interrelated activities performed by diverse resources or organizational members that require effective coordination.

Page 36 3.

They are directed toward the attainment of a clearly defined objective or set of objectives which, when achieved, mark the end of the project and the dissolution of this project team.

4.

To some degree, each project is unique.

These features form the core that distinguishes project-based work from other forms of organizational activity. Because they are significant and underscore the inherent challenge in managing projects, it is important that we examine each of these characteristics in more detail. In addition to developing a general understanding of projects, as we discuss each of these features, we will also begin to see the roots of conflict that are embedded in the characteristics of projects themselves.

Finite Budget and Schedule Constraints Unlike the typical ongoing operations that occur within line or functional units of most corporations, projects are set up with two very important limits on their activities: a specified time period for completion and a limited budget. Projects are temporary undertakings, intended to solve a specific problem (more on this later). They are not intended to supplant the regular functional operations of the organization but rather, operate until they have achieved the goals they set out to accomplish. Once these objectives have been completed, the project ends. Certainly, we should note that budget and time constraints are estimates, based on the best available (and sometimes naively optimistic) information that the organization has. As a result, it is not uncommon to build in a margin for error to allow for unforeseen expenses or time slippages. The key to understanding the nature of project work as opposed to, say, an assembly line production run is that, unlike the production line which can continue on into the indefinite future,

Page 37 projects are temporary. They fulfill their goals, in accordance with time and money limits, and disband. Given the significant portion of an organization’s budget that projects often comprise, it is clear that in making budgeting and project selection decisions, there is a strong propensity for conflict. There are bound to be differences in opinion as to how scarce resources such as money and personnel are used. One obvious reason is that in making such choices, we are implicitly (and many times explicitly) making trade-off decisions. That is, it is impossible for me, as the manager, to give approval and funding to two competing projects. Therefore, I make my decision on the basis of a number of criteria that will naturally throw the two potential projects, along with their prospective project managers, into conflict.

Complex and Interrelated Activities Projects typically comprise a degree of complexity that is not found to the same extent within other functional departments, often due to the cross-functional nature of the activities. For example, in developing a new product, a project team may be staffed with members from a wide variety of functional backgrounds: marketing, production, finance, human resources, and so forth. This crossdisciplinary nature of much project-based work adds another order of magnitude to the usual levels of complexity found within any individual department. Unfortunately, the complexity and interrelatedness of projects has some unwelcome side effects: power, political processes, and conflict. Political activities and power considerations abound within projects due to the unique properties that they possess as well as the multiple goals and attitudes of different members of the project team. Not only are projects forced to compete with functional units for their share of a variety of scarce resources but even within the

Page 38 project team, the almost ubiquitous nature of conflict is clearly demonstrated. Members of the project team regularly experience these sources of tension and must seek a balance between dual allegiances to their functional bosses and project manager. Another example of the complex and interrelated nature of projects derives from the multiple activities that are carried out, often simultaneously by different members of the project team. This interrelatedness is typified by the project network diagram used in the Critical Path Method which demonstrates the sometimes bewildering array of interdependent activities performed by a project team. If tasks are not performed in their correct order and within the time allotted to them, the entire project can be jeopardized. Consequently, the project manager’s job here is twofold: first, to establish a coherent working relationship among a number of team members from diverse functional backgrounds, and second, to create a planning, scheduling, and control system that permits the greatest level of efficiency of project activities.

Clearly Defined Objectives Projects are usually created with a specific purposes or narrowly determined set of purposes in mind. Indeed, the worst sorts of projects are those that are established with vaguely defined or fuzzy mandates that permit a wide range of interpretations among members of the project team and parent organization. Projects of this sort are usually foredoomed to spin along out of control as objectives are continually interpreted and reassessed while the budget grows and the estimated completion date slips further and further into the future. One of the most important bits of advice that we habitually offer to organizations that are setting up project teams is to narrow their focus: Make the objectives clear and concise. Indeed, it is usually better to create two separate project teams, each with a smaller set

Page 39 of clearly defined objectives, than load excessively vague or expansive objectives on a single project. The more well-defined the objectives, the clearer are the indications, both internally and externally, that the project team is succeeding. We often find that one of the chief features of projects that continue to function well past the point of serving any reasonable purpose is that they represent those for which the initial objectives have either been altered midstream or were so poorly elucidated when the project began that they provided no guidance for the team.

Uniqueness Projects are usually one-shot propositions; that is, they are nonrecurring and typically established to address a particular problem or market opportunity. Their very uniqueness is the characteristic that underscores the challenge of project management—the learning curve from one project to the next is, at best, tenuous. Once a manager has become part of a functional department concerned, for example, with the production of Brand X, that manager will likely continue facing a series of duties and even problems that can be somewhat anticipated due to past experience with similar products being manufactured using similar techniques. Past experience (either their own or others’) and learning curves will allow that manager to begin to anticipate likely problem areas and points of potential difficulty in the production process. We are able to gain a measure of comfort with the company’s manufacturing activities due to our familiarity with how the process has always operated. The world of project managers is very different. To the extent that we are faced with a unique problem or opportunity, the rules for how the project should be configured and run have not been developed. In effect, we have to learn some lessons as we progress. In learning these lessons and exploring virgin territory, project managers encounter the sort of risks and uncertainty that typify

Page 40 project-based work. It is, however, important to note that a project’s uniqueness may vary to a considerable degree from company to company and project to project. For example, a project team for a computer software manufacturer preparing the fourth modification and reissue of a well-known product will have the experiences of the original development team and the first three modification teams to draw on in setting work schedules and coordinating activities. Certainly, recent demands for new features and changes to hardware technology have to be taken into consideration and represent a source of uniqueness, but the basic project shares common characteristics that limit the risk inherent in new product development.

WHAT IS PROJECT MANAGEMENT? Given the nature and idiosyncrasies of projects, how are we to define project management? Simply put, project management is the application of knowledge, skills, tools, and techniques in order to meet or exceed stakeholder requirements for the project.3 This definition encompasses a number of distinct and often intimidating challenges. The successful management of projects is simultaneously a human and technical challenge, requiring a far-sighted strategic outlook coupled with the flexibility to react to conflicts and trouble areas as they arise on a daily basis. The project managers who are ultimately successful at their profession must learn to deal with and anticipate the constraints on their project team and personal freedom of action while consistently keeping their focus on the ultimate prize. But what is the ultimate objective for project managers? What are the determinants of a successful project and how do they differ from projects that we may rightfully consider to have failed. Our initial definition of projects offers some important clues as to how we should evaluate project team performance. Ask any seasoned project manager and they will usually tell you that a successful project is one

Page 41 that has come in on time, under budget, and performs as expected (conforms to specifications). In fact, this definition is so common, it is usually referred to as the triple constraint of project management. In the last few years, we have seen a reassessment of this traditional model for project success. The old triple constraint is rapidly being replaced by a new model, invoking a fourth hurdle for project success: client satisfaction. Client satisfaction refers to the idea that a project is only successful if it satisfies the needs of its intended user. As a result, client satisfaction places a new and important constraint on project managers who have often heretofore been evaluated through internal measures of success: budget, schedule, and performance. Project managers must now devote additional time and attention to maintaining close ties with and satisfying the demands of external clients (Figure 2.1). Among the implications of this new quadruple constraint is its effect on traditional project management roles. As we will see in a later chapter, concern for the client necessitates that project managers Figure 2.1 The New Quadruple Constraint

Page 42 adopt an outward focus to their efforts. In effect, they must now become not only managers of project activities, but sales representatives for the company to the client base. The product they have to sell is their project. Therefore, if they are to facilitate acceptance of the project and hence, its success, they have to learn how to engage in these marketing duties effectively. When we begin to view project management as a technique for implementing overall corporate strategy, it is clear that the importance of project management and project managers cannot be underestimated.4 Project management becomes a framework for monitoring corporate progress as it further provides a basis on which the skillful manager can control the implementation process. No wonder, then, that there is a growing interest in the project manager’s role within the corporation.

HOW ARE MOST PROJECT TEAMS STRUCTURED AND STAFFED? One of the most intriguing and challenging aspects of project management lies in the relationship of the project team to the rest of the parent organization. With the exception of companies that are set up with matrix or project structures, the majority of organizations using project management techniques employ some form of a standard functional structure. As Figure 2.2 shows, within the classic Figure 2.2 Functional Organization

Page 43 functional structure, departments are organized in accordance with functional roles: marketing, finance, R&D, production, and so forth. Most activities and operations occur within these functional groupings. Further, as we intimated earlier, these functional duties are often on-going and act as necessary parts of the organization’s activities. For example, the manager of new business development within the marketing department of a firm doing business with the federal government would be concerned with determining what programs his company will bid, what price he can offer, and the sort of product attributes he can reasonably deliver as part of those bids. In essence, no matter what program he is bidding on, this activity comprises the manager’s full-time job and will continue on indefinitely, as long as he works for the company and as long as the company remains in business. When project teams are added to an organization, the structural rules change dramatically. Figure 2.3 demonstrates the same simplified functional structure in which project teams have been overlaid. Note the inclusion of the doted lines from the functional departments of finance, R&D, marketing, and production. When Figure 2.3 Functional Organization with Project Teams

Page 44 project teams are formed in most organizations that possess functional structures, they are staffed on an ad hoc basis from members of the various departments. These personnel are assigned to project teams through one of several ways: their services are expressly requested by a project manager who values their competence, they are ‘‘exiled” to the project team by a functional boss who is dissatisfied with their work, or they are assigned simply because they are available. The key, however, is that these assignments, like the projects themselves, are temporary. Personnel who staff the vast majority of project teams serve on those teams while maintaining links back to their functional departments. In fact, it is quite common for these individuals to split their time between their project and functional duties. Not surprisingly, this arrangement can lead to a great deal of internal conflict when each member of the project team seeks to create a workable balance between the competing demands of functional and project team superiors. The temporary nature of projects, coupled with the very real limitations on their power and discretion that most project managers face, constitutes the core challenge of managing projects effectively. Table 2.1 gives a comparative breakdown of some of the important distinctions between project-based work and more common department activities. It is clear that the very issues that characterize projects as distinct from department work also illustrate the added complexity and difficulties they create for project managers. For example, within a department, it is common to find people with a more homogenous background; that is, the finance department is staffed with finance people, the marketing department is made up of marketers, and so on. On the other hand, most projects are constructed from special, cross-functional teams. These teams are composed of representatives from each of the relevant departments and they each bring their own attitudes, time frames, learning, past experiences, and biases to the team.

Page 45 Table 2.1 Differences between Department and Project Management Department

Project

Repeat process or product

New process or product

Several objectives

One objective

On-going

One shot—limited life

People are homogeneous

More heterogeneous

Well established systems in place to integrate efforts

Systems must be created to integrate efforts

Higher certainty of performance, cost, schedule

Higher uncertainty of performance, cost, schedule

Part of line organization

Outside of line organization

Bastions of established practice

Violates established practice

Supports status quo

Upsets status quo

Source: R.J. Graham. (1989). Project Management as if People Mattered. BalaCynwyd, PA: Primavera Press.

Creating a cohesive and potent team with this level of heterogeneity presents a challenge for even the most seasoned and skilled project managers. Likewise, functional activities are intended to reinforce the organizational status quo, the standard operating procedures that are clearly documented in most companies. Project management work is different. As Figure 2.3 demonstrated, project teams operate at the periphery of the organization, pulling human, technical, and monetary resources away from the functional areas for their own needs. Rarely are there manuals written on how these project teams are expected to operate. Rather, much of project management involves “violating” rules such as the manner in which members of different functional departments are expected to communicate, the way additional resources are secured, close interaction with clients by all members of the project team, and so forth. It is in violating these

Page 46 standard operating procedures that project teams are most effective, operating in a flexible and responsive manner to a variety of both internal and external client demands.

WHAT IS A PROJECT EXECUTION PLAN? Before any product ends up in the hands of a customer, it has gone through a process that involves a varying number of engineering, purchasing, manufacturing, and distribution phases. At the same time, project documentation, used to support the project’s development, may vary dramatically in terms of sophistication, depending on how new the technology or complexity of a project. The more routine the project and the lower its developmental uncertainty, the better it is typically documented. A supply chain for a highly certain, or mass-produced technology project may involve rooms full of procedures and a huge supporting documentation needed to design the product and ensure that the production process produces products that meet all technical specifications and are of the specified quality. At the other end of the scale, the plans and procedures that are needed to implement a simple phase of a construction project, carried out by a subcontractor, might be described on one page. Or, in the cases where the technology is uncertain, documentation may also be little more than a general conceptual statement identifying the broad goals we seek in developing a new product. What many companies are increasingly turning to is a method to more formally document their procedures and protocols, using a project execution plan (PEP). The PEP can be composed in different ways. One way involves categorizing the three main building blocks of the plan and identifying them as company procedures, standard project management procedures, and project specific plans (see Figure 2.4).

Page 47 Figure 2.4 What Is a Project Execution Plan?

The PEP is based on a cascading set of planning tools that vary according to the degree our organization is comfortable with managing projects. At one extreme are companies in which project management is so imbued that the entire process is formalized to a great degree (resulting in project documentation being a formal part of company procedures). On the other extreme are organizations where each project is unique and calls for a unique development model (the project specific plans). As we noted, project specific plans are a function of necessity, either due to the complexity and uniqueness of the project in development or our firm’s unfamiliarity with project management in general. Most PEPs are some combination of all three substantive layers: project specific plans, standard project management procedures, and company procedures. Uniquely recombined for each new project, due to the unique nature of our projects, these layers form the basis for developing the supporting documentation that is a Project Execution Plan. The degree to which project plans are formalized is often a reflection of the technological and project-based sophistication of the

Page 48 organization developing the product. If a project is carried out in a mature organization using mainly its own resources, the project execution plan will typically contain the standard procedures that are established in the organization. In other words, the project plan is based on a formalized and wellestablished procedure. For example, General Electric (GE) takes great pains to establish a series of project evaluation points, called gates, at different points in the development process. Only projects that have successfully passed through the various gates will be considered for development. GE has managed to establish well-documented procedures to support (or kill) projects during their initial development phase when they require heavy scrutiny. In circumstances where the organization employs a mature and documented approach to project development, the portion of the project specific plans can be relatively small. Consequently, when a company attempts to sell its project management procedures to a potential customer, they have only to demonstrate their formal processes. Boeing, for example, goes to great length to standardize development policies to ensure that projects developed around the corporation follow standard protocols. In the customer’s eyes, therefore, the real issues for evaluation lie in the company procedures and standard project management procedures that the contractor can demonstrate. The logic here is that the more standardized the process is, the less there is need for project specific plans, which usually means a greater proven track record of past project implementation and less risk to the customer. In today’s world, however, it is very seldom possible to win a major project contract and implement it just by evaluating a vendors’ standard operating procedures only. To be successful in today’s competitive international project business, the contractors need to master a combination of low cost and great flexibility that is usually achieved by significant utilization of an external supplier network.

Page 49 Managing a business model that is based on using a great number of outside suppliers creates a work environment that rapidly becomes complicated. In dealing with various kind of organizations that may be located in different parts of the world, we are confronting significant differences in culture and the way they may prefer doing business. With this approach, we are facing two main challenges: Given the risks involved in project development, how are we able to sell our project implementation model to the customer, and how are we able to actually manage the process after winning the contract so that the relationship is profitable to both parties. Basing our project business on a networking approach calls for a tool that brings the whole delivery system together, organizes and describes it in a form that is understandable to ourselves and to our external and internal project stakeholders. In the model we are presenting here, the project execution plan is such a tool. Our model of the execution plan (Figure 2.5) for managing supply chain based projects is based on the concept of Project Management Plan (PMP) introduced by Pells.5 This is a combination of two plans that are traditionally prepared separately: the management plan that describes the operational management system, and the project Figure 2.5 Project Execution Plan

Page 50 plan that incorporates the work breakdown structure, schedules, and cost estimates. The project execution plan has both internal and external communication functions. Internally it will communicate to the project team, the firm management, and the other functions in the company how the delivery system of a particular project is expected to work. Externally it will communicate to the customer the process that the contractor has assumed for the project implementation in the bidding phase. Typically changes that are made to these assumptions during the project will cause changes to the usage of materials, the amount of work, possible rework, or out-of-sequence work. In other words, these changes will have a cost and schedule impact. Well-defined project execution plans will help the customer and the contractor, as well as the contractor and the suppliers, respectively, to understand and agree to the change orders as the project progresses. Further, toward any third-party project stakeholders, the project execution plan will serve as a description of the project implementation process, helping them to understand what we are planning to do, permitting activities to proceed more smoothly. For example, projects initiated by the Department of the Interior often include very detailed specifications for external consumption (the public) because so many interest groups have a strong interest in environmental issues. In the sales phase of a project, one important function of the project execution plan is to differentiate the contractor from the competition at the marketplace. It offers a framework for introducing the contractor as a firm, as a project manager, and as a delivery system provider for a particular project. In our approach, the purpose of the project execution plan is to facilitate internal and external communication during all phases of the project. It has to capture the important aspects of the project at an early phase and document them into a set of structured plans that are organized in a book or a series of books. These include definition of

Page 51 the project mission and goals covering the health, safety, and environment (HSE) objectives, quality assurance and quality control objectives, as well as other project objectives. Furthermore, the project execution plan defines the scope of work, design and planning basis, and describes the key project execution processes and key procedures applied to the project. Figure 2.6 gives a sense of some of the key descriptive information that effective PEPs often contain. The PEP also demonstrates to the customer how the contractor will deliver a competitive product based on a delivery system consisting of well-planned, low risk, and the cost-efficient implementation of engineering, purchasing, construction, and distribution of the final product. The project execution plan enables the customer to assess the project risks based on reliable information about the implementation. This facilitates the customer adding only a minimum contingency on top of the contractor’s price to cover his own risk and Figure 2.6 Project Execution Plan Description

Page 52 to come up with the lowest possible risk weighted cost in his cost estimate. In the customer’s bid evaluation process, this is the level where the competition between different contractors usually takes place. During the project implementation phase, the project execution plan will become a framework for the development of the final, detailed set of updated procedures and plans for the project implementation. For the project team, it will be the project handbook pulling together the necessary key information concerning the project implementation. In the end the project execution plan will display how the project was actually implemented forming a good basis for the learning and continuous improvement process.

HOW TO COMPOSE A PROJECT EXECUTION PLAN Sometimes the PEP is something that the project manager, or a few key individuals on the project team, puts together because this document is requested by the customer or required in order to conform to internal company procedures. We are proposing another kind of approach. We argue that to contain real substance, the PEP has to be produced by the organization, the entities and individuals who are actually responsible for implementing the project activities. This would include both your own organization and your supply chain. Naturally, the problem here is that typically the key individuals in these organizations may feel that they do not have time because they have many other important duties associated with running their day-to-day business. This sets a clear resource requirement to support your approach. You need to set up a system that facilitates composing the PEP promptly without overloading the project organization too much. Before taking the first step, a clear analysis concerning why you are about to start setting up a new system has to be carried out. Like many other project-related activities, this effort is not likely to

Page 53 Figure 2.7 How to Compose a Project Execution Plan

be very successful if you do not have both the support from the firm’s upper management and the buyin from the organization. In the case of the supply chain-based project business, the situation gets even more complicated because it is imperative to have the support and buy-in, not only from your own organization, but also from your supply-chain network. That is why a mission and a set of clear objectives that are based on thorough understanding of the situation at the marketplace, in your own organization, and in your supply chain, is very important for the success of your effort. In our model, the process of setting up a system for producing the project execution plans involves the following phases (Figure 2.7):

Page 54 l l l l l l

Defining mission and objectives Identifying the contents and format of the plan Writing the instructions of how to compose the plan Developing the document control procedure for the plan Organizing the training Consolidating the procedure as a part of the QA system of our company

As we further refine and develop these activities, it is often useful to run them first in a beta-test format using a pilot project in order to generate a deeper understanding of the nature of the task in hand. The pilot project makes it possible for us to test what works and what does not within our own organization, with the supply chain network, and most importantly with our customers. Doing a project execution plan correctly represents a great challenge and should not be undertaken lightly. We have the opportunity to create a business process that is expected to demonstrate to prospective customers, in great detail, the nature of the project delivery system we employ, the products we produce, the manner in which we can create value for the customer, and how we manage our supply chain throughout project development. Done correctly, the PEP offers customers a clear window into our operations, demonstrating our project development expertise in such a way that it is going to reduce their perceived risk in selecting our firm as a contractor. Done incorrectly, or with less than full attention to detail, the PEP can backfire: demonstrating our lack of expertise to potential clients. This means that we have to ensure that the system we are composing actually fits for our purpose and meets our goals. Before we enter into the pilot project, we have to do our homework carefully. We need to have our mission and goals well defined and we also need to have the first revision of the contents and the format of our plan figured out. At this point these do not have to be perfect; we understand that some changes are going to take place

Page 55 following the feedback that we will get. However, we have to keep in mind that the pilot project is going to involve our key future project stakeholders, including our customer, and it is important that they get a favorable impression about what we are trying to accomplish. At this phase, we cannot afford to lose the credibility of our program. The great strength in using the pilot project is that testing the system at the field in its early phase will provide faster and better results than trying to conduct a series of almost infinite fine-tunings from behind the desk. We can learn far more from actually observing the project in the field than we ever can hope to know about it from viewing a series of drawings and specifications. When beta-testing the project through a PEP, however, it is vital that we pay attention to organizing an efficient system for gathering and utilizing the feedback. One of the big mistakes we routinely witness comes from firms who devote enormous resources to the planning of projects and almost nothing to creating a feedback system to allow for organization-wide learning. This is a factor that in the end will help us to consolidate the lasting substance of our plan and enable the necessary buy-in from the whole supply chain organization to occur. Several good frameworks for the contents of the project execution plan can be found in the project management literature.6 Modifying these to fit our intended purpose is often the easiest way of getting started. Another way is to compose the elements of the plan without any template by starting from the needs of the particular case. There is, however, quite a lot of thinking and cumulative experience incorporated into the standard templates published in the literature by different writers that makes them definitely worth considering. Furthermore, these templates include detailed descriptions of the write-ups under the different subtitles, helping the person responsible for composing the document to stay focused. This is especially important when incorporating the comments and change proposals that are coming from the different project stakeholders into the main framework. Remember that the goal is to

Page 56 create a new firm procedure that will later be routinely used by large numbers of people in the supply chain leading to a direct positive effect on the productivity of their everyday work. The effort needed to come up with a well-functioning PEP should not be underestimated. It is the framework for structuring the information presented in our plan and will have a great impact both to the usefulness of the final document and the efficiency of the process of composing it. After all necessary parties have agreed to the contents, it will be easier to come up with the format for the PEP document itself. In works of this kind, simple usually works better than complicated; after all, substance of the information in the document itself is more important than the format. Typically there is certain information that is useful to include in the document, such as: l l l l l l

Project number Customer name and project number Date and revision number Name of the person responsible for composing the information Discipline check and approval Clear identification of each page (volume name and number, section number, etc.)

In developing a PEP that will be an effective tool in our supply chain management tool kit, it makes sense to split the main document into several smaller independent sections. One practical way of doing this is to define the work breakdown structure (WBS) of the document to reflect the split of responsibilities between different parties involved in our supply chain. Different suppliers can be assigned responsibility for composing their own part of the plan. In the end, the separate documents come together to form the final comprehensive document. To a certain extent, this approach is always a compromise between the absolutely fluent readability of the

Page 57 document and the productivity of the process of putting it together. However, clear logic, the right kind of standard format, and good discipline and QA in composing the document, along with good quality information, will help to compensate for the possible losses of readability. After all, although intended to communicate our project implementation-related intentions to the customer in the sales phase, the project execution plan is still more a procedures handbook than a clean sales document. The pilot project is our prototype. We expect that even significant changes might take place in our process based on the feedback we will get from the project stakeholders. Build up to speed slowly. This means that it most likely is not a good idea to test the new system the first time in a large project with our most important customer. In the best case, the pilot project should be manageable in all respects and with a customer that understands and appreciates what we are trying to do. The project manager and the core team should also be fully committed to make the system work, understanding that they will have to do extra work in launching the system into the supply chain. Furthermore, there should preferably be some extra time and money reserved in the project budget for launching the new system. On the other hand, we very seldom have the luxury of dealing with an optimum situation. Depending on our situation, launching the new system might be necessary just to achieve a productivity gain in our project implementation process. In this case, no extra time or money is available but we actually are forced to gain some savings by employing the new system. This is to a great extent a case-by-case consideration. To be able to start with a new system, we need an instruction book. If the structure of our plan is close to some standard that has been taken from the literature, it is relatively easy to write the instructions. In this case, we may only need to add or modify the subtitles and sections to fit the standard plan to our particular purpose.

Page 58 We have to make sure that these fit to all, or at least most of our projects and are not typical just for the selected pilot project. A description of the contents of all sections of the plan is necessary because all people do not understand the short titles the same way. If there is misunderstanding, our plan may evolve from project to project and is soon something other than what was originally intended. The instructions also should be composed so that they highlight the importance of a short text form. Put another way, writing discipline is required as the plan evolves. We need to exercise judgment in keeping the textual material short and to the point. Typically the problem in the beginning is that the plan seems to be too thin. However, what actually happens over the course of the time is that it becomes too thick, containing nonessential information inherited from the plans of the earlier projects. The basic reason for gaining productivity through composing the project execution plan is that the work that is done for one project can be utilized to the maximum extent in the projects that will follow. This means that the document control system and database that we establish is bound to facilitate the easy use of the existing write-ups and other information that go into the plan for all the people who are expected to contribute in putting the plan together. This includes the format, as well as coding and filing of the pieces of information. When composing the PEP, some information can be copied from earlier projects, some information has to be modified, and some has to be composed specifically for each project. There is a tendency to overshoot the productivity. This means that the amount of information copied from one project to another easily starts to grow unnecessarily large or complex, actually lowering the quality of the final plan. From this point of view it is necessary to organize a QA function that guards the quality of the document and the information that goes into the different plans in it making sure that the end result always meets the targets that have been set for each project. Our final goal is to describe the process of composing

Page 59 the project execution plan as a standard company procedure that is incorporated into our QA system. However, developed procedures, no matter how carefully devised and controlled, do not ensure that the tool works. As the final step of our program, the potential users of our system both in our own organization and in our supply chain have to be trained to use the system. In the following chapters, we will continue to explore in depth our understanding of customer-based project management. This chapter provided a basic understanding of some of the unique characteristics of the project management process and the roles they will be assuming. Now, with the stage set, the balance of this book will continue exploring the processes companies must develop to become attuned to the needs of their customer base. Successful project management becomes successful customer management.

NOTES 1. Project Management Body of Knowledge (PMBOK). (1994). Upper Darby, PA: Project Management Institute, p. 2. 2. David I. Cleland and Harold Kerzner. (1985). A Project Management Dictionary of Terms. New York: Van Nostrand Reinhold, p. 199. 3. See note 1, p. 3. 4. J.M. Bryson and P. Bromiley. (1993). ‘‘Critical Factors Affecting the Planning and Implementation of Major Projects,” Strategic Management Journal, 14, 319–337; and M.A. Lord. (1993). “Implementing Strategy through Project Management,” Long Range Planning, 26, 76–88. 5. D. Pells. (1993). “Project Management Plans: An Approach to Comprehensive Planning for Complex Projects,” in P. Dinsmore, ed., The AMA Handbook of Project Management. New York, Amacom, p. 143–164. 6. Ibid.

Page 60


Page 61

CHAPTER THREE WHAT IS PROJECT SUCCESS AND FAILURE? Before offering advice on how to better manage projects, we must first state, as precisely as possible, how we intend to evaluate and classify project outcomes. This process is by no means simple; as we show in this chapter, project success or failure, is often in the eye of the beholder. Until we can establish a set of criteria that have some generally accepted basis for assessing projects, at best we run the risk of mislabeling as successes projects that may ultimately be judged failures. In this chapter, we develop a generally accepted guideline by which project success and failure can be judged. We recognize that it may be difficult for all readers to completely agree with our criteria, as the subject lends itself to a certain degree of passion, particularly among those who have, like ourselves, worked on failed projects in the past.

THE UNIQUE SETTING OF PROJECT MANAGEMENT In the first chapter, we defined projects as the “engines of growth” for most corporations. We suggested that almost all innovative new

Page 62 products developed within companies arise through the creation of projects and the use of project management techniques. Because projects play an increasingly significant role in organizational profitability, it is vital that we develop an understanding of their unique properties: What is it about the nature of project management that gives it such a preeminent role? The answer to this question can be made partially clear by demonstrating the position that projects, particularly new product development projects, occupy in our organizations. The global economy, coupled with rapid product obsolescence and shrinking development budgets, necessitates a level of competition that is becoming increasingly frenetic. Within many hardware and software computer manufacturers, for example, product life cycles have shrunk to mere months—a far cry from two decades ago when the IBM personal computer was the industry standard for nearly five years! Coupled with this increased competition is the concomitant demand for innovation as companies vie for transitory market dominance. The most obvious method for leading the field in a new market opportunity lies in rapid product development. Hence the need for professional and competent project management practices. Project management offers a number of advantages to companies but it also creates a series of special challenges. For example, typical new product development lies outside the realm of traditional departmental budgeting and control practices. Upper management is often forced to stake tremendous amounts of capital and other resources on merely the promise of a good idea, in the hope that an innovative product will eventually emerge. Consequently, with many large projects, initial budgets and schedules comprise best guesses as to the most likely costs to be incurred. It is no wonder then that we continually read about projects saddled with runaway budgets and sliding schedules as initial plans meet hard reality.

Page 63 The lines of responsibility for project development present another difficulty within the project management context. Most projects are staffed with personnel borrowed (sometimes on an extended basis) from their line departments. A project manager faces the unique and vexing challenge of attempting to motivate and secure the commitment of a disparate group of functional employees who often feel little personal identification with the project and preserve a profound functional loyalty. This problem is further exacerbated when the project managers do not have the freedom to perform formal performance appraisals on these temporary employees. When set against this unique backdrop, project control becomes increasingly problematic. The irony is that most organizations, including those that have experienced terrible difficulties with their projects, will readily acknowledge the necessity of using project management in their operations. What is particularly frustrating to them is that they continue (seemingly) to make the same mistakes again and again as one project after another falls further and further behind, goes increasingly over budget and then is either canceled outright or simply slides into oblivion. Or, the project is finished and transferred to a customer who no longer wants it or is expecting something so different from the finished output that it is useless to them. In our experience, the problems that underscore such shaky track records are usually legion; however, one common denominator shared by most troubled organizations is their unwillingness or inability to learn from past failure. Project review meetings, so important as a learning tool, are either perfunctory (in the case of successes) or are ignored (in the case of failures). This is a pity and it is with this message in mind that we have developed our program of customer-based project management as detailed throughout this book. We are convinced that the more we are willing to look at a project’s status from the perspective of the customer, the greater the likelihood that the finished product will be both used and useful. It is our hope that each of us is strong enough

Page 64 to recognize the dross of common experience as readily as we are to claim the laurels of success.

DETERMINING SUCCESS AND FAILURE It is, perhaps, ironic that attempts to label projects as successes or failures often poses considerable difficulty. Part of the problem is that while everyone seems to understand intuitively the various component measures of project success or failure, agreement with how to assess various projects in light of these criteria is often problematic. Some of the most impassioned arguments we have received from both project managers and customer organizations in our consulting and professional careers have come about as a result of our suggesting a specific project with which they were associated “failed.” This response is completely understandable in that project managers’ careers often hinge on their ability to “deliver the goods’’ in the form of successfully completed projects. Likewise, no customer wants to admit that it accepted a project that was ultimately useless to them. Consequently, it is axiomatic that, in the absence of dramatic disaster (e.g., structural collapse in construction or banned or abandoned pharmaceutical development), for every detractor of a specific completed project there is a champion singing its praises. How is this possible? How is it that two equally capable individuals can often view the same results through entirely different frames of reference and make completely opposite conclusions about a project? Part of the answer lies in the notion that project success is not always as clear-cut as we would sometimes believe. Any one of a number of confounding issues can cloud our ability to view a project’s outcome in an objective light. For example, when a project is evaluated can make a very real difference. Likewise, egos and personal agendas of top managers across organizations can obscure

Page 65 the true outcome of a project, if these powerful individuals seek to protect themselves and their turf from the side-effects of less-than-successful projects. Finally, while successful projects are trumpeted throughout the organization and publicized externally, the majority of project failures are quietly swept under the carpet. People naturally tend to promote the positive. Where this is not possible, people adopt a simple philosophy: Out of sight, out of mind. The irony is that all organizations experience project failure far more often than rousing success. Consider, for example, the results of a recent study by Peat Marwick of 300 large companies attempting to implement computer software development projects. Fully 65 percent of the organizations reported experiences where their projects were grossly over budget, far behind schedule, and/or the technology was nonperforming, leading to “runaway” projects. In some cases, the companies experienced all of the above! Perhaps more impressively, over half of these firms considered this state as “normal” or “of no concern.”1 Because of the confusion surrounding the meaning of project success, before we can begin making meaningful observations about the success or failure of a particular project, we need to develop, as systematically as possible, a working definition of project success (and by default, failure). We are under no illusions that this exercise will encompass the various views and arguments of all readers. Nevertheless, such a framework will at least allow us to develop a foundation on which to build the arguments we intend to advance while illustrating the various and distinct ways in which projects can fail. What, then, is an appropriate definition of project success? In the old days, project managers commonly made use of a concept known as the triple constraint to evaluate a completed project. This triple constraint offered a three-legged stool for any project’s viability. The three constraints were: (1) time—the project had to come in on or under its initially scheduled timeframe, (2) money—the project had

Page 66 to be completed within its budget limits, and (3) performance—the end result had to perform in the manner that was intended. Seen in this light, it was relatively easy to make some initial value judgments about any project. We had only to consult the project’s timeline to assess schedule constancy, review the cost accountant’s report to determine budget adherence, and see if the project ‘‘worked” to measure performance. Unfortunately, the triple constraint is too simplistic in the modern business world. In an era of tremendous competition and enhanced concern for customers, the triple constraint has become, in fact, a dangerously out-of-date convention. In considering the three components of the triple constraint, it is clear that the primary thrust of each of these measures is internal; that is, they are intended to satisfy some interest group internal to the organization rather than in the environment. For example, satisfying time and budget considerations are often the concern of cost accountants who are tasked with keeping costs down. Likewise, the performance criterion has often been seen as primarily an engineering concern: the challenge of making a product that works. What was lost was any real concern for the customer; that is, the desire to satisfy the concerns of the client for whom the project was intended. Within many companies with which we have worked or consulted, a fundamental conceit that emerged was the assumption that once a project was completed, the public was offered something that they would naturally buy or use. The underlying theme of this position seemed to be an arrogant assertion: Don’t tell us what you need. Trust us to know what you need. The result of such attitudes was predictable: Customers went increasingly to companies whose projects and products reflected a concern for the customer, as illustrated by the phenomenal success of the Ford Taurus. The Ford Motor Company faced a number of problems by the end of the 1970s. Poor quality, antiquated and traditional designs,

Page 67 and a shrinking customer base resulting from foreign competition were all serious hurdles in the path of future success. In a radical departure from past convention, Ford sought to better understand the causes of their difficulties. They initiated a series of structured interviews with former Ford owners who had since purchased competitors’ products, they held brainstorming sessions with suppliers and retailers, and worked to involve customers in the design of the next generation of automobile. The resulting new design for the Ford Taurus reflected both a radical departure in car design as well as a redirection for the company and the way it operated. The driving factor behind the success of Ford in the following decades was the reestablishment of their connection to their customer base. The new rules governing global business in the 1980s and 1990s require that project management adopt a new standard by which to measure success: the quadruple constraint. The additional feature of the quadruple constraint requires us to include customer satisfaction as one of the pillars of project success. Customer satisfaction means that a project is only successful if it satisfies the needs of its intended user. This addition has tremendous implications for the way we manage projects and the manner in which the success or failure of both past and future projects will be assessed. With the inclusion of customer satisfaction as a fourth constraint, project managers must now devote additional time and attention to maintaining close ties with and satisfying the demands of external clients— customers. Among the implications of this new quadruple constraint is its effect on what were viewed as traditional project management roles. Concern for the client necessitates that project managers adopt an outward focus to their efforts. In effect, they must now become not only managers of project activities, but sales representatives for the company to the client base. The product they have to sell is their

Page 68 project. Therefore, if they are to facilitate acceptance of the project and hence its success, they have to learn how to engage in these marketing duties effectively.

THE ASSESSMENT OF SUCCESS OVER TIME One frequent error that many organizations slip into when assessing the performance of their project development is to make inadequate allowances for the impact of time on a project’s viability. To illustrate, consider a real-life situation in which a company was determining the success of a recently completed hardware computer development project. Based on internal cost accounting data, the project looked good: It had come in on time and only slightly over budget. Further, the hardware performed as it was intended to perform. As a result, the project manager was given a performance bonus and reassignment for a job well done. Unfortunately, the story does not end there. The project, while internally efficient, was a disaster in the marketplace from its first introduction. The technology that the company had assumed would be adequate, turned out to be so user unfriendly that the product was withdrawn within nine months. This story illustrates a number of the problems we face in studying the causes of failure. First, this project was not seen as a failure at all; in fact, just the opposite. The second problem had to do with the incomplete picture of project expectations that top management painted. Obviously, client satisfaction was never a concern of the project manager who naturally, devoted his time to the measures that did matter for his performance appraisal: schedule, budget, and performance. Finally, this story demonstrates a subtler third point: It is important, in the absence of full information, not to assume that a project is a success or failure too early in its life, before the final returns have had an opportunity to come in.

Page 69 We do not only mean to suggest that many projects deemed successes are, in fact, failures. The reverse is also true: Many projects that give every evidence of being instant failures may actually demonstrate themselves to be long-term successes. One example that comes immediately to mind is the well-known English Channel tunnel project, known as the Eurotunnel, or Chunnel. Opening in 1994, nearly 18 months behind schedule (late enough to miss the vital summer traffic season), the Chunnel project was originally budgeted for 7.5 billion pounds. The final bill, at 15 billion pounds, was more than twice the initial projection. From an internal auditing perspective, the Chunnel represented a financial nightmare, particularly when it defaulted on the bond financing made by the initial investors in the venture. Nevertheless, looking at the project in regard to its long-term potential, we must admit that its contribution to society may be significant; in effect, leaving the judgment of project success or failure in the hands of future generations. This case illustrates a central idea regarding project success and failure: the importance of balancing immediate assessment against long-term project viability. Clearly, there are definite benefits involved in waiting until after the project has been completed and is introduced to its intended clients before assessing the success and impact of the system. On the other hand, we must be careful in not waiting so long to determine a project’s external impact that the possibility exists of other organizational or external environmental factors influencing the organization’s operations to the point where we are unable to determine the relative impact of the project in the marketplace. For example, in the field of computer hardware development, product launch windows are often calculated in terms of months; either a computer is introduced during a favorable launch period or that company will be so far behind the technology and marketing curve that they may just as well not bother with the project at all. In this hyper-shortened timeframe, a successful project is

Page 70 assessed within months of its introduction. In contrast, the viability of Denver’s new International Airport may not become clear until years into the future. In the meantime, a number of factors external to the project itself (e.g., the price of jet fuel, profitability of major airlines, or demographic patterns within the city itself) will either elevate the airport project to dramatic success or condemn it to white elephant status. Figure 3.1 illustrates the difficulty faced by project managers and their organizations.2 This figure shows a simple time line, demonstrating the point at which various aspects of project success can be evaluated. At the earlier stages in the implementation process, the typical assessments of success tend to revolve around those previously mentioned internal organizational factors, such as adherence to budget and schedule, performance capabilities, project team cooperation and productivity, and project team-parent organization relationships. The loop in the system represents the instance or instances when periodic assessments of these internal Figure 3.1 Assessment of Project Impact over Time Installation

Page 71 criteria are made. If major discrepancies exist in any of these criteria, quite often the project development effort is extended, reconsidered, rebudgeted, or sometimes, even scrapped. About midpoint in the time line is the point of project transfer. At this stage, a number of projections regarding the project’s success are being made. The project is examined in terms of its technical capabilities— Have prototype results been satisfactory? Where appropriate, are the beta test site findings promising? While performance capabilities will become and remain very important, some other traditional measures of internal success become less so. For example, by this point, marketing and/or project transfer and installation schedules have been completed. The scheduling that remains pertains largely to client training and, if necessary, bringing additional features online. Further, the majority of the budget has already been expended at this stage. On the other hand, the issue of client acceptance and use continues to become of greater and greater importance now that the project has been completed, put in the marketplace, or handed over to its prospective users, and is up and running. As the time line continues to the right, it becomes progressively hazier, symbolizing the increasing difficulty in accurately measuring project success based on concepts such as client impact and their perceived value of the project. Because the project has been completed and for all intents and purposes is beyond the control of the developing organization, its fate resides with the company’s ability to have accurately gauged the public’s desire for the project. Consequently, external issues such as the state of the economy and changes in customer needs and tastes will continually impact the completed project. As an end result, sometimes the project will initially be hailed as an important breakthrough and down the road suddenly become both obsolete and an expensive, embarrassing failure (the Ford Edsel). On the other hand, some projects that were regarded early on as a waste

Page 72 of money or worse, may now be viewed as being very important to the organization and be considered successes. Figure 3.1 suggests that while periodic assessments of the current state of the completed project are important, an accurate determination of the ultimate success or failure of a project is equally critical. The difficulty lies in attempting to find a suitable reference point, at which time the project has been completed, transferred to the clients, and is having some initial impact in the marketplace. One of the important benefits of using such a postcompletion project assessment is that it drives home the point to many project managers that their duty to the project does not end when it is completed from an internal evaluation perspective. In fact, in most instances, there is still much hard work ahead. Project managers and their organizations can foreshorten some of their time with postcompletion client involvement depending on the degree to which they and other relevant project team members consulted with clients at various earlier stages in the development process. However, an accurate determination of the ultimate success or failure of any project largely rests with the key external factors: the client and their use and satisfaction with the project. The main point underlying this position has to do with the organization’s desire to fulfill the client’s needs: matching the project to the client rather than attempting to alter the client’s perception of their needs to fit the completed project. It behooves project managers to spend sufficient time in postintroduction activities to better assess the true success or failure of the project. It is ironic to consider that many times, a key for achieving project success is to simply avoid the obvious pitfalls of failure; that is, the ability to recognize the various traps that snare numerous projects along the way is a principle ingredient in project success. Causes of project failure come in many forms, including: insisting on perfection, adopting the myth of standard controls, infatuation

Page 73 with procedures, poor contract documents, and blaming outsiders for our troubles.3 Learn to avoid these common sources of project difficulties as a necessary first step toward steering the project to a successful conclusion.

POINTS TO REMEMBER In this chapter, we highlighted a number of salient issues that managers need to consider when attempting any sort of system implementation assessment, including: l

Balance cost consciousness with project performance. There is sometimes a strong temptation to come down on either side of the cost/performance argument, usually with questionable results. For example, organizations that build projects at any cost because they are enamored of technology for its own sake inevitably run into trouble with project financing. We cannot continue to pour money down the gaping hole of a project run out of control. On the other hand, when project development is left in the hands of the accountant (i.e., project decisions are ultimately made almost solely on the merits of cost), we run the equally unpalatable risk of stifling crucial creativity and long-term innovation, all in the name of immediate capital constraints. Clearly, a middle ground is needed—somewhere between the excessive controls of cost accounting and the anything-goes mentality of those who would tinker with technology just for its own sake. This conclusion forces management to adopt some decision rules for new product development that leave the project team free to ensure that performance is top-notch while at the same time ensuring that the team does more than simply pay lip-service to cost constraints.

Page 74 To illustrate, consider the true case of a large, international corporation whose forestry division worked to develop a state-of-the-art loader for timberland clearing. Because the organization was dominated by its engineering function, the project continued to run high deficits against the original budget as the engineers worked to get the technology right. Unfortunately, while the project was introduced (moderately late and over budget) as a technological masterpiece, it is now showing the telltale warning signs of overdevelopment. For example, one of the primary markets for the loader is in the forests of Indonesia. Unfortunately, the loader, equipped with state-of-the-art gadgetry such as LCD monitors and other computer readouts, is unsuitable for the rugged treatment it would receive in the Indonesian forests. Often situated hundreds of miles from the nearest servicing center, the forestry industry needs equipment that is rugged and basic, rather than leading-edge and high-tech. As one engineer ruefully admitted, “They needed a Chevy and we built them a Rolls Royce.” Hence, a technological marvel in the hands of the developing engineers runs the risk of mediocre sales in the marketplace. l

Do not be too hasty to judge a project as a success or a failure. It is the rare project that is correctly judged to be a success or failure immediately following its introduction. The cost accountant may endorse a project’s development process as being within budget and schedule constraints. Likewise, our organizations may have positive feelings about a project’s viability in the marketplace, but only time will tell the true story. In reality, many current projects cannot do more than offer imprecise evidence of their future success at the time of their introduction. We must make a serious evaluation of the project manager’s role based on a project’s future expectations. To what set of criteria is it appropriate to hold project managers in evaluating their performance? We argue that rewarding a

Page 75

l

project manager on the basis of adherence to the internally focused triple constraint is inadequate and, in fact, likely to send the exact wrong message to those running current development projects. On the other hand, it may be highly unfair to hold project managers to a standard that is beyond their control (e.g., the future stream of profits for a project with a 10- or 20-year market cycle). Some middle ground is necessary between the equally misleading guidelines of short-term development and long-term profitability. Companies that are intent on making their evaluations on as clear a set of data as possible must look for methods to evaluate client satisfaction, acceptance, and use of new project offerings in conjunction with the traditional measures of performance, schedule, and budget. Project managers need to be aware of the standards that the organization holds with regard to its evaluation criteria so they are willing and even eager to make the investment in client consultation and project marketing that are so important to ultimate project success. Products or projects must be used to be successful. One of the most important points that past research and experience has taught us is that the client is the ultimate determinant of successful project implementation. This lesson, seemingly so fundamental, is one that nevertheless must be continually relearned by many of our organizations, both large and small. As long as our gaze remains firmly fixed on the internal criteria for project success, the triple constraint, we will never achieve the full measure of the project success. We live in a culture that is fascinated with the latest technological advances. Organizations that are dominated by their engineering departments are particularly vulnerable to this bias. The prevailing assumption that one has only to build the latest design with the hottest component properties to ensure client acceptance, use, and subsequent project success is a conceit our

Page 76

l

companies can no longer afford to reinforce. Where Marketing and Customer Service are relegated to supporting cast roles, we will simply recycle the same mistakes again and again. In our drive to innovate, there is a very real danger that we will continue to pursue technology for technology’s sake, rather than working to create projects that have practical and useful features. The oft-repeated statement, ‘‘Of course, it will be used—it’s state of the art!” reveals a high level of naiveté about how innovations are received and perceived by the average person. Project managers need to devote as much time to networking with potential clients as they do to ensuring that all the technical features of a new project are performing well. Successful projects may require product and client modification. Any new project must be right for the client base for whom it is targeted. Further, the right project refers to the importance of matching the needs and attitudes of the client base to the new product. Many clients acquire products that are underutilized because they were inappropriate for their needs. However, it is necessary to understand that an inappropriate project is often not the direct result of technical difficulties or performance characteristic flaws. Sometimes a project will be perceived as inappropriate because it does not conform to the attitudes and value systems of the target population. In other words, the cultural ambiance of a firm or customer group must be taken into consideration when determining their needs. The process of developing greater acceptance of innovative projects involves a process of mutual adaptation between the project itself and the customer. Significant prework is required from the project manager and team members as they scan the client and objectively assess attitudes and needs regarding a

Page 77 project. If the team determines that it is not feasible to introduce a project within the current organizational or environmental context, they need to begin formulating plans for how to create a more supportive environment. That process may require either modifying the project to suit the technological needs of the client, engaging in large-scale training or education programs within the external environment to create an atmosphere of acceptance, or both. Unless project managers and their teams work to address potential problems of project acceptance, their highly developed and technically sophisticated innovations are likely to fail without having been given a sufficient chance to succeed.

CONCLUSIONS This chapter addressed some of the confusion that results from our attempts to accurately assess projects as either successes or failures, arguing that there are a number of criteria that can cause confusion in our ability to first assess completed projects before learning from them. Organizations must be straightforward regarding their failures, just as much as they trumpet successes, if failure is to serve as a valuable learning mechanism for future activities. When we are continually unwilling to learn from past mistakes, first by refusing to recognize them as failures and then glossing over their impact, we simply perpetuate a recurring cycle of attempt—failure—attempt—failure. Success is first and foremost a customer-based phenomenon. It is the client who is the ultimate arbiter of successful project implementation. An overemphasis on client concerns, while willingly sacrificing internal constraints such as budgets, schedules, and performance, is not the answer either. A balance is required: an à priori decision rule that allows us to correctly prioritize our activities

Page 78 while at the same time ensuring that the project is not done in by a factor we could control but chose not to address. If such a balance is achieved, it will go far toward creating an atmosphere in which project priorities are well-understood and serve as guideposts for our efforts, reducing the manageable reasons for projects to fail.

NOTES 1. R.X. Cringley. (1994). “How to Forfeit Millions for Nothing,” Forbes, August 29, pp. 61–64. 2. J.K. Pinto and D.P. Slevin. (1988). “Project Success: Definitions and Measurement Techniques,” Project Management Journal, 19(1), pp. 67–72. 3. R.D. Gilbreath. (1986). Winning at Project Management—What Works, What Fails, and Why. New York: John Wiley.

Page 79

CHAPTER FOUR PROJECT CRITICAL SUCCESS FACTORS The managers charged with successful implementation of projects face a number of challenges today in their management tasks. The environment of most organizations has become more dynamic with increasing uncertainties in technology, budgets, and development processes. Highly trained and well-educated experts from a variety of diverse functional backgrounds must be coordinated so that their technical inputs and expertise integrate well into the human system in which they are operating. Thus, the manager charged with successful implementation of a project must be increasingly aware of any early warning signs of problems of either a technical or organizational nature. Project managers should also be aware of some of the wide range of issues, called critical success factors (CSFs), that can play a significant role in determining the likelihood of implementation success or failure. Numerous computer software management aids have been developed to help manage the technical aspects of projects (the critical paths, interdependencies, budgets, milestone schedules, and so forth). However, the use of CSFs offers project managers an important tool in assessing the behavioral and organizational aspects of

Page 80 implementation: Issues that we will demonstrate, are often of equal importance to implementation success as are the more technically based factors. In organizations today, project managers are often firefighters; they spend their days going from one problem area to another, putting out a succession of small and large ‘‘fires” that can threaten the successful development of their projects. They often attend to critical success factors in an intuitive and ad hoc fashion as they attempt to manage and allocate their time and resources across a number of conflicting demands. A refined and specific model of these critical success factors and their interrelationships would be helpful. Further, a method to measure these factors would assist project managers in allocating resources and detecting problem areas early enough to enable them to respond effectively. This chapter describes the development of a framework of CSFs for project implementation. Further, we argue that in the majority of situations, it is the behavioral and organizational factors rather than technical issues that can have the greatest impact on successfully introducing new projects.

BACKGROUND There is an increasing interest in critical success factors in the field of organizational research. Several authors, writing on the implementation process, have developed sets of CSFs, or those factors which, if addressed, will significantly improve the chances for successful implementation. In this chapter, we focus on three of the more well-known streams of CSF research and their implications for project implementation. Two of the studies examined the CSFs for implementation success using databases of projects from U.S. companies.1 A third study, using a sample of British firms, looked at major drivers and inhibitors of project success.2 There is a high level of agreement among the findings in these three studies, regardless of

Page 81 the different implementation efforts being studied and the potential cultural differences.

Morris’ Study The first study that we would like to briefly touch on, conducted by Peter Morris, was based on a large sample of British firms and their efforts at implementing new technologies. Morris broke the implementation process into a life cycle comprising four stages: team formation, build-up, main phase, and close-out. Among the behavioral factors looked at were issues such as personal motivation, top management support, team motivation, clear objectives, client support, technical issues, financial concerns, and so on. The results of the study, as shown in Table 4.1, demonstrated three important points. First, the relative importance of the various CSFs change as the implementation effort proceeds through its life cycle. For example, at stage one, team formation, the most important factors are personal motivation and top management support. However, by the time the implementation process is in its close-out, personal and team motivation are most important to the success of the project. Behavioral and organizational factors far outweigh technical issues in terms of their importance for implementation success. Rather than focusing undue concern on technical issues (adequate budgets and financial support, scheduling, and so forth), it was far more important to pay attention to the human side of the implementation process: to remember that management does not simply imply oversight, but also attendance to the needs and concerns of members of the implementation team as well as the clients. The final point, although closely related to the above two issues is that these human and organizational issues which are the primary drivers of implementation success can also have tremendous impact on system failure if not addressed. The inhibitors of successful implementation,

Page 82 Table 4.1 Findings from the British Study on Critical Success Factors Principal Success Drivers Stage

Critical Success Factors (in Order of Importance)

Formation

Personal ambition Top management support Team motivation Clear objectives Technological advantage

Build-up

Team motivation Personal motivation Top management support Technical expertise

Main phase

Team motivation Personal motivation Client support Top management support

Close-out

Personal motivation Team motivation Top management support Financial support

Source: P.W.G. Morris. (1988). “Managing Project Interfaces—Key Points for Project Success,” in D.I. Cleland and W.R. King, eds., Project Management Handbook. New York: Van Nostrand Reinhold, pp. 16–55.

once again, are clearly shown to be primarily behavioral and organizational in nature, rather than technical (Table 4.2).

Baker, Murphy, and Fisher’s Study Morris’ study sparked interest in the analysis of CSFs within the project implementation context partially because it pointed so clearly to the tremendous role that behavioral and organizational factors can play in the successful implementation of innovations. A separate study by Baker, Murphy, and Fisher addressed a comprehensive list of those

Page 83 Table 4.2 Findings from the British Study on Critical Success Factors Principal Inhibitors to Success Stage

Problems with Critical Success Factors (in Order of Importance)

Formation

Unmotivated team Poor leadership Technical limitations Money

Build-up

Unmotivated team Conflict in objectives Leadership problems Poor top management support Technical problems

Main phase

Unmotivated team Poor top management support Deficient procedures

Close-out

Poor control Poor financial support Objectives Leadership

Source: P.W.G. Morris. (1988). “Managing Project Interfaces—Key Points for Project Success,” in D.I. Cleland and W.R. King, eds., Project Management Handbook. New York: Van Nostrand Reinhold, pp. 16–55.

factors which were thought to contribute to perceived project implementation success.3 Their list also included a number of behavioral dimensions (project team spirit, project team and leader goal commitment, project manager’s human skills, job security of implementation team, and so forth), as well as organizational issues (parent organization enthusiasm, satisfaction with project team structure, adequacy of change procedures, and so forth), and technical factors (development of a realistic budget and schedule to completion, technical details of the system to be implemented, and so forth). They

Page 84 examined over 650 projects across a wide range of project types, durations, budgeted costs, and goals. As Table 4.3 shows, the similarity of their findings to the earlier British study are striking. Again, the behavioral and organizational factors are clearly most important. In particular, the single factor of coordination and relations, encompassing a variety of items such as capability of the project team, sense of mission, team spirit, goal commitment, and supportive informal relations of team members accounted by itself for 77 percent of the causes of implementation success. These two studies illustrate that any discussion of the factors critical for system implementation success must look beyond concerns over the basic technical merits of the system. Too often, particularly among technical personnel, there is a tendency to see problems and possibilities from a very narrow focus. In implementing a project, managers placed in charge of that process must acknowledge that technical mastery of the system provides, in itself, no guarantee of adoption success. In fact, such mastery may actually hurt the Table 4.3 Factors Contributing to Perceived Implementation Success Standardized Regression Coefficient

Sig.

Cum. R2

Coordination and team-client relations

+.35

p < .001

.773

Adequacy of team structure and control

+.19

p < .001

.830

System uniqueness, importance, and public exposure

+.15

p < .001

.887

Success criteria salience and consensus

+.25

p < .001

.886

Competitive and budgetary pressure

–.15

p < .001

.897

Initial over-optimism, conceptual difficulty

–.22

p < .001

.905

Internal capabilities build-up

+.08

p < .001

.911

Determining Factors

Source: B.N. Baker, P.C. Murphy, and D. Fisher. (1983). “Factors Affecting Project Success,” in D.I. Cleland and W.R. King, eds., Project Management Handbook. New York: Van Nostrand Reinhold, pp. 778–801.

Page 85 prospects for successful introduction if it causes managers to reveal and be influenced by professional biases in their management of the team and implementation process.

Pinto and Slevin’s Study Another study of CSFs in the project implementation process looked at over 400 projects varying greatly in terms of the basic characteristics.4 A wide range of representative samples of project type included R&D projects, construction projects, information system projects, and so forth. Their study validated a 10-factor model of critical success factors for project implementation that will be discussed next. Further, they were also able to confirm the extreme importance of managerial, behavioral, and organization issues in successful system implementation. In fact, one of the stated benefits of their research was the determination that, to a large degree, these CSFs remain within the control of the project manager responsible for implementing the project. Rather than being held captive to a chain of events beyond their control, project managers have a strong capacity to influence and improve their teams’ chances of implementation success by attending to these CSFs.

CRITICAL SUCCESS FACTORS—A 10-FACTOR MODEL There is a growing body of project management literature that focuses on implementation critical success factors. However, in many cases project management prescriptions and process frameworks are theoretically based, rather than empirically proven. That is, the evidence supporting these sets of factors is often anecdotal, single-case study, or theory-derived rather than empirical. While there sometimes exists strong intuitive evidence supporting the conceptual frameworks of the project management process, there is relatively

Page 86 little empirical basis for the resulting models and theories of project management and implementation. From Pinto and Slevin’s research, however, we can begin to explore how these factors offer new insights into the managerial nature of project CSFs (Table 4.4).

Factor Definitions The first factor that Pinto and Slevin developed was related to the underlying purpose for the implementation and was classified Project Mission. Several authors have discussed the importance of clearly defining goals as well as ultimate benefits at the outset of a project. Table 4.4 Factor Definitions 1. Project mission—Clearly defined goals and general directions. 2. Top management support—Willingness of top management to provide the necessary resources and authority/power for implementation success. 3. Schedule/plans—A detailed specification of the individual action steps for system implementation. 4. Client consultation—Communication, consultation, and active listening to all parties impacted by the proposed project. 5. Personnel—Recruitment, selection, and training of the necessary personnel for the implementation project team. 6. Technical tasks—Availabilty of the required technology and expertise to accomplish the specific technical action steps to bring the project online. 7. Client acceptance—Selling the final product to its ultimate intended users. 8. Monitoring and feedback—Timely provision of comprehensive control information at each stage in the implementation process. 9. Comunication—The provision of an appropriate network and necessary data to all key actors in the project implementation process. 10. Troubleshooting—Ability to handle unexpected crises and deviations from plan.

Page 87 For example, Morris classified the initial stage of a project management as consisting of a feasibility decision.5 Are the goals clear and can they succeed? Project Mission refers to a condition where the goals of the project are clear and understood, not only by the project team involved, but by the other departments in the organization. Some examples of questions for project managers to answer include “The basic goals of the project are clear to me,” and ‘‘The goals of the project are in line with the general goals of the organization.” The underlying themes of issues classified in this factor include statements concerning clarification of goals as well as belief in their congruence with overall organizational objectives. The second factor is that of top management support. Management support for projects, or indeed for any implementation effort, has long been considered of great importance in distinguishing between their ultimate success or failure. Beck observed that project management is not only dependent upon top management for authority, direction, and support, but that ultimately, projects serve as the conduit for implementing top management’s plans, or goals, for the organization.6 Further, the degree of management support for a project will lead to significant variations in the degree of acceptance or resistance to that project or product. Top management’s support of the project may involve aspects such as allocation of sufficient resources (including financial, manpower, time, etc.) as well as project management’s confidence in their support in the event of crisis. Sample statements for project managers to consider using when addressing this factor are “Upper management has provided me with sufficient authority and responsibility to oversee the project” and “I have the confidence of upper management.” The third factor to be classified was that of schedule/plans. Project schedule refers to the importance of creating a detailed plan of the required stages in the implementation process. As developed in our model, schedule/plan refers to the degree to which time schedules, milestones, manpower, and equipment requirements are specified.

Page 88 Further, the schedule should include a satisfactory measurement system as a way of judging actual performance against budget and time allowances. Schedules and plans are not intrinsically the same. Planning is a more broad-range process, encompassing resource assessments, work breakdown structures, and other forms of project monitoring mechanisms. Scheduling, on the other hand, is generally understood to refer to the tasks of creating specific time and task-interdependent structures, such as Critical Path and Gantt charts. A sample of the type of statements considered in this factor include “I have identified the important manpower skills required for successful project completion,” and “I have contingency plans in case the project is off schedule.” The fourth factor is labeled client consultation. We have identified the client as anyone who will ultimately be making use of the result of the project, as either a customer outside the company or a department within the organization. The need for client consultation has been found to be increasingly important in attempting a successful system implementation. The degree to which clients are personally involved in the implementation process will cause great variation in their support for that project.7 It is, therefore, important to determine whether clients for the project have been identified. Once the project manager is aware of the major clients, he or she is better able to accurately determine if their needs are being met. Some examples of statements to consider in the client consultation factor include ‘‘I have solicited input from all potential clients of the project,” and “I understand the needs of those who will use the system.” The fifth factor was concerned with personnel issues, including recruitment, selection, and training. An important, but often overlooked aspect of the implementation process concerns the nature of the personnel involved. In many situations, personnel for the project team are chosen with less-than-full regard for the skills necessary to actively contribute to implementation success. Most current

Page 89 writers on implementation are acknowledging the role of effective project team personnel in successful implementation efforts and are including the personnel variable in their equation for project team success. For example, one researcher has developed a contingency model of the implementation process which includes “people” as a situational variable whose knowledge, skills, goals, and personalities must be considered in assessing the environment of the organization.8 For our framework, personnel, as a factor, is concerned with developing an implementation team with the requisite skills and commitment to perform their function. Examples of statements for the personnel factor include “The personnel of my project team are committed to the project’s success,” and “The lines of authority are well defined on my project team.” The sixth factor to be discussed is technical tasks. It is important that the implementation be well managed by people who understand it. In addition, there must exist adequate technology to support the system. Technical tasks refer to the necessity of ensuring that the necessary personnel of the implementation team possess the necessary technical skills and have adequate technology to perform their tasks. The decision to initiate a new project must be predicated on the organization’s ability to both staff the team with competent individuals and provide the technical means for the project to succeed. A recent example of a technical task failure involved a company who contracted with the U.S. government to create a software system using C programming language. The firm belatedly discovered that they did not have enough programmers conversant in C language to perform the contract and lost valuable time and incurred schedule slippages while they sent several of their programmers off-site to take training classes in C language. Examples of technical tasks statements would include “The technology that is being implemented works well,” and ‘‘Experts, consultants, or other experienced managers outside the project team have reviewed and criticized my basic plans/approach.”

Page 90 In addition to client consultation at an earlier stage in the system implementation process, it remains of ultimate importance to determine whether the clients for whom the project has been initiated will accept it. Client acceptance refers to the final stage in the implementation process, at which time the overall efficacy of the project is to be determined. Too often project managers make the mistake of believing that if they handle the other stages of the implementation process well, the client (either internal or external to the organization) will accept the resulting system. Client acceptance is a stage in project implementation that must be managed like any other. Some researchers have even proposed the use of intermediaries to act as a liaison between the designer, or implementation team, and the project’s potential users to aid in client acceptance.9 Examples of statements referring to client acceptance would include “Potential clients have been contacted about the usefulness of the project,” and “Adequate advanced preparation has been done to determine how best to ‘sell’ the project to clients.” The eighth factor to be considered is that of monitoring and feedback. Monitoring and feedback is a project control process by which, at each stage of the project implementation, key personnel receive feedback on how the project is comparing to initial projections. Making allowances for adequate monitoring and feedback mechanisms gives the project manager the ability to anticipate problems, to oversee corrective measures, and to ensure that no deficiencies are overlooked. Project managers need to emphasize the importance of constant monitoring and fine-tuning the implementation. For our model, monitoring and feedback refers not only to project schedule and budget, but also to monitoring performance of members of the project team. Sample statements for the project manager to consider under the monitoring and feedback factor include “When the budget or schedule requires revision, I solicit input from the project team,” and “All members of the project team know if I am satisfied/dissatisfied with their work.”

Page 91 The ninth factor was that of communication. The need for adequate communication channels is extremely important in creating an atmosphere for successful system implementation. Communication is not only essential within the project team itself, but between the team and the rest of the organization as well as with the clients. Figure 4.1 demonstrates the tripartite nature of communication and the necessity of keeping open channels among all active stakeholders in the project’s development. As the factor communication has been developed for our framework, it refers not only to feedback mechanisms, but the necessity of exchanging information with both clients and the rest of the organization concerning the project’s capabilities, the goals of the implementation process, changes in policies and procedures, status reports, and so on. Some statements that reflect the issues that are of concern for communication include “Input concerning the implementation effort’s goals and strategy have been sought from members of the project team, other groups affected by the project, and upper management,’’ and “All groups affected by the project know how to make problems known to those who can deal with them.” Figure 4.1 The Three-Way Path of Communication

Page 92 The tenth and final factor to emerge from the research study is troubleshooting. Problem areas exist in almost every implementation. The measure of a successful project implementation effort is not the avoidance of problems, but knowing the correct steps to take once problems develop. Regardless of how carefully the implementation effort was initially planned, it is impossible to foresee every trouble area or problem that could possibly arise. As a result, it is important that the project manager make adequate initial arrangements for troubleshooting mechanisms to be included in the implementation plan. Such mechanisms would make it easier not only to react to problems as they arise, but to foresee and possibly forestall potential problem areas in the implementation process. Statements that reflect issues to be considered under the troubleshooting factor include: “I spend a part of each day looking for problems which have just begun or have the potential to begin.” and “Implementation team members are encouraged to take quick personal action on problems on their own initiative.”

Research Implications The framework initially developed by the previous discussion can be viewed from both a conceptual and a practical standpoint. Conceptually, the model argues for both the sequential and interdependent aspects of the factors found to be critical to system implementation success. That is, these factors are seen as arising for consideration separately, but as often having strong influence on each other. For example, the theoretical literature and practical experiences of many project managers demonstrates that initial client consultation will create a strong likelihood of subsequent client acceptance. Beyond the development of a conceptual framework of 10 critical success factors, recent research has verified the importance of each of the 10 factors to implementation success. Table 4.5 shows the results of a study of over 400 project implementation efforts that assessed

Page 93 Table 4.5 Critical Success Factors and Their Importance for System Implementation Factor

Beta

T-Value

Sig. T

Mission

.72

19.99

p < .001

Top management support

.32

10.60

p < .001

Schedule

.32

10.92

p < .001

Client consultation

.39

11.86

p < .001

Personnel

.31

10.54

p < .001

Technical tasks

.43

11.25

p < .001

Client acceptance

.39

11.46

p < .001

Monitoring and feedback

.29

10.89

p < .001

Communication

.32

10.38

p < .001

Troubleshooting

.35

11.15

p < .001

Cumulative R2 = .615 Source: J.K. Pinto. (1986). Project Implementation: A Determination of Its Critical Success Factors, Moderators, and Their Relative Importance Across Stages in the Project Life Cycle, Unpublished doctoral dissertation, University of Pittsburgh, Pittsburgh, PA.

the importance of these 10 factors, clearly demonstrating the strong significance of each of these factors for implementation success.

WHAT DOES THE RESEARCH SHOW? Rather than devote a tremendous amount of space to an in-depth discussion of the results of research on the 10-factor model, we have condensed these findings into a summary based on the conclusions discussed next.

Keep the Mission in the Forefront On the surface, it seems obvious to state that it is important to keep the mission in mind when implementing a project. However, the

Page 94 point bears repeating and underlining. Adherence to mission was the number one cause of implementation success. Remember that mission refers to conveying exactly what the goals of the implementation effort are to all concerned parties, particularly the other project team members and prospective users of the system. What will the new project do for us and the rest of the organization? How long do we expect it to take to develop and bring it out the door? Does every member of the project team understand and buy into these goals? These are just some of the important questions that need to be asked about the project’s mission. Nothing will derail a project faster than not having clearly communicated its goals to all groups impacted by the project. When goals change or need updating, that information also needs to be made public. One well-known problem with getting a project out the door is the potential for the mission to change or metamorphosize as the project progresses. There are many examples of projects that, for whatever reason, underwent major specification, technological, or user changes or got off on such tangents that the originally agreed-upon goals and purposes became meaningless. Obviously, some modifications are bound to occur as a project is customized for a particular client’s uses. The point that must be stressed, however, is that the project’s underlying purpose must remain clear and important for all members of the implementation team.

Consult with Your Clients Early Remember that clients refers to any projected or potential user of the project. Regardless of who the client is for a particular project, it should be apparent that consultation and communication with clients across its development is very important for successful implementation. Put another way, one of the worst things that a project manager can do is initiate and develop a product or service without engaging in any meaningful dialogue with the external

Page 95 customers or internal departmental clients who could potentially make use of the technology. People don’t mind “change,” they just don’t like being changed. We tend to be leery of anything that can cause disruption in our thought patterns, approaches to decision making, or work habits. The output of a completed project is bound to cause disruptions in all three of these areas. Therefore, knowing in advance that there is a strong potential for this project to change forever (hopefully, in a positive manner) customer attitudes or internal client operations, it makes excellent sense to spend a considerable amount of up-front time laying the groundwork for successful introduction of the project.

Stay Well Connected to Clients Client acceptance, a selling activity, is necessary during both the initial planning processes as well as during the termination phase of the implementation. Often, the sequence of operations concerned with the client follows this pattern: (1) Consult to determine specific needs; (2) sell our ideas (including the benefits of the project), budgets, and time frame to completion; and (3) perform a final verification of client acceptance once the project has been completed. This verification may be in the form of a series of formal interviews or follow-up conversations with clients who are intending to use it. In developing and implementing a project, do not underestimate the importance of “selling” the output to the clients, even after having initially consulted with them about the system. An important truth of project implementation suggests that one can never talk to the clients enough. A corollary to that rule argues that just because the project manager and team members have once spent time consulting with clients about the system, it is absolutely incorrect to now assume that clients will embrace the finished product with open arms. In the time between initial consultation and

Page 96 project development and transfer, too much can change that will alter their perceptions of the product. For example, the technology may be altered significantly or a great deal of time may have elapsed, changing their basic reasons for even needing the system. Or perhaps, one of the department’s chief proponents of the project has since left to take another job. The common denominator of all these issues is that time does not stand still between initial client consultation and final project completion. Do not automatically assume that you fully understand the client’s concerns or, once transferring the completed project, that it will now be used. In fact, this topic is so crucial to successful project implementation that we have devoted a chapter to it later in this book.

Make Sure You Have the Technology to Succeed The successful development and acceptance and use of a project assumes that the organization has the technology or the technically capable people to support the system and ensure that it succeeds. Many of us suffer from the eyes-bigger-than-the-stomach syndrome. This malady manifests itself most often at mealtimes, particularly during dessert. No matter how much we may have eaten to that point, once dessert is offered, it is almost always accepted. Of course, there is no guarantee that the dessert will be eaten. In fact, it is rarely completely finished. We are just unable to judge our capacity. There is a similar characteristic with many organizations: They too suffer from having eyes bigger than their stomachs. A new technology is introduced nationally and someone within the organization develops great enthusiasm for the concept. The question that needs to be asked at this point is whether or not the organization can support the successful development and introduction of this project with the personnel and facilities they currently possess. If the answer is no, the organization needs to take immediate remedial steps: either

Page 97 hiring additional support personnel who have the necessary technical backgrounds, instituting a department-wide training program to bring potential users up to technical standards, or if necessary, put the brakes on the project’s development until another time when it can be more fully supported.

Set Up and Maintain a Scheduling System Planning is an activity that many project managers avoid. The process can sometimes be rather tedious and involves an activity that does not have immediate visible results. This is particularly true early in the project’s life cycle, when top management begins to issue a string of pointed communiqués demanding to know when project development will begin, somehow assuming that time spent planning is taken away from time spent doing. In spite of these external pressures for action, it is impossible to underestimate the importance of comprehensive and detailed planning for successful project implementation. There is great validity to the old saying that ‘‘Those who fail to plan are planning to fail.” Initiating the action steps in a project without having developed a comprehensive planning and control process may please upper management in the short term but it is a real recipe for disaster down the road. During the early start-up of the implementation effort planning is paramount. This type of planning involves setting milestones, breaking down the specific work activities into meaningful bits and assigning the necessary personnel to tackle each of these duties. However, planning is also very useful during the final termination phase of the project. We have found that planning here serves two purposes. First, schedules provide feedback on how well the project team accomplished their goals: It serves as a learning device through comparing projected schedules with actual results. Second, schedules are needed for the transfer of the project to its intended

Page 98 users. Transferring the project, establishing training sessions and maintenance cycles, and getting it online usually require an additional series of target dates and schedules.

Put the Right People on the Project Team The importance of recruiting, selecting, and training people who possess the necessary technical and administrative skills to positively influence the ultimate success of the project cannot be stressed enough. Does the organization currently possess people capable of understanding the technology and dealing with the headaches, deadlines, and conflict that a project implementation can bring? Of equal importance is the question, “How are project team members assigned to the group?” In many organizations, members are assigned to project teams purely on an availability basis; that is, if managers have subordinates who are currently free, those people are put on the team, regardless of whether or not they possess the technical qualifications, people skills, or administrative abilities to perform effectively. In some organizations, members are assigned to projects as a method for getting them out of their departments and making them someone else’s problem. In these cases, managers simply use the project as an excuse to shift problem employees to other duties. It is easy to imagine the prospects for projects that are continually staffed this way. Personnel as a factor implies having and assigning the most qualified individuals to the implementation team, not the most available. We owe our projects more than to simply make an implementation team the dumping ground for malcontents.

Make Sure Top Management Gets behind the Project It is well-accepted that top management can either help or seriously hinder a project. Top management grants the necessary authority to

Page 99 the project manager, controls needed resources, arbitrates cross-departmental disputes, and rewards the final results. Its role in the successful implementation of a new project should not be overlooked. However, top management support must go further than simply “approving” the new system. Their statements of support have to be backed up by concrete actions and demonstrations of loyalty. Actions speak far louder than words and have a way of truly demonstrating how top management feels about the project and, by extension, the project manager. Are they putting their money where their mouth is or is their support simply pro forma? This is an important question that needs to be resolved early in the implementation process, before significant time and resources have been spent. Further, top management’s support can be most important during the time when the actual work of the implementation is being done rather than early on or after the project is being terminated prior to transfer to clients. Top management is most able at this point to make their presence felt, through providing the necessary money, personnel, and support for the system as they are needed. Finally, both project managers and their teams need to know that top management will support them in the event of unforeseen difficulties or crises. All implementation efforts encounter difficulties and “fair weather” supporters are likely to be terribly demoralizing.

Continually Ask the ‘‘What If?” Questions It is axiomatic that problems will occur with the implementation. All projects run into trouble and the mark of a successful project manager is not one who can foresee and forestall problems; rather, the successful project manager is the individual who has taken the time to puzzle out appropriate responses to likely trouble spots. This idea of troubleshooting is particularly appropriate in the implementation of projects with new or not-well-understood technology because there are so many human and technical variables that

Page 100 can go wrong. The successful project manager has to be cognizant of technical issues and difficulties that can arise but further, the behavioral and organizational issues are often more common, pressing, and potentially damaging to implementation success. Therefore, the act of simply troubleshooting the project’s technical features will only be of limited usefulness. One final point about troubleshooting needs to be mentioned. We have already discussed the importance of a clear project mission for successful implementation. In fact, it was noted as the number one cause of project success. A follow-up study was conducted by one of the authors and a colleague to investigate, again using the 10-factor model, the principal causes of implementation failure. We discovered that the number one cause of failure in project implementation was a lack of adequate troubleshooting mechanisms.10 The projects that were viewed as unsuccessful due to poor adherence to budget, schedule, specification performance, and user acceptance were almost always associated with an inadequate or nonexistent attempt by the project team at troubleshooting.

CONCLUSIONS This chapter has focused on the results of recent research and its implications for successful project implementation using critical success factors (CSFs). The interest in CSFs as a methodology for gaining better control of the project implementation process is still relatively new, but has already yielded some important implications for project managers and those charged with successfully introducing a project. The information offered in this chapter suggests some guidelines for project managers to employ in more efficiently assigning their personnel and resources. It is particularly encouraging to note that the critical factors are all within the control of the project manager; that is, these issues are addressable in that remedial action can be taken in the event that problems do occur. Consequently, this chapter has not

Page 101 only listed the important CSFs, it is also possible to offer advise on their most effective use. It is through creating an actionable set of CSFs that project managers are most likely to employ them in their work and consequently, that their projects are most likely to benefit.

ADDITIONAL RESEARCH ON PROJECT CRITICAL SUCCESS FACTORS Pinto, J.K. and D.P. Slevin. 1992. The Project Implementation Profile. Tuxedo, NY: Xicom. Pinto, J.K. and J.G. Covin. 1989. “Critical Factors in Project Implementation: A Comparison of Construction and R&D Projects, Technovation, 9, 49–62. Pinto, J.K. and J.E. Prescott. 1988. “Variations in Critical Success Factors over the Stages in the Project Life Cycle,” Journal of Management, 14, 5–18.

Notes 1. B.N. Baker, P.C. Murphy, and D. Fisher. (1983). “Factors Affecting Project Success,” in D.I. Cleland and W.R. King, eds., Project Management Handbook. New York: Van Nostrand Reinhold, pp. 778–801; J.K. Pinto. (1986). Project Implementation: A Determination of Its Critical Success Factors, Moderators, and Their Relative Importance Across Stages in the Project Life Cycle, Unpublished doctoral dissertation, University of Pittsburgh, Pittsburgh, PA; J.K. Pinto and D.P. Slevin. (1987). ‘‘Critical Factors in Successful Project Implementation,” IEEE Transactions on Engineering Management, EM-34, 22–27. 2. P.W.G. Morris. (1988). “Managing Project Interfaces—Key Points for Project Success,” in D.I. Cleland and W.R. King, eds., Project Management Handbook. New York: Van Nostrand Reinhold, pp. 16–55. 3. See Baker, Murphy, and Fisher in note 1. 4. See Pinto and Slevin in note 1. 5. See note 2.

Page 102 6. D.R. Beck. (1983). “Implementing Top Management Plans through Project Management,” in D.I. Cleland and W.R. King, eds., Project Management Handbook. New York: Van Nostrand Reinhold, pp. 166–184. 7. J.H. Manley. (1975). “Implementation Attitudes: A Model and a Measurement Methodology,” in R.L. Schultz and D.P. Slevin, eds., Implementing Operations Research/Management Science. New York: Elsevier, pp. 183–202. 8. J.S. Hammond, III. (1979). “A Practitioner-Oriented Framework for Implementation,” in R. Doktor, R.L. Schultz, and D.P. Slevin, eds., The Implementation of Management Science. New York: NorthHolland, pp. 35–62. 9. A.S. Bean and M. Radnor. (1979). “The Role of Intermediaries in the Implementation of Management Science,’’ in R. Doktor, R.L. Schultz, and D.P. Slevin, eds., The Implementation of Management Science. New York: North-Holland, pp. 121–138. 10. J.K. Pinto and S.J. Mantel, Jr. (1990). “The Causes of Project Failure,” IEEE Transactions on Engineering Management, EM-37, 269–276.

Page 103

CHAPTER FIVE MANAGING THE SUPPLY CHAIN FOR PROJECTS In the past decade, the concept of the organizational supply chain has become an increasingly important method for analyzing corporate operations. Supply chain management (SCM) refers to the management of materials and information flows both in and between facilities and other stakeholder organizations. This includes vendors, manufacturing plants and other fabrication facilities, distribution centers, and even distributors themselves. SCM, therefore, involves an enormous undertaking from a logistics perspective. Recent estimates have placed the annual expenditures on nonmilitary logistics at $670 billion, over 11 percent of gross domestic product.1 In many organizations, logistics costs run at approximately 30 percent of total cost of goods sold.2 Consequently, the amount of money we are considering and the potential savings from effective coordination of logistics cannot be underestimated. Increasingly, project organizations and project managers are heeding the call to pay attention to the impact that the supply chain has on the performance, not just on the firm overall, but on individual projects. The goal of project-based SCM is to create a coordinated planning network that allows for optimal acquisition,

Page 104 scheduling, shipping, and distribution of goods and services used in creating a project. As a result, project supply chain management (PSCM) requires project managers and team members to adopt an external focus to project development. Put another way, tending the project while our focus is entirely in-house is no longer useful. In a globalized, hypercompetitive marketplace, being first to market involves managing the entire logistics process, rather than simply developing the project without regard to the larger picture. Suppose you are a member of a project team and have discovered that a competitor is in the process of developing a project very similar to yours. Unlike your firm, however, the rival’s project team is in close touch with all external vendors, shippers, warehousing and facilities management personnel, and distributors. Your team concentrated solely on the project’s development, trusting your acquisitions and purchasing people to get materials to you when you needed them. Which team do you think stands the better chance of getting the necessary materials, completing the project, and getting it to market in the more timely fashion? Complex projects that require the input from multiple vendors and support organizations cannot afford the luxury of waiting patiently for materials to arrive. In our consulting and work experience, one of the common mistakes many project managers and their teams make is to create a relationship with vendors based solely on price, short-term time horizons, and a one-job-at-a-time mentality. The first sign of problems in the relationship typically shows up when the first promised delivery date is missed. Then the telephone calls start, the excuses begin, and the “real” target delivery date is agreed to. Unfortunately, to you every day that passes until the new delivery date means additional costs due to the changes in your planned work sequence and accelerated work, as well as, in the worst case, delay and loss of revenue. This is not the way to manage the supply chain for our projects. Canny firms realize this point. Companies as diverse as General Electric, Ericsson, Boeing, ABB, Hewlett Packard, and Aker

Page 105 Maritime have some important similarities; all have been successful for a number of years, all have good project management systems in place, and all place a premium on gaining and maintaining effective external relationships with their suppliers. Whether the key is global outsourcing, as GE champions, or long-term subcontractor partnerships, which is the path Boeing has followed, the key lies in proactive management of the supply chain. Project supply chain management requires a new way of viewing the traditional approach to managing and supporting project development. Consider the diagram in Figure 5.1. Traditional project management often offered a truncated activity flow; that is, the emphasis tended to be on front-end procurement and supply issues and internal project development. That is not to say that clients were unimportant, but beyond attaining specific order information from them, clients had little say in the project as a work-in-progress activity. Under the operating philosophy typified by this model, coordination with vendors through procurement practices was key to preparing the stage for project development. Further, the Figure 5.1 Project Supply Chain Management

Page 106 subsequent development of the project signaled its completion and project success. Using the PSCM approach, project management has become a more long-linked phenomenon. Traditional procurement activities are still emphasized as a key to on-time development of the project. However, this customer-based approach also directly involves the customer, the final link in the supply chain. Customer involvement implies that we are creating a methodology in which the client is not simply the recipient of the final project, but a direct participant in the project’s planning, decision processes, target and goal setting, and measurement of project performance.3 In effect, PSCM closes the circle on new project development by starting with customer requirements, working throughout the project in active partnership with the customer, and finally completing a project that is highly likely to satisfy customer needs because their voice has been heard throughout. An important mechanism for establishing this customer focus is to analyze firm activities in project management around the framework of supply chain management. This chapter creates a model of the project supply chain. PSCM requires first a sound understanding of its various components and then a logical link to how we currently run our projects. Are we following a PSCM program or are we dealing with suppliers in a reactive mode? Customer-based project management cannot work to its full potential until we take the necessary steps toward managing the development process; a process that begins with suppliers and ends with customers. Project development is a critical component of the overall chain, but it can work effectively only if it is understood outside the larger framework.

THE PROJECT SUPPLY CHAIN There are three traditional components of organizational supply chains: procurement, fabrication, and distribution. Each of these

Page 107 three stages may contain several levels or networks, as Figure 5.2 illustrates. We consider each of these stages in turn, particularly their implications to the project organization.

Procurement The logistics trail for project development begins with supply. Procurement is the process of establishing reliable and cost-effective relationships with the necessary suppliers to ensure that all services and parts or subcomponents are available when they are needed. Realistically, all procurement activities must project outward from the organization to the point at which raw materials are acquired. As Figure 5.2 shows, it is often reasonable to recognize that effective procurement must consider resource availability all the way back to the source, the raw materials that are manufactured into needed supplies or components of assembly (in the case of produced goods) or other forms of raw materials such as manpower and financial resources (in the case of services). Sometimes these challenges are truly daunting: the Boeing 767 requires the assembly of 3.1 million individual parts through over 1,300 separate vendors. In maintaining its process throughput, Boeing has to ensure that each vendor delivers Figure 5.2 Project Supply Chain

Page 108 products of sufficient quality at the time they are most needed. Sometimes, unfortunately, they fail. Boeing, for example, faced with enormous demand for their jets and not having taken sufficient steps to manage their supply chain, was forced to take a $1.6 billion dollar write-off in late 1997 due, in part, to “raw material shortages, [and] internal and supplier parts shortages. . . .”4 Proactive firms are constantly alert to future trends, problems, and opportunities for procuring the material resources necessary to complete the project. Procurement requires extensive planning and relationship-building in the form of trust in order to work. The challenges of procurement are exacerbated by the complexity of the project in development, as in the case of Boeing. Highly complex or technical projects may require organizations to devote millions to their coordination efforts. Further, when project development requires sequential processes, as in the case of construction, the failure of one link in the procurement chain can cause the delay and disruption of the entire project. Likewise, when suppliers’ delivery of required materials or services is uncertain, it makes it almost impossible to develop accurate project plans. To illustrate, Eli Goldratt, a noted project management theorist, tells of the circumstances involved in constructing a steel girder bridge, a structure with approximately 200 unique steel products.5 Assuming that the likelihood of ontime delivery of each part is 60 percent, the problems quickly mount. The likelihood of getting two parts on time is (.60)(.60) or 36 percent. Getting four parts delivered on time has a likelihood of (.60) (.60)(.60)(.60) or 12.9 percent. And on it goes. Ultimately, without effective delivery timetables, the impact on the project’s schedule quickly becomes severe. You have a greater chance of winning the lottery than completing a bridge on schedule when procurement is this chancy! The obvious key is to create relationships with vendors who are dependable to allow for more accurate planning. Until our organization can create a comfort level with vendors in project

Page 109 procurement, deliveries will always be problematic and the likelihood of successful performance to project schedules impossible. In this respect, international quality assurance (QA) standards, such as ISO 9001, are highly useful in providing a standard basis for supplier selection. The companies that have acquired ISO 9001 certification have demonstrated to a third-party auditor that their systems and operations fulfill certain standard criteria. Furthermore, they are regularly audited by third party to ensure that they follow their approved procedures and maintain the requested level of quality in their operations. Some firms operating in the high-technology environment have gone one step further. General Electric Company, through their global sourcing initiative, has created a program to develop vendors and constantly work to improve their performance to minimize negative impact on GE’s operations. Vendors and perspective vendors are given extensive guidelines and training in improving their own operations by GE personnel. Those vendors who perform well and whose operations improve to the level of efficiency and quality that GE requires are given long-term supplier contracts. Those whose products or processes are substandard are provided with detailed information on how to improve their systems and are carefully monitored. Repeated failures to improve is grounds for GE to terminate their agreements. GE’s attitude can be summed up in a paraphrase of President Clemenceau’s (French President during WWI) famous dictum, “Our suppliers’ performance is too important to be trusted to them.”

Fabrication Fabrication may consist of manufacturing goods or assembling the manufactured materials that were produced at another site. This phase represents the actual creation of the service or good, as in the case of new product development or internal system implementation.

Page 110 As with procurement, fabrication carries its own set of challenges and complexities. For example, in creating a new software package, programmers may create literally millions of lines of computer code, refining the process to streamline the subactivities for optimal speed. As an other example, building an offshore oil drilling vessel consists of numerous individual steps in fabrication, assembly, testing, and commissioning. This includes construction of the hull with the necessary systems needed for power generation, propulsion, ballasting, station keeping, and navigation, as well as, outfitting the hull with the necessary technology and systems for drilling, material handling, storage, and accommodation of the crew. Whether the project is relatively routine or highly complex, at some point in its life cycle, it will require that the various activity steps be accomplished. Although fabrication is a word that derives its roots from manufacturing, there is a natural parallel to service technologies as well. The term technology itself simply refers to the conversion process a company uses to change inputs into outputs. If, for example, the output of our firm is a manufactured good, such as an automobile, our technology is one of manufacturing and fabrication. On the other hand, in financial services, such as banking or investments, the technology revolves around contact with people through providing services such as investment advice or savings and checking opportunities. In either case, the technology of the firm (its conversion process) involves some notion of fabrication such that projects can be developed in service industries just as readily as in manufacturing concerns.

Distribution Traditional supply chain management focuses on logistics planning and execution. Distribution, in that arena, typically refers to the completion of finished goods, shipment to storage facilities such as

Page 111 warehouses, and final transfer to distribution centers and independent wholesalers. In project supply chain management, however, distribution refers to the final link in the development chain; that is, the actual transfer of the product to its users. In this sense, the distribution process is the signal of completion of a successful project. Distribution has had some important changes in various aspects of project-based firms in recent years. For example, in large plant construction in foreign countries, more and more foreign governments are requiring a significant resource commitment from the construction companies. A concept known as BOOT refers to the stages of Build, Own, Operate, Transfer, suggesting that foreign countries are anxious to defray some of the monetary risk of developing these plants. Construction companies such as Bechtel, M.W. Kellogg, Brown and Root, Fluor-Daniel, and others are now required not only to build the plant but operate it jointly with the customer for some period of time prior to final transfer of ownership to the client. In this way, clients reduce their risk while forcing construction firms to take active joint ownership in the venture, minimizing the potential for start-up problems. Ultimately, distribution issues require significant commitment to the project from the developing organization but they also offer some exciting opportunities for gaining competitive advantage over the rest of the marketplace. More and more, companies and other clients are anxious to find ways to defray risk of new projects. Project-based organizations that recognize this natural desire on the part of their customers to minimize risk have begun to operate in ways to position themselves advantageously. Consider again the example in Figure 1.8 in Chapter One. Price is one important factor in determining the awarding of contracts. Also important, however, is the degree of risk a customer is willing to take on as part of the client-project organization relationship. When our company can demonstrate a commitment to building and maintaining a long-term win-win relationship

Page 112 with customers, we offer them substantial evidence of our credibility and consequently, minimize their assumed risk for the project.

DESIGNING THE PROJECT SUPPLY CHAIN AND MAKING IT WORK The four fundamental steps in the creation of a project supply chain and its effective use are summarized in Table 5.1.

Goal Setting The key to designing an effective supply chain lies first in an honest appraisal of our firms’ goals; that is, why are we initiating this process in the first place? For many organizations, the fundamental goal behind creation of an integrated supply chain is a desire to improve internal operating efficiencies. We use supply chain Table 5.1 Steps in Developing a Project Supply Chain 1. Goal setting—Establishing the targets for our organizations. How will this process improve our ability to develop projects? 2. Environmental analysis—Determining the list of viable suppliers who are technically and financially capable of working with our firm. What are the external threats and opportunities in developing the supply chain? 3. Coordination and Planning—Creating and maintaining the supplier relationship in order to develop long-term trust and win-win performance. How can we optimally structure our supply chain to ensure cost and resource flow efficiency? 4. Control—Measuring performance and adjusting the flow of resources or mix of suppliers as needed. How can we be sure that we are getting maximum performance (i.e., highest efficiency) from our supply chain? How can we improve it?

Page 113 management as a mechanism to enable us to develop our projects more cost effectively than our competitors.

Environmental Analysis The goal of environmental analysis is first to identify and assess the potential of a wide range of stakeholders. Project stakeholders are any other people, groups, or larger organizations that have an active stake in the outcome of the project. We identify the best sources of supply, the groups most likely to help (and hinder) project development, other external advocacy groups (such as environmental watchdog organizations), and anyone else who can potentially affect our project. A stakeholder strategy is drawn up for proactively addressing these groups’ concerns. A second use of environmental analysis lies in assessing the external threats and opportunities in the supply chain. For example, will our supply chain consist of companies and suppliers from our own country or will we adopt a multinational perspective? If the latter, do we have plans or methods for assessing their status as well as any significant shifts in the business policies of foreign governments that could have serious impact on our ability to depend upon that particular supplier? Would it be prudent to work with local suppliers due to questions of their long-term viability in an unsettled business climate? This kind of environmental analysis of opportunities and threats creates a logical framework for comparing the strengths and weaknesses of various alternative sources of supply.

Coordination and Planning For supply chain project management to work, effective and intelligent coordinated planning is required. This planning involves two distinct levels: buyer-vendor coordination and productiondistribution coordination.6 Both categories of coordination are

Page 114 important and each can have an impact on the effective development of projects. Figure 5.3 shows the levels of project supply chains and the required planning related to each stage in the development process. Buyer-Vendor Coordination. At the first level, the challenge of project management is procurement; that is, attaining a steady supply of raw materials and resources for the project. Resource procurement is not simply a task of obtaining raw materials, however; a wide variety of resources are necessary if a project is to be developed. Among the resource requirements necessary are financing, human resources, physical plant and equipment needs, and (in the case of produced goods) raw materials. Production-Distribution Coordination. The second stage of coordinated planning concerns the links from development to product transfer to the customer (the so-called distribution link). Clearly, the key determinant of project success lies in the acceptance and use of the product by the customer. How will the transfer be coordinated? Is it a simple sign-off process once the project completes performance Figure 5.3 Supplier Work in Progress

Page 115 verification checks? Is there a transition period to allow for ironing out bugs in the system? Or is there a more complex set of stages of transfer, similar to the BOOT processes mentioned previously? Regardless of the transfer method, careful planning needs to accompany the process and that planning must be incorporated into the front-end PSCM development.

Control Simply stated, control systems are any methods our company maintains to accurately assess or measure performance and correct significant deviations from the plan. Hence, it is a two-stage process: measurement and correction. Controlling the project supply chain is an ongoing process as we constantly assess the performance of our suppliers, their quality, their prices, their reliability, and their future prospects. Indeed, in many corporations it is the standard practice to station a quality assessment staff at the supplier’s work site to ensure before delivery that project components are up to expected standards. We are able to save much more time and money if we have an active say in how our suppliers manufacture or create the raw materials we require rather than waiting for delivery, assessing substandard quality, repackaging and returning, and waiting for new shipments. Further, control also has the unspoken requirement of continuous analysis. We are constantly looking for ways to streamline our supply chain, develop more efficient and value-adding ways of working with the existing vendors, shift to new vendors when appropriate, simulate new chains and delivery systems, and so forth. In other words, once the supply chain is developed, it is subjected to continuous improvement and scrutiny to make sure that we have whittled it down to the best, most efficient, highest quality, and most reliable vendor base we can attain. The process of supply chain

Page 116 control is ongoing. This also raises an important point for vendors: It is vital not to sit back on the laurels of past-won business successes. Companies are looking to streamline operations; therefore, as vendors, we must be aware of their goals and constantly look for ways to reinvent ourselves to stay on top. Don’t wait for the pink slip from a past account to realize it is time to upgrade. Recognize that competitors are doing everything they can to pull business away and respond accordingly.

SETTING UP A PROJECT SUPPLY CHAIN There are a number of steps in setting up effective project supply chains. In this section, we address some of the key points in this process. Clearly, this discussion is not intended to be the last word in establishing your own organization’s project supply chain. Rather, it is aimed at giving you some insight into the various steps involved in initiating the process. A common question we hear from companies attempting to implement supply chain management is, ‘‘How do we get started?” That is a fair question. Too much time spent extolling PSCM and too little explaining the process is of little value to those who need some pragmatic steps. We suggest the following steps in modeling a supply chain.7 Figure 5.4 illustrates the top-down approach to creating a supply chain for a project-based organization. Note, that as a branch-and-bound diagram, the process builds on itself; that is, as we begin to solve one level of challenge, it opens the door to a series of additional, follow-on questions. The target improvement that our organization seeks may involve multiple routes; for example, we may find that our organization’s performance improves through a combination of enhanced understanding and oversight of our operations as well as better use of resources. The means to create these improvements comes about

Page 117 Figure 5.4 PSCM Improvement Process

through motivating all members of the project as well as top and department managers to think in terms of overall process improvement (“How can each department contribute to improving the project development process?”). In doing so, we see alternatives means, including the design of a supply chain and the modeling of supply chain alternatives. These preliminary steps serve as the trigger for organizational enhancements. The next stage in design of the supply chain consists of a realistic analysis of the strengths and weaknesses of current operations, particularly with regard to project development, vendor relations, and client contacts. Because PSCM is a logistics problem at the front-end, diagramming all relevant vendors is essential. This vendor analysis often takes the form of asking a series of searching questions about the nature of our suppliers. Table 5.2 gives examples of some of the important issues to consider when setting our current operating baseline. The second stage in the design of the project supply chain consists of charting our current operating state versus the desired goal.

Page 118 Table 5.2 Steps in Developing a Project Supply Chain 1. Vendor Analysis •

What processes do we currently perform that could be framed out?

•

Who do we get supplies from?

•

Who are reasonable alternative to these vendors?

•

What criteria do we use to make vendor decisions?

•

How often do we review the status of vendors in terms of their prices? Reliability? Quality? Responsiveness?

2. Goals in Creating a Project Supply Chain •

What goals are driving our decision? Cost containment? Long-term relationships? Market penetration?

•

How will we measure our progress?

3. Modeling the Supply Chain •

How often do we reevaluate our suppliers?

•

Have we modeled or run simulations to determine optimal supply chains in terms of time (speed of response), money (cost efficiency), or quality?

•

Is the supply chain understood by all relevant project organization members?

4. Distribution Channel Analysis •

How do we handle product transfer currently?

•

How do we want to handle product transfer?

•

Do we have an idealized vision of product transfer?

•

How often do we contact or communicate with the project clients?

5. System Control •

How do we know when problems are occuring?

•

Do we have any proactive methods for staying ahead of problems or do we react to them as they occur?

•

Have we identified primary problem solvers in our organizations in case of trouble?

•

Do we have clear lines of communication into our vendor and client organizations when problems threaten?

•

How often do we audit the supply chain to find ways to improve its efficiency or quality?

Page 119 What do we hope to achieve through PSCM? Is our primary goal one of cost containment or increased flexibility and productivity through benefits following from creating long-term vendor/client relationships? What trade-offs are we willing to make between these goals? For example, we might find that in our desire to contain costs, we are making too many decisions based solely on the bottom-line, eventually alienating both our vendors and our client base who are weary of observing how every project decision becomes a battle over money. Finally, Table 5.2 suggests some of the important questions we must continually ask as we first create and then hone our project supply chain. We start with a realistic statement of project organization goals. The process then evolves through an internal analysis, a series of external analyses aimed at our supply chain partners and customers, and concludes with a comprehensive control system set in place to monitor the activities and offer methods to remain proactive. Proactive means two things: (1) constantly looking for ways to improve the supply chain process, evaluating new potential partners, and solidifying working relationships with long-term vendors and customers, and (2) identifying potential problem areas before they become serious.

CHALLENGES IN EFFECTIVE PROJECT SUPPLY CHAIN MANAGEMENT Creating an effective project supply chain is not an easy process. It requires first an intimate understanding of our current operations, our strengths and weaknesses, as well as a clear view of competition and customer needs. To maintain such a supply chain in a project organization, a number of challenges continually confront top management.8 Let us consider some of these challenges and the effects they have on project management.

Page 120

Approved Vendors The basis for supply chain management lies in identifying a group of approved vendors that meet the criteria we have set to our partners. Among the criteria of concern here are the quality of their processes and products as well as their attitudes and operating procedures. In establishing and maintaining the supplier network, quality standards, such as ISO 9001, offer a great tool by setting the basic requirements and involving regular third-party audits to keep up the initially achieved level.

Effectively Tracking Work in Process One of the long-time challenges associated with project management is having a clear view of the project’s status at any point in time. With PSCM, this problem is even more confusing because effective organizations are tracking not only their own processes, but also the workflow of their vendors. Our company’s planning must take into consideration the work of the vendors whose supplies are critical to our subsequent success. As Figure 5.3 shows, project tracking and control begin much earlier in the project development, prior even to procurement, during the initial stages of supplier production. In this simple diagram, we have labeled only three external vendors whose supplies we need to develop our project. Note, however, that it may be appropriate to sequence and schedule the delivery of their materials at different points throughout the work-in-process at our site. Rather than stockpile potentially huge quantities of supplies prior to initiating our own project, it is often more efficient to phase delivery of required materials when needed. As research on just-in-time inventory (JIT) shows, companies can save money through more efficient workflow control. Furthermore, sequenced delivery of materials makes it easier to adopt the changes that may

Page 121 follow the concurrent engineering and fabrication often necessary in fast-track project deliveries. The tradeoff is the necessary investment of resources in scheduling and tracking vendor deliveries to minimize disruptions to our planned work sequence and project development schedule.

Understanding Stakeholders and Their Needs Project stakeholders are any individual or group, either internal or external to the organization, that has the potential to affect the project’s development or be affected by it. These people are referred to as stakeholders to the project. For example, the project to develop a nuclear power plant in Indiana Dunes, Indiana, by Northern Indiana Public Service Company was derailed by a coalition of concerned stakeholders, including environmental groups, community action groups, political leaders, and so forth. Further, oil field developments often involve combinations of partners consisting of major, independent, and national oil companies all with their own interests which may effect both the final product and the project development. Other examples abound, of internal organizational stakeholders in top management who worked to torpedo (or help) a project they viewed as dangerous (or beneficial) to their agendas. Any project will only succeed to the degree a project organization has identified stakeholders, determined their needs and preferences, and actively taken steps to address their needs or ameliorate their concerns. This point is particularly relevant in PSCM because the pool of stakeholders for our projects is often wider than many organizations are used to dealing with. Vendors and other raw material suppliers must be considered, as well as the various end-user groups for whom our product has been developed. Project stakeholder analysis takes on a higher level of complexity and importance with

Page 122 PSCM because their potential to impact the project both positively and negatively are that much greater. We have devoted a chapter in this book to a more in-depth discussion of the role of stakeholder analysis and the steps necessary to conduct an effective review of our project’s stakeholders.

Benchmarking Superior Service and Inventory Control An area of increasing interest in project management research is the practice of benchmarking best practices as a model for improving project development. Benchmarking occurs when one firm recognizes both their difficulties with project development and a competitor’s expertise in performing these activities. That company would then set out to copy the rival’s procedures. Alternatively, when confidentiality is important or individual firm data is unattainable, it may be appropriate to create a database of several companies, compare their procedures and then extrapolate best practices from industry standards. In a number of settings, project management researchers have been conducting industrywide surveys in an effort to identify these best practices as a benchmarking target for other, less project-savvy firms to emulate.9 Benchmarking service and inventory control can be a helpful, but challenging process in PSCM. It is often difficult to ascertain appropriate levels of client interaction or truly accurate vendor or work-flow project control. Establishing a benchmarking point involves identifying successful competitors and emulating their practices, vendor contacts, inventory and raw material levels, project procedures, and so forth. The benefit of benchmarking is that it gives firms guidelines and targets to shoot for; if effective project practices involve establishing a series of vendor relationships with companies in foreign countries, for example, our firm should look to develop similar ties. Likewise, if carrying certain levels of raw

Page 123 materials are cost effective for other firms in our industry, we should alter our work-in-process levels to reflect these standards. It is important to note one caution in the use of benchmarking and best practice analysis. The flaw with establishing best practices based on an industry leader is the supposition that the rival firm’s procedures, once established, remain static. In other words, we must recognize that during the time a laggard firm works to catch up with a leader’s best practices and benchmarks them, the industry leader has not been idle. They have also been refining their processes and likely, developing entirely new approaches. Consequently, benchmarking firms are always attempting to hit a moving target. By the time they reach point A, the industry leader has already moved on to point B. The best practices of 1995 are not the best practices of 2000 nor of 2010. In essence, it is vital to observe the marketplace. Are we still in the same game or are the rules and customer drivers changing?

Operational Planning and Control One of the difficult steps in effective PSCM is planning the flow of materials and other resources across the project’s development to avoid bottlenecks and other problems that can choke down development and increase schedule times. Project schedules are developed with several suppositions, one of which is that resources necessary for the project will be available when they are needed. To ensure that these resources are in place, careful resource planning is key. Many examples exist of organizations that failed to adequately plan for resources to be available when they were required. The problem is exacerbated by the inclusion of multiple external suppliers. A simple rule of thumb suggests that the more complex and integrated the supply chain, the greater the potential for problems to occur, if the process is left unmanaged. Further, because most projects are developed sequentially, errors in supply at one

Page 124 stage have a ripple effect downstream, leading to increased costs caused by accelerations and changes in the planned work sequence, and in the worst case, delay of the whole delivery. The key is accurate and systematic planning and control. Indeed, an entire academic discipline has arisen around the processes for planning the supply chain, from procurement of materials and resources through to fabrication and distribution. Firms that work to plan and control resource flows derive great benefits from supply chain management while companies that are still in the learning mode are likely to continually experience new and greater difficulties.

What-If Analysis Supply chain management is the management of a series of complex, interrelated linkages between one firm and potentially numerous suppliers. To make this process work, we must recognize that there is no point at which the process works optimally. Project supply chain management is not a summit we reach, it is a slope we continually climb. We get better at it—so does our competition. We lock in reliable suppliers—one of them goes bankrupt. And so the process goes. Continuous fine-tuning, asking “What if?” questions, and tweaking the system are all evidence of effective companies and their approach to the supply chain methodology. Among the sorts of ‘‘What if?” questions that we should continuously consider are the following.10 l l

l

Changes in market demand for our products due to competitive pressure or mature product lines. Changes in the design of the supply chain network (What happens when our old chain is disrupted?). Changes in technology make old suppliers inadequate or recommend new options.

Page 125 l

l

Improvements to shipping and other logistics costs expand the pool of potential suppliers and customers. The continuous desire to make and ship our projects faster, cheaper, and with greater flexibility.

CONCLUSION Project supply chain management is not an easy process, nor should it be approached without sufficient understanding of the steps involved and the organizationwide commitment to the methodology that is required for it to work. Its benefits, however, are obvious: integrated, logical supplier networks, clear links to customers, a coordinated efficiency to the flow of materials (raw, financial, and human) to the project as needed for development. Supply chain management takes the old discipline of project planning and expands it significantly. Whereas in the old days, project planning often meant simply scheduling, with a bit of risk analysis or work breakdown structure thrown in, PSCM means that planning takes on a whole new level of complexity. Planning begins outside of the project and even the project organization; it begins with suppliers. It analyzes their potential contributions, selects those that will best benefit the project organization, and coordinates their deliveries. Further, PSCM creates a new set of linkages directly with customers, at the end of the supply chain. In the new system, project planning is no longer an internal process involved simply in project development, it is a totally coordinated exercise with explicit links to the rest of the organization, vendors and customers. Properly established and continually monitored and upgraded, PSCM offers firms a new and powerful way of maintaining project workflow. The initial time spent up-front establishing the supply chain will more then pay for itself downstream, as projects come to market cheaper and with more direct customer feedback and acceptance.

Page 126

NOTES 1. D.J. Thomas and P.M. Griffin. (1996). “Coordinated Supply Chain Management,” European Journal of Operational Research, 94, 1–15. 2. J.J. Coyle, E.J. Bardi, and C.J. Langley, Jr. (1996). The Management of Business Logistics. Minneapolis, MN: West. 3. B.T. Barkley and J.H. Saylor. (1994). Customer-Driven Project Management. Burr Ridge, IL: McGraw-Hill. 4. F.M. Biddle. (1997). “Boeing Plans $1.6 Billion Pretax Charge—Output Bottlenecks Cited,” Wall Street Journal, October 23, p. 1. 5. E. Goldratt. (1999). “The Theory of Constraints Applied to Projects.” Address at the Nordnet conference, Helsinki, Finland. 6. See note 1. 7. D.R. Towill. (1996). ‘‘Industrial Dynamics Modeling of Supply Chains,” Logistics Information Management, 9(4), 43–56. 8. H.L. Lee and C. Billington. (1993). “Material Management in Decentralized Supply Chains,” Operations Research, 41(5), 835–847. 9. R. Gareis, M. Huemann, and B. Schaden. (1998). “Best PM Practice: Benchmarking of Project Management Processes,” in A. Hauc et al., ed., Proceedings of the 14th World Congress on Project Management. Ljubljana, Slovenia, pp. 799–808. 10. See note 8.

Page 127

CHAPTER SIX VALUE CHAINS AND PROJECTS Value chain management (VCM) offers a unique and highly promising approach to the management of projects. More than simply an offshoot of supply chain management, VCM recognizes the goal of finding ways to create the highest value for the customer. Indeed, the whole focus is aimed at redirecting the activities of the organization toward finding maximum benefit for the organization’s customers. This customer-first mentality means that the primary pursuit must be value creation for the client. From providing this value, all other traditional forms of business success follow: profitability, growth, and long-term survival. When we look first to take care of our own bottom-line, we may be tempted into behaviors that short-change the customer (e.g., using cheaper quality materials to save money). On the other hand, when our highest goal is to take care of our customer, everything else falls into place. While project supply chain management takes an efficiency perspective as its primary goal, either through cost containment, greater vendor responsiveness, or faster project delivery, value chain management is aimed at enhancing organizational effectiveness.1 This effectiveness comes in the form of responding rapidly and fully to customer needs; that is, finding ways to create value in the customer’s operations. Redirecting the focus to the customer and their

Page 128 operations forces organizations to look externally, to be more in tune with market needs and customer expectations rather than simply operating with goals of finding ever-greater internal efficiencies. As we noted in Chapter Two, one danger of an unregulated approach to PSCM is to make all decisions on the basis of satisfying or enhancing the internal efficiency by which our organization creates projects. Making cost containment decisions that can save us money will often lead to serious downstream problems with the customers who are naturally dissatisfied with poor project quality. Likewise, when we make all vendor relationship decisions purely on a basis of who can quote us the lowest price, we know that eventually quality and our organization’s reputation are going to suffer. The danger of constantly demanding better prices from our vendors, simply because we are in a position to do so, is damaging in the long term. As we demand greater efficiencies and price adjustments, the vendors in turn must pass along similar demands to their raw material suppliers to maintain their own profit margins. As Tom Peters and others have argued, you cannot continue to mine this shaft indefinitely; eventually quality will reach the unacceptable level and every link in the supply chain will suffer accordingly.2 Think of the process as a death spiral. Figure 6.1 shows the impact on quality of making supply chain relationships depend purely on price. Every link in the supply chain is naturally looking to maintain their profit margins. Accepting the lowest bids for parts forces our vendors to go to their vendors and make the same demands. Those second-level vendors must then make the same demands further upstream, and on it goes. Eventually, the result is that the raw material provider must sacrifice quality in the name of profit margin. Everybody wins in the short-term because everyone has kept profit margins in line. Everyone loses in the long-run, however, because the poor quality that has been introduced will ultimately affect the project organization’s ability to create viable products, the kind that bring customers back for repeat business.

Page 129 Figure 6.1 Price Squeeze

Value chain management recognizes the flaws in an efficiency-only mentality. When our highest goal is maximizing internal efficiencies, we have a natural temptation to subordinate all of our operations to this single goal. As we noted, subordinating operations to efficiency may work in the short run; it will improve margins, reduce costs, and keep discipline among our vendor chain. However, it opens a Pandora’s box of long-term problems. When our chief goal becomes the enhancement of value to our customer, it signals an enormous shift in operational thinking, a move away from efficiency-at-any-cost to a view based on satisfaction at any opportunity.

WHERE DOES VALUE COME FROM? A key question in value chain management is: What is the nature of value? How is it created? How is it communicated and passed along?

Page 130 The answer to the first question is emphatic—value is determined by the customer. Companies that seek to improve their operations through value chain management are doing so because they recognize that their long-term viability does not rest within their own control, it is the result of creating a product or service that customers recognize as one that adds value to their operations. Therefore, if my customers perceive value in terms of low-cost vendor/supplier materials only, as a potential vendor, I enhance my chances of gaining their business through creating internal cost efficiencies that allow me to compete for their business on the basis of price. On the other hand, if a potential customer signals that they perceive value in terms of additional factors, such as low risk, flexibility, or ability to come up with innovative solutions to address their needs, I create value in their eyes through demonstrating a willingness to lock in a long-term relationship. I show willingness to work with their quality assurance people, develop and maintain continuous lines of communication, and so forth. The key lies in recognizing that my actions are in response to their perception of value. I affect their value chain by understanding their fundamental needs and restructuring my operations accordingly. Imagine the implications of this model. First, because value is identified by the customer, it requires my company to be customer-oriented, rather than internally driven. Success lies in our ability to identify and respond to customers. While this point seems obvious, it still forces serious reorientation on the part of those organizations that have been known for maintaining an attitude of “Don’t tell us what you want, let us tell you what you need.” Second, the model suggests that effective organizations are those that are agile enough to constantly remake themselves to fit the mold a customer seeks. A recent article noted the success American Standard Co. has had in reinventing themselves to appeal to different customers.3 Through better customer needs assessments, American Standard has been able to reorient their traditional, functional structure to one that was able

Page 131 to respond directly to customer needs. They rebuilt relationships with their chief suppliers, retooled their manufacturing processes to better service customer needs, and communicated these goals through massive retraining of their workforce. Through it all, the watchword has been customer satisfaction. Recognizing and quickly responding to alternate demands of various customers is essential; if one customer seeks price breaks, we must emphasize our efficiency. If another customer wants the freedom to make significant design changes through development, we must demonstrate a strong and helpful engineering staff. Doing the same old thing the same old way is a fine recipe for maintaining strong internal efficiencies but it is a poor approach for positively impacting customers with their various and different needs. It is the equivalent of Henry Ford’s famous statement about buying a Model-T, “You can get one in any color you want, as long as it’s black!” Dell Computer Corporation represents a good example of the flexibility needed to contribute to the customer’s perception of value. In the computer industry during the decade of the 1990s, speedy service and flexibility became hallmarks of value for both private and corporate customers. Rather than simply buying a standard model off the shelf, everyone wanted the opportunity to create their own computer configuration based on personal needs. Dell capitalized on this market opportunity by developing the first full-scale sales and service network designed to give customers maximum say in configuring their own systems. Coupled with speedy delivery, Dell’s idea led to its overtaking Compac as the world’s largest seller of personal computers. Figure 6.2 shows a simplified schematic identifying some of the keys links in the value chain configuration. Note that the chain is not simply a linear series of connections from site to site, but a complex set of interactions among suppliers, partner firms, sales, service support, and customers. In a project firm producing highly

Page 132 Figure 6.2 SCPM Distribution

technical products, it is not uncommon to find fifth and sixth tier suppliers even further upstream. Managing all the complex interactions among these firms, both upstream from the project and further downstream during development and project transfer, is a difficult process. When our needs are not simply to ensure channel efficiency, but relationship effectiveness, the project firm that successfully manages its value chain must be constantly alert to supplier requirements and relationships, methods for enhancing logistic support, and opportunities to promote a relationship-based link to its customers. General Electric goes to extraordinary lengths in managing their value chain. Even though just one division within the overall corporation may have thousands of external vendors, GE works with these vendors individually, not just to ensure that price relationships remain stable, but through offering feedback on vendor business operations and other technical support. Creating a stable value chain means maintaining a stable base of supply just as much as it means ensuring optimal customer relationships. To best understand the idea of value chain management, it is first necessary to take a detour into a discussion of how organizations have traditionally measured project success. As any behavioral scientist can tell you, one of the few aspects of human nature we all

Page 133 agree with is the assumption of motivation based on reinforcement—people tend to repeat behaviors for which they are reinforced. This idea is nowhere more apparent than in a discussion of project success.

UNDERSTANDING PROJECT SUCCESS How do we know when a project is successful? When it is profitable? If it comes in on budget? On time? When the technology we are developing works? When we achieve our long-term payback goals? It is ironic that project management continues to have great difficulty in identifying an acceptable and mutually agreed-upon definition of success. Perhaps our difficulties in defining success are similar to Justice Potter Stewart’s famous description of pornography (“I know it when I see it”). There has always been great difficulty in coming to a consensus on what we mean by project success. In Chapter Three, we discussed the basic elements of the traditional triple constraint model. It bears repeating here: l l l

Time—Did the project come in on schedule? Cost—Did the project come in on or under its budget? Performance—Does the project perform according to the technical specifications we originally developed for it?

The problem with this model goes deeper than its lack of any understanding of the customer. While well-understood and relatively easy to measure, these traditional measures also present some serious difficulties for project organizations. These difficulties arise as a result of the natural tendency toward operating in ways that are rewarded by this triple constraint model, including:4 1.

The tendency to sacrifice external concerns for internal performance. In other words, when a company measures their

Page 134 performance purely in terms of their performance, the natural by-product is to discount or minimize legitimate customer concerns. For example, if a project manager gains maximum corporate credit for simply bringing in projects under budget, it generates a temptation to continually cut corners or make decisions leading to a poorer project in order to improve margins. The irony is that when using this model, it is possible to create a successful project that does not attempt to directly satisfy the customer. While the company will be pleased with the result, the customer could end up with a product that is substandard. 2.

The potential to develop adversarial relationships with contractors. As we noted in Chapter One, a common problem that underlies the contractor-subcontractor (subs) relationship is the desire of the various subs to squeeze every last drop of profit out of the contracted relationship. The irony is that this difficulty chiefly arises from prejudicial attitudes by both the contractor and the subs. When the up-front assumption from the project contractor is that all subs are out to gain as great an advantage as possible at the expense of the contractor, it causes contractors to go into a project relationship with a firm degree of distrust. From this point, any disagreements with subs merely solidifies, in their minds, this preconceived attitude.

3.

The habit of treating all project relationships as short term, rather than focusing on long-term partnership building. A common result from the traditional success approach is to treat each project as a discreet operation. To a degree, there is nothing wrong with this mentality—certainly projects are one-shot activities. However, the more important long-term relationships between customers and contractors are then often ignored. Once a subcontractor has completed their phase of the project, communication breaks down and both parties go their own ways.

As we noted in Chapter Three, the inclusion of a concern for the client and their satisfaction with the project alters our thinking in

Page 135 a profound way. This additional constraint creates an important shift in the previous focus of the triple constraint, in which project success was essentially an internal mechanism; that is, it was addressed and ultimately assessed primarily as a function of internal operating efficiency. (Did we keep a lid on development time and costs? Have we made sure it works?) Now, the focus altered to include our recognition that internal efficiency (doing it right) was not a sufficient goal in and of itself. Efficiency is only useful in tandem with some measure of customer satisfaction (e.g., sales, repeat business, longterm contract relationships, and so forth). It is in the court of public opinion (the customer) that we determine if we are getting the project done correctly. “Doing it right” was never a substitute for ‘‘getting it right.” As a result of the drawbacks with traditional project success assessment, increasingly, companies are shifting their focus to including customer satisfaction as a fourth success constraint. The inclusion of customer satisfaction acknowledges a fundamental truth in project-based firms: Successful projects are only truly successful if they are seen that way through the eyes of the customer. The obvious benefit from this thinking is that it naturally moves project firms toward an externally focused mindset, rather than reinforcing excessive concern for internal control processes based on simply adhering to the triple constraint. The underlying motivation for such a refocus has been an acknowledgment of the importance of VCM in successful project implementation.

VALUE CHAIN ANALYSIS In trying to understand the implications of the VCM system, it is useful to refer to Michael Porter’s value chain model.5 Value chain analysis suggests that companies can compete most effectively if they clearly understand how they help create value to their customer’s business activity cycle. To be successful, value chain analysis requires

Page 136 an organization not only to understand its own strengths and weaknesses, but those of potential customers. In this manner, they are better able to address and appeal to the most critical aspect in the customer’s business operations. For example, many companies routinely engage in value chain analysis to tailor their project bidding to areas in which they can significantly enhance their clients’ operations. Knowing what key measures drive my customer’s operations allows me to make optimal bidding decisions; for example, if reliability is the key decision criteria for a potential customer, I will develop a bid that may be more expensive than competitors, but will focus on my strengths in the area of on-time delivery. There are four distinct steps in performing a value chain analysis: 1. Construct the value chain of the client. It is imperative that the project organization clearly understand their role in the customer’s value chain. Each firm is composed of a sequence, or chain of activities, beginning with inputs bought from suppliers and ending with delivery to the customer, and after-sales support. (See Figure 6.3.) Activities define the process by which a firm creates value through transforming raw materials into finished goods or services. It is important to note that it is possible to attain competitive advantage in any activity in the chain; it is not necessary that all activities be _superior to the competition. Let us consider a direct example: Figure 6.3 shows a simplified value chain for an oil company customer. Note that the project organization’s contribution to this company’s value chain lies primarily within its operations activities—the project firm provides superior quality and lower total costs and risk by effectively implementing the engineering, design, and fabrication of the facility under construction. To effectively develop a value chain strategy, significant internal and external analysis is key; an organization simply cannot attempt to add value to a potential customer’s operations until they are fully aware of the areas in which they can most significantly affect the

Page 137 Figure 6.3 Value Chain Analysis

Source: Adapted from M. Porter (1985). Competitive Advantage. New York: Free Press.

Page 138 client. Further, to effectively do so, the first stage lies in a clear understanding and acknowledgment of those activities our organization does well (our value-added operations) and those we do not perform as well as our competitors. While we can construct the value chain of our customers, until we know and work to improve our own strengths and weaknesses, we cannot expect to successfully influence their operations. Finally, we must also recognize the potential to affect both on-going operations (the primary activities) as well as support activities. Quality value chain analysis offers organizations direct clues as to where they can most effectively bring their expertise to bear in adding value to customers. Our project firm example uses its superior technology and customer service traditions to impact their clients’ operations and outbound logistics links. Another organization may trade upon their worldwide distribution channels or technical know-how to offer value in the areas of inbound logistics and aftersales support, respectively. The key lies not in trying to cover all the bases (every element in a customer’s activity sequence), but rather, to seek specific areas of expertise where we can make our competitive advantages most felt. 2. Identify activities and linkages that are superior compared to the competition. Activities in which the client has a cost advantage over the competition and activities that allow the client to produce a unique product or service are drivers of competitive advantage. It is important to discover whether the customer firm is driven primarily by low cost or product or service differentiation advantage. Understanding the customer’s focus will enable the project organization to appreciate the project’s impact and help guide choices that best fit the client’s strategy. At the same time, project subcontractors need to engage in a straightforward assessment of their own strengths and weaknesses to ensure a close fit between what they do well and what the customer seeks.

Page 139 3. Identify activities and linkages that are inferior compared to the competition. What are the areas in which our firm operates at a competitive disadvantage? These activities are a drag on the performance of the firm. For each inferior activity, a superior activity is necessary to offset the effect. Overall performance is enhanced when these activities are improved to, at the very least, meet the capability of the competition. Finally, it is important to note that a successful project need not create a competitive advantage. It can be equally effective through eliminating a disadvantage. As long as the client has a source of advantage in other activities, they will reap superior returns when the comparative disadvantage is corrected. 4. Target activities and linkages with high potential for impact. Communicate to the client project options and alternatives, in order to improve activities to create a new competitive advantage(s), enhance existing competitive advantage(s), and improve activities to eliminate competitive disadvantage (s). Step 4 becomes the key starting point to developing a protocol for partnering with clients in order to enhance their business operations. The better able the project organization is at helping customers increase competitive advantage, the greater their own strategic position becomes vis à vis their competitors. In effect, we seek to give other customers a compelling reason to select us as a supplier. One important key to success lies in a project organization’s ability to offer the client competitive advantage through its own commitment to project excellence. This is accomplished in two ways: first, by viewing project success through the clients’ eyes, rather than based simply on historical parameters of time, budget, and specification. Second, successful project firms actively seek to redefine themselves as partners, rather than simple subcontractors. This partner relationship can be reinforced by the attention the project firm pays to the overall project, rather than simply their

Page 140 contracted subcomponent. In developing design and engineering aspects of their component of a larger project, our example project firm also looks to improve the overall project through close collaboration with other subcontractors (those contracted to develop other elements of the project) to give the customer enhanced value. This relentless pursuit of project excellence is based on a philosophy that suggests that where the technology is to a great extent undifferentiated, what characterizes competitive advantage is often superior service through project development in active partnership with client firms.

REVISITING PROJECT SUCCESS USING VALUE CHAINS Value chain analysis allows us to sharpen our understanding of what constitutes a successful project for most organizations. Figure 6.4 demonstrates an extension of some of the ideas we offered in Chapter One. Note that traditional measures of project success are still Figure 6.4 How Do We Measure Customer-Based Project Success?

Page 141 relevant, but increasingly, only as an internal reference to how well we run our project’s development cycle. These measures tend to obscure the further we travel down the timeline toward completion and transfer of the project to the customer. Here we have to consider additional, primarily external issues, in our analysis. Technical validity, asking the question of whether the project passes its technical hurdles, clearly remains a critical factor in successfully completing the project. Other issues of organizational validity and effectiveness emphasize our external refocus. As value chain management emphasizes, the customer is the driver in determining value in a project. Consequently, after passing a series of internal and external checks, the project is viewed as successful, right? Not in this model. The goal for project firms has always been and remains acquiring future business opportunities, not just from past customers but through learning appropriate lessons that can be employed in future operations with new customers. Future business is the goal. The key to gaining future business lies in our ability to satisfy customer needs, not simply a series of internal checks and balances.

CONCLUSION One important message that this new model of project success should transmit is the complexity of what success really encompasses. Rather than using the old, outmoded triple constraint as a metric, it is vital to raise our standards to consider a far wider, and more important focus. Make no mistake, if our company’s highest goal is simply to get the project done fast and cheaply, perhaps a traditional triple constraint approach is sufficient to model our behavior and rate performance. On the other hand, if we have set larger goals, ones that challenge us to look toward long-term viability, customer satisfaction, and corporate renewal, we must recognize the greater challenges of customer-based project success.

Page 142 The key lies in identifying the prevailing goal for our company. If that goal is long-term survival, then the path we must travel to attain it is equally clear.

NOTES 1. J.H. Sheridan. (1999). “Managing the Value Chain for Growth,” Industry Week, September 6, 50– 66. 2. Tom Peters. (1994). The Tom Peters Seminar. New York: Random House. 3. See note 1. 4. J.K. Pinto and P.D. Slevin. (1988). “Project Success: Definitions and Measurement Techniques,” Project Management Journal, 19 (1), 67–72; A.J. Shenhar, O. Levy, and D. Dvir. (1997). “Mapping the Dimensions of Project Success,” Project Management Journal, 28 (2), 5–13; J. Wateridge. (1998). “How Can IS/IT Projects Be Measured for Success?,” International Journal of Project Management, 16 (1), 59–63. 5. M. Porter. (1985). Competitive Advantage. New York: Free Press.

Page 143

CHAPTER SEVEN PROJECT STAKEHOLDER ANALYSIS From the previous chapters, it should be clear that the starting point to developing a systematic program for customer-based project management requires a clear understanding of our customer base. Creating the goals for project supply chain or value chain management are a necessary activity. However, these goals are established in relation to a clearly identified customer/supplier base. In other words, until we have an understanding of the key stakeholders with the potential to affect our organization’s operations, it is impossible to progress very far down the path of customer-based project management. This chapter examines the key elements in project stakeholder analysis, a necessary first-step to improving our ability to manage projects well in a difficult and changing environment. Past organizational research and, indeed, common sense tells us that organizations and even managers within those companies cannot operate in ways that ignore the external effects of their decisions. No manager makes decisions exclusive of consideration of how those decisions will affect external groups.1 One way to understand the relationship of project managers and their projects vis à vis the rest of the organization is through employing stakeholder

Page 144 analysis. Stakeholder analysis is a useful tool for demonstrating some of the seemingly unresolvable conflicts that occur through the planned creation and introduction of any new project. An organizational stakeholder refers to any individual or group that has an active stake in the activities of an organization.2 When a company makes strategic decisions, they will have major implications for a number of stakeholder groups, such as environmental watchdog groups, stockholders, and government regulatory bodies. Stakeholders can impact on and are impacted by organizational actions to varying degrees.3 In some cases, a corporation must take serious heed of the potential influence that some stakeholder groups are capable of wielding. In other situations, a stakeholder group may have relatively little power to influence a company’s activities. The process of stakeholder analysis is helpful to the degree that it compels firms to acknowledge the potentially wide-ranging effects that their actions can have, both intended and unintended, on various stakeholder groups.4 For example, the strategic decision to close an unproductive manufacturing facility may make good business sense in terms of cost versus benefits that the company derives from the manufacturing site. However, the decision to close the plant has the potential to unleash a torrent of stakeholder complaints in the form of protests from local unions, workers, community leaders in the town affected by the closing, political and legal challenges, environmental concerns, and so forth. The prudent company considers the impact of stakeholder reaction as they weigh the sum total of likely effects from their strategic decision. Just as stakeholder analysis is instructive for understanding the impact of major strategic decisions within the project environment, there is also a very real concern for the impact that various project stakeholders can have on the project development process. This relationship is essentially reciprocal in that the project team’s activities can also impact the external stakeholder groups.5 For example, the project’s clients, as a group, once committed to a new project’s

Page 145 development, have an active stake in that project being completed on time and living up to its performance capability claims. The client stakeholder group can impact project team operations in a number of ways, the most common of which are agitating for faster development, working closely with the team to ease project transfer problems, and influencing top management in the parent organization to continue supporting the project. On the other hand, the project team can reciprocate this support through actions that show their willingness to closely cooperate with the client and effect smooth transition of the project to its intended user groups. The key point is that project stakeholder analysis solidifies the fact that in addition to considering all the managerial activities involved in project development, project managers need to be aware of the ways in which attaining the project’s goals can impact a host of external stakeholders outside of their authority. Further, project managers must develop an appreciation for the ways in which these stakeholder groups, some of which have considerable power and influence, can affect the viability of their projects. There is an old saying, ‘‘Never get the accountant mad.” The obvious logic behind this dictum is that cost accountants can make the project manager’s life easy or very difficult, depending on the format, frequency, and detail of the reports they request to monitor and control project expenditures. In this chapter, we explore the concept of stakeholder analysis as it forms a backdrop for customerbased project development and implementation. Stakeholders, while having varying levels of power and influence over the project, nevertheless have the potential to exert a number of significant demands of project managers and their teams. This problem is compounded by the fact that the nature of these various demands quite often places them in direct conflict with each other. That is, in responding to the concerns of one stakeholder, project managers often unwittingly find themselves having offended or angered another stakeholder with an entirely different

Page 146 agenda and set of expectations. The challenge for project managers is to find a way to balance these various demands in order to maintain supportive and constructive relationships with each important stakeholder group.

IDENTIFYING PROJECT STAKEHOLDERS In identifying project stakeholders (Figure 7.1), we need to go beyond the project organization’s internal environment to determine which external stakeholder groups can impact our operations and the degree to which they are able to influence the project’s implementation. Internal stakeholders are a vital component in any stakeholder analysis and their impact is usually felt in relatively positive ways; that is, while serving as limiting and controlling influences, most internal stakeholders do want to see the project developed successfully. On the other hand, external stakeholder groups may operate in a manner that is hostile to project development. Consider Figure 7.1 Project Stakeholders

Page 147 the case in which a city is seeking to upgrade its subway system, adding new lines and improving facilities. There is a strong potential for those who are interested in preserving antiquities to actively resist the completion of such a project if they perceive that the tunnel digging could be destroying valuable artifacts. Cleland refers to these types of external stakeholders as “intervenor” groups and demonstrates that they have the potential to pose a major threat to the successful completion of projects.6 Among the set of project stakeholders that project managers must consider are included: Internal l l l l

Top management Accountant Other functional managers Project team members

External l l l l

Clients Competitors Suppliers Environmental, political, consumer, and other groups

Let us briefly consider the demands that these stakeholder groups commonly place on project managers. Although we will start with top management, it is also important to note that top management, as a single entity, may be too simplistic a classification for this stakeholder group. Within top management there are differing degrees of enthusiasm for and commitment to the development of a particular project. Likewise, any environmental intervenor groups are likely to be composed of a number of different factions, with their own agendas and priorities. In other words, a good deal of conflict and difference of opinion will exist within any generalized group.

Page 148 Nevertheless, this approach is useful because it demonstrates the inherent nature of conflict and other pressures arising from project development as it exists between stakeholder groups, rather than within any group.

Clients Our focus in this book rests chiefly with maintaining and enhancing client relationships. In most cases, concerning both external and internal clients, the project deals with an investment. The longer the project implementation, the longer the money invested sits without creating any returns. That is why the clients are concerned with receiving the project as quickly as they can possibly get it from the team. As long as costs are not passed on, clients are seldom overly interested in how much expense was involved in the project’s development. On the other hand, the project, in many cases, started before the client need was fully defined. Product concept screening and clarification will often be part of the project scope of work. This is the reason why the customers seek the right to make suggestions and request alterations in the project’s features and operating characteristics for as long as it is possible without jeopardizing their schedule. The customer feels, with justification, that a project is only as good as it is acceptable and is used by them. As a result, this sets a certain flexibility requirement and requires willingness from the project team to make themselves amenable to specification changes. When dealing with client groups, it is erroneous to simply use the term client under the assumption that it refers to the entire customer organization. As Figure 7.2 shows, the reality is often far more complex. When an organization is charting a stakeholder management strategy for dealing with a customer, that customer must first be more specifically identified. A client consists of a

Page 149 Figure 7.2 Stakeholder Analysis of a Customer Organization

number of internal interest groups in many cases with highly different agendas operating. For example, our company can readily identify a number of distinct clients within the customer organization, including the top management team, engineering groups, sales teams, on-site teams, manufacturing or assembly groups, and so forth. Under these circumstances, it becomes clear that the process of formulating a stakeholder analysis of a customer organization is a potentially highly complex undertaking. Our challenge is further complicated by the divergent expectations and demands of these various customer stakeholder groups. Preparing a presentation to deal with the customer’s engineering staff will require highly technical information and solid specification details. On the other hand, the finance and contractual people are looking for entirely different sorts of information. As a result, formulating stakeholder strategies requires us first to acknowledge the existence of these various client stakeholders, and then a coordinated plan for uncovering and addressing each group’s specific concerns to their satisfaction.

Page 150

Competitors Competitors can be an important stakeholder in that they are materially affected by the successful implementation of a project. Likewise, should a rival company bring a new product to market, the project team’s parent organization could be forced to alter, delay, or even abandon their project. In assessing competitors as a project stakeholder group, project managers should try and uncover what information is available concerning the status of potential rival projects being developed within competing firms. Further, where possible, the lessons learned by competitors can be an important and useful source of information for a project manager who is initiating a similar project in another company. If a number of severe implementation problems occurred within the first organization’s project, that information could offer valuable lessons to the other project organization in terms of what activities or steps to avoid in their own situation.

Suppliers As we noted in Chapter Five, suppliers refers to any group that provides the raw materials or other resources that the project team needs in order to complete their project. When projects require a significant supply of externally purchased components, it behooves the project manager to take every step possible to ensure that steady deliveries will continue. In most cases, this is a two-way street. First, the project manager has to ensure that each supplier will receive timely input that they need to implement their part of the project. Second, he or she has to be able to monitor that the deliveries are met according to the plan. In the ideal case, the supply chain becomes a well-greased machine that automatically both draws the input information from the project team and delivers their products without excessive involvement of the project manager. For example, in

Page 151 large-scale construction projects, project teams must daily face and satisfy an enormous number of supplier demands. The entire discipline of supply-chain management is predicated on the ability to streamline our logistics processes through effectively managing the project’s supply chain.

Intervenor Groups Any environmental, political, social, community-activist, or consumer groups that can have a positive or (more likely) a detrimental effect on the project’s development and successful launch are referred to as intervenor groups.7 That is, they have the capacity to intervene in the project development and force their concerns to be included in the equation for project implementation. There are some classic examples of intervenor groups curtailing major construction projects, particularly within the nuclear power plant construction industry. As federal, state, and even local regulators decide to involve themselves in these construction projects, they have at their disposal the legal system as a method for tying up or even curtailing projects. Prudent project managers need to make a realistic assessment of the nature of their projects and the likelihood that one intervenor group or another may make an effort to impose their will on the development process. In fact, in some of the better-known project success stories, the construction project manager devoted a great deal of time early in the process to make a stakeholder management assessment of the potential intervenor groups, plotting strategies for finding the most effective and cost efficient ways of dealing with them.

Top Management The top management group in most organizations hold a great deal of control over project managers and are in a position to regulate their freedom of action. Top management is, after all, the body that

Page 152 authorizes the development of the project through giving the initial “go” decision, sanctions additional resource transfers as they are needed by the project team, and supports and protects the project managers and their teams from other organizational pressures. The top management group has, as some of its key concerns, the requirement that the project be timely (the project needs to be out-the-door quickly), cost efficient (they do not want to pay more for it than they have to), and minimally disruptive to the rest of the functional organization.

Accounting The accountant’s raison d’être in the functional organization is maintaining cost efficiency of the project teams. Accountants support and actively monitor project budgets and, as such, are sometimes perceived as the enemy by project managers. We suggest that this perception, while convenient, is incorrect. To be able to manage the project, to make the necessary decisions, and to communicate with the customer, the project manager has to stay on the top of the cost of his project in real time. That is why he needs an efficient cost control and reporting mechanism. Accountants perform an important administrative service for the project manager. Canny project managers will work to make an ally of accountants rather than simply assume that they serve in adversarial capacities.

Functional Managers The functional managers who occupy line positions within the traditional chain of command represent an important stakeholder group. As we noted in Chapter One, most projects are staffed by individuals who are essentially on loan from their functional departments. In fact, in many cases, project team members may only have part-time appointments to the team, while their functional

Page 153 managers expect 40 hours of work out of them per week in performing their functional responsibilities. This situation serves to create a good deal of confusion, conflict of interest and seriously divided loyalties among team members, particularly when their only performance evaluation is conducted by the functional manager rather than the project manager. In terms of simple self-survival, team members are likely to maintain closer allegiance to their functional group rather than the project team. Project managers need to appreciate the power of the organization’s functional managers as a stakeholder group. Functional managers, like the accountants, are not usually out to actively torpedo project development. Rather, they have loyalty to their functional roles and they optimize their actions and utilization of their resources in respect to the measurements that are set to them within the traditional organizational hierarchy. Nevertheless, as a formidable stakeholder group, functional managers need to be treated with due consideration by project managers.

Project Team Members The project team has a tremendous stake in the project’s outcome. As we noted, although they may have a divided sense of loyalty between the project and their functional group, in many companies these team members volunteered to serve on the project and are, hopefully, receiving the sorts of challenging work assignments and opportunities for growth that will motivate them to perform effectively. Just as the top management group and the accountants have their priorities, the project team’s concerns focus on the need for as much time as the project manager can secure for them. Fast-track schedules mean deadlines: Project teams prefer to avoid them. Further, the project team wants the client to lock in to project specifications as early as possible. It is much easier for project team members to operate within this environment if they are reasonably sure that the client will not

Page 154 be changing the specifications and asking for new features or additions to the product downstream.

MANAGING STAKEHOLDERS The simplified management process consists of planning, organizing, directing, motivating, and controlling the resources necessary to deal with the various internal and external stakeholder groups. Figure 7.3 shows a model that illustrates the nature of the management process within the framework of stakeholder analysis and management. These various stakeholder management functions are interlocked and repetitive; that is, this cycle is recurring. As we Figure 7.3 Project Stakeholder Management Process

Source: See note 6.

Page 155 identify and adapt to stakeholder threats, we develop plans to better manage the challenges they pose. In the process of developing and implementing these plans, we are likely to uncover new stakeholders whose demands must also be considered. Further, as the environment changes or as the project enters a new stage of its life cycle, we may be required to cycle through the stakeholder management model again to verify that our old management strategies are still effective. If, on the other hand, we deem that new circumstances make it necessary to alter those strategies, project managers must work through this stakeholder management model anew to update the relevant information.

STAKEHOLDER CONFLICT In addition, we can also illustrate the essential conflict in project development and implementation through the use of stakeholder analysis. For the sake of our discussion, let us assume a project has been undertaken in a company to implement a new information system. Further, there are four identifiable stakeholder groups: the clients, the top management, the accountant, and the manager’s own implementation team. The clients are the most obvious stakeholder as they are the intended recipients of the new system. Top management has given the initial go-ahead to acquire and install the system. Likewise, the accountant provides the control and support for the implementation effort, ensuring that budgets are maintained and the cost is monitored on real time basis. Finally, assuming an implementation team is working together to implement the information system, this team itself has a stakeholder interest in the implementation, particularly if they are receiving some type of evaluation for their efforts. To demonstrate the nature of conflict among stakeholder groups, we will focus on three criteria under which the implementation project effort will be evaluated: schedule, budget, and performance

Page 156 specifications. Schedule refers to the projected time frame to complete the installation and get the system online. Budget refers to the implementation team’s adherence to initial budget figures for the information system implementation. Finally, performance specifications involves the assessment that the project is up and running, while performing the range of tasks for which it was acquired. Certainly, additional evaluative criteria can and should be employed, for example, whether the system will be used by the client group. However, for simplicity’s sake, these three success measures serve to illustrate the nature of the underlying conflict in any project implementation. Figure 7.4 shows the four identified stakeholders and the three success criteria that have been selected. The arrows are used to illustrate Figure 7.4 Stakeholder’s Conflicting Demands

Page 157 the emphasis placed on each of these criteria by the stakeholders. For example, consider the case of stakeholder preferences in terms of the differences between clients and the implementation team. It is obvious that in terms of evaluation criteria such as schedule and budget, there are significant differences in attitude. The clients want the system delivered as soon as possible for as cheap a final price as possible. On the other hand, the implementation team would like large budgets and longer installation schedules because that reduces the pressure of the team in terms of bringing the system online. Further, the criterion of performance specifications varies with stakeholder group. Clients want the opportunity to alter the system, customize it, or add as many technical capabilities as is possible. The implementation team is much more comfortable with a simple system that has few technical surprises (and therefore, less likelihood of long debugging procedures) and is not changed or modified once it has been acquired. Figure 7.4 presents a compelling case for the underlying conflict of most project implementation efforts. It also serves to illustrate one inescapable conclusion: To rationalize and resolve the diverse goals and priorities of the various stakeholders, a considerable amount of bargaining and negotiation is called for. Bargaining and negotiation are two of the primary defining elements of organizational politics. Clearly, political behavior is required in successful implementation efforts. If we take as our starting point the conclusion that a successful project manager is not one who will satisfy all stakeholder parties, it becomes clear that implementation success is instead predicated on that project manager’s ability to successfully bargain and negotiate with the various stakeholders in order to prioritize and maintain a balance between their needs and the realities of the project implementation process. Project implementation becomes a process that depends on the project manager’s clever and effective exercise of political skills. Indeed, we would argue that the trick is not keeping every stakeholder happy. Such an outcome is not possible. When the client is happy

Page 158 with the number of specification changes the project manager is willing to make, the team is likely to be upset by the manager’s unwillingness to freeze specifications. Likewise, when the team is satisfied with the amount of time that the project manager has scheduled for the development process, the manager is likely to begin to hear complaints from top management about lagging schedules. As a result, rather than seek general happiness from each stakeholder group, we often suggest in training sessions that the true goal of project managers should be to focus on communicating the big picture to the stakeholders in order to keep everyone minimally annoyed! If everyone is minimally upset with the project manager’s compliance with various components of the project (time, budget, and specifications), it is likely that this project manager has found a way to strike an effective balance among the various competing demands.

CONCLUSION The management of project stakeholders represents a challenge that most project managers are only now beginning to acknowledge. Part of the reason for this is that little is known about the nature of the various project stakeholders: Who they are, what their drivers and separate agendas are, and how to understand the nature of project stakeholder trade-offs. In this chapter, we offer a framework for understanding some of the most well-known project stakeholder groups, arguing that the stakeholder management process is cyclical, requiring that project managers continually update and reassess the nature of the stakeholder groups and their potential impact on the project’s likelihood for successful implementation. Finally, we demonstrated a model that illustrates the compelling nature of project stakeholder trade-offs. That is, different stakeholder groups have different priorities that project managers must acknowledge. Behind this acknowledgment is the tacit understanding that it is manifestly impossible to maximize satisfaction levels among all project stakeholders. Rather,

Page 159 insightful project managers must learn to prioritize and find a delicate balance of trade-offs among these various stakeholder groups, seeking to satisfy all groups only to the degree possible. It is our hope that this chapter has triggered a better understanding of the importance of project stakeholder management in corporations. The second step depends on the project manager’s willingness to internalize these concepts and seek to manage not only the project’s development, but stakeholder concerns as well.

NOTES 1. W.R. Dill. (1958). ‘‘Environment as an Influence on Managerial Autonomy,” Administrative Science Quarterly, 3, 409–443. 2. T.L.Wheelen and J.D. Hunger. (1992). Strategic Management and Business Policy, 4th ed. Reading, MA: Addison-Wesley. 3. E. Weiner and A. Brown. (1986). “Stakeholder Analysis for Effective Issues Management,” Planning Review, 14, 27–31. 4. A. Mendelow. (1986). “Stakeholder Analysis for Strategic Planning and Implementation,” in William R. King and David I. Cleland, eds., Strategic Planning and Management Handbook. New York: Van Nostrand Reinhold, pp. 176–191. 5. P.O. Gaddis. (1959). “The Project Manager,” Harvard Business Review, 37, 89–97. 6. D.I. Cleland. (1988). “Project Stakeholder Management,” in David I. Cleland and William R. King, eds., Project Management Handbook, 2nd ed. New York: Van Nostrand Reinhold, pp. 275–301. 7. Ibid.

Page 160


Page 161

CHAPTER EIGHT CREATING CUSTOMER-BASED PROJECT ORGANIZATIONS Making the customer-based philosophy work in a project firm is not a simple matter of marginal realignments of current business operations. It requires a top-to-bottom commitment to a new model of business operations; one in which the contractor and customer work together as partners with an equal, vested interest in successful implementation. The common problem lies in effectively moving from a current business-as-usual attitude toward one that represents a potentially radical shift in thinking. This is nothing new. The business literature is replete with example after example of new business practices, guaranteed to solve our most pressing problems. All that is needed to reap these rewards, we are told, is a willingness to change our operations to take advantage of the new paradigm. While we may intuitively understand and even acknowledge the legitimacy of such a change in mindset, a common complaint we hear from company directors is the lack of clear guidelines for transforming their firms. In other words, many of us recognize the worthiness of goals at the end of the road, but few are able to chart a reasonable path

Page 162 toward achieving those goals. What good does it do us to see something of value that is essentially unattainable? This chapter offers a model for becoming a customer-based project organization; for putting into practice the points we have made throughout the book. We describe some concrete steps for project organizations contemplating a shift to take advantage of the strategic opportunities presented them by refocusing their goals in an external, customer-based direction. To use a project management analogy, this chapter is our work breakdown structure; our attempt to redefine the overall project in terms of its various component parts, showing how those parts fit together and how they ultimately lead to the outcome we desire.

THE MODEL: UNDERSTANDING OUR GOAL In making the kind of organizational changes necessary to implement a customer-based approach, we follow the underlying framework established in Chapter One (see Figure 8.1). As we noted previously, it is useful to think of the change process as representing a house, starting with the foundation and moving upward toward the roof. Customer-based project management is founded on a renewed commitment to quality procedures and techniques for developing projects (our foundation). Our goal, prior to attempting the sort of organizational change we are contemplating, is to ensure that all the necessary elements are in place. Without these components, it would be pointless and expensive to initiate a program of change. We argue for the need to combine quality processes (internal efficiencies of operations) with a systematic supply change development (ensuring that our external channels are in place). Project management, as we conceive it, can only be performed to its maximum potential once both internal processes and external channels are refined. The earlier chapters in this book have pointed

Page 163 Figure 8.1 What Are the Basic Elements of Customer-Based Project Success?

to some of the necessary steps in quality and value chain management. Once this groundwork has been laid, we are able to begin developing a heavyweight project organization capable of exploiting this competitive advantage. Project management improvement is not, however, the end of this process. Rather, project management practices, coupled with value and supply chain creation, gives us the ability to put the roof on the house in this model. Customer relationship management can best be done when customers comprehend the commitment our organization has made to process improvement. In essence, the first and hardest challenge is often convincing our own firms to join us on the change to customer-based project management. Once we have done so and have demonstrated our commitment to these changes and attitudes, customer relationship management is not nearly as onerous a process. Initiating the type of systematic changes we are talking about is bound to have a meritorious effect on customer relationships.

Page 164

IMPLEMENTING THE NEW APPROACH: MAKE IT A PROJECT Perhaps the best way to visualize the steps needed to implement a move to customer-based project management would be to view it as a project. As with any good project, a key first step in getting out of the starting gate lies in identifying the necessary steps in implementing the new system. Next, we need to consider how we establish a schedule for the change, include significant milestones, key personnel to be involved, and so forth. When the change is envisioned as a project, it gives us a working model for moving from the current system to the target model.1 Figure 8.2 shows a simplified work breakdown structure (WBS) as a tool to illustrate some of the important aspects of such a system introduction in your organization. We have grouped the key steps in the process along the lines of internal and external analysis, protocol development, testing and refinement, and implementation. Like any effective project, the work breakdown structure for creating a customer-based project success program involves several Figure 8.2 Customer-Based Implementation—Steps

Page 165 steps. Figure 8.3 shows a sample time line schedule with the key milestones included for implementing the customer-based project approach. In pursuing an agenda based on such an operating shift, it is important to consider the following steps as vital milestones in making the change a reality: 1. Conducting an honest internal analysis. An internal analysis forces us to ask the most basic questions: What are we doing right? What do we do better than the majority of our competitors? What do our owners expect from us? In some cases, the list may be quite long. For example, our firm may clearly be the market leader in terms of quality, price, customer satisfaction, and so forth. In other circumstances, however, the list may be depressingly short. Nevertheless, internal analysis is the key to beginning such a measured corporate change program. Until we know where we are, we cannot chart a route to an alternate state. Figure 8.3 Customer-Based Implementations—Schedule

Page 166 As part of this process, it is useful to develop an internal project team to manage the organizational changes, either as part of an ongoing quality assurance (QA) initiative, or separately, as a stand-alone committee. We have found that appointing a project team to oversee the move to a customer-based approach is far more effective than simply layering this philosophy over ongoing operations. An independent team has a more detailed mission and direct commitment to making such a change happen; on the other hand, without direct responsibility being given, it is too easy for initiatives such as this to fall through the cracks. In our experience, when everyone is responsible for making a significant change occur, no one really is. 2. Devoting the time necessary to perform an external analysis of our business focus in relation to customers. Who are our customers? Where can we best add value to our customer base? What key operational features should be our competitive focus? Chapter Four was devoted to the creation of the value chain for customers. The value chain allows us to objectively analyze the activities of our potential customers, matching their needs with our specific strengths. The more our firm is able to refine its message in how we specifically propose to provide value, the greater our ability to identify potential customers and create a compelling case for ourselves. 3. Making contact with our customer base. Who are the key informants we must draw information from among our major customers? The list of key informants consists of those individuals knowledgeable enough and qualified to comment on the various activities of our organization and give their opinions as to the effectiveness of these activities. Some of these individuals may be high-ranking members of the customer organizations and others are key project management personnel. The key is to establish a reasonable list of stakeholder members of customer firms and attempt to develop a dialogue with as many different members as

Page 167 possible. Likewise, it may be appropriate to talk with several members within each stakeholder group. People often hold varying opinions and the more data points we collect, the greater our confidence that we are collecting accurate information. 4. Asking key informants about their decision process and criteria. One common method for gaining information from project customers is to hold a series of lessons-learned meetings at the completion of a project. While useful, lessons-learned meetings should never be confused with timely, usable information. Feedback mechanisms, such as lessons-learned meetings, can tell us where we erred with a fair degree of accuracy. The obvious problem is that such information may not be very helpful for ongoing projects. Learning how we messed up is never an adequate substitute for learning how to avoid such mistakes. Successful customer-based project organizations eschew simply holding post-project lessons-learned feedback sessions in favor of a series of regular meetings with customers. It is much better to adopt a preference for concurrent project control, which allows the project firm to get answers to some fundamental questions, including: What are my customers’ key values and success criteria? What are their key concerns? How can my organization continue to satisfy their needs? What are we doing today that could be done better tomorrow? How do we operate to put ourselves at a strategic advantage with other competitors? These questions and their answers are key to understanding what specific decision criteria our customers employ. Note that the intent of the questions asked at these meetings is not to simply adjudicate disagreements and fire fight current problems. Problem solving is important, but successful organizations also feel that the best method for fixing problems is addressing and clearly understanding customer goals before misinterpretation leads to downstream problems.

Page 168 5. Developing and refining the list of critical issues. These issues are the key to our organization’s continuing strategic advantage. They identify the areas that are important to customers, and ones they feel we perform either well or poorly relative to our competition. This list becomes the key starting point to developing an in-house quality assessment device that allows us to continually track future projects to ensure that they are being developed in accordance with customer needs and expectations. One of our key findings in implementing this program is the importance of recognizing that different stakeholders will have a dramatically different set of critical issues that, for them, define successful partnering. For example, in one case a project organization headquartered in Europe regularly brought a site team from the customer over for an extended period of time while the project was being developed. One important factor for the site team members and their families in evaluating the quality of the relationship with the contractor firm was the attention they had paid to assimilation details. These included identifying appropriate schools and housing options for site team families, conducting local tours, explaining customs, currency exchange and cost of living tips, and so forth. In this case, being customer-focused meant, to a great extent, the company’s willingness to attend to the variety of professional and personal needs that were likely to arise as a result of their employees’ expatriate status. Contrast this example with the wide range of expectations other stakeholders within the customer organization are likely to have. Top management looks for rapid response and cost containment. Engineering wants strong technical solutions and a sense of perceived competence in the contractor firm. All these views, while diverse, are understandable and have to be anticipated. In developing the appropriate customer focus, one key is to recognize that stakeholders is not a monolithic term, but usually a loose collection of individuals and

Page 169 groups with separate decision criteria and expectations. Our ability to tap into those needs and address them as effectively as possible is a necessary step in the process of becoming customer-based. 6. Deciding on measurement parameters. Once the list of key issues (critical success factors) has been developed, the next step is to determine the various parameters of actual data measurement. The key parameters revolve around the effective administration of the customer satisfaction measurement instrument. There are essentially three issues that required immediate attention: l

l

Method. How should the data be measured? Should our company employ a qualitative device based simply on interviews with customers? Should they use some gap measurement device to judge the difference between expected and actual results? Should we rely on a combination of quantitative instruments and qualitative interviews? Clearly, the method used for measuring satisfaction with our critical issues is key to obtaining useful and actionable information. If a survey is employed, how will we know that the right people have filled it out? How can we be sure they have understood and responded appropriately to the questions? There is no question that great care has to be taken with how we propose to access the relevant information from these key informants in such a way that our organization can feel confident in the data we uncover. Timing. When should this information be collected? Clearly, it is necessary to do it at different points during the development process. There is little immediate benefit from getting the information about a finished project if it allows no opportunity for correction. On the other hand, it is also important to reflect on the appropriate points in the current project when this information is most useful. Your organization’s quality assurance department can be most effective with

Page 170

l

this data if it is timely and actionable—meaning that the findings can lead to immediate corrective action. Part of the answer to the timing question lies in the length of the project undertaken. If, for example, a project takes over a year to complete, your firm should work with customers initially to address their chief concerns. Then, at various stages of project completion (e.g., engineering and design, procurement, fabrication), the organization develops regular toll gates to assess their own performance to date based on the identified key success factors. Likewise, these event points also allow the company to update customer expectations, answer questions, and strengthen communication links. Feedback to the contact personnel (both internal and external). Who are the key individuals who should be kept in the reporting loop? Once customer satisfaction data is generated, who are the personnel within our organization who should immediately be informed of any status changes and recommendations for corrective action? One of the problems that often emerges, even when we are able to collect useful data, is knowing who should be informed in a timely way. If a specific quality assurance representative or project team core member is charged with maintaining all customer-related information, they must then serve as the conduit for further dissemination, particularly to the customer. It is common in many companies to make positive information widely available and suppress or severely limit the flow of negative or troubling news. This tendency, though understandable, should be resolutely avoided in this new model for several reasons. First, it assumes that customers do not know the state of their own dissatisfaction, as if they may be unhappy but somehow do not know it! Obviously, this belief is a canard. When we pick up evidence of dissatisfaction with customers, the first people who should be informed are the

Page 171 customers. In doing so, we demonstrate that we know your concerns, and we want to work with you to allay them. Assuming that somehow suppressing bad news will make it go away faster is patently false. All we do is set the stage for a much larger confrontation downstream, usually right around a point in the project when we can least afford it. A second reason for avoiding the mistaken idea of limiting information, both positive and negative, to clients relates to the underlying philosophy that we are seeking to adopt. If our goal is customer satisfaction as the final driver of project quality and implementation success, it is necessary that communication be our chief tool for realizing this mission. Communication necessitates a complete picture of the project’s status. If technical problems are cropping up, if schedules are slipping, if costs are mounting, these are messages the client needs to hear. Partnership means a collaborative relationship through both the good times and bad. Besides, once clients realize that we are not shielding them from problems, they are more inclined to work with us to resolve them mutually, rather than sitting back and assuming that our problems are no concern of theirs. 7. Developing change strategy. Once the information has been collected, analyzed, and fed back to the clients, the work does not stop; instead, in a larger sense, the real work is just now beginning. Information is only a metric to allow our organization an insight into our performance against some level of expectations developed by the customer. Even feeding back to them the results of the surveys should only elicit a ‘‘So what are you going to do about it?” response. The next steps we choose to take are key because they signal our willingness to show our commitment to total customer satisfaction. When, for example, we discover that some subset of our customer (key informants) base is not satisfied with project performance, we have the option of covering up these concerns,

Page 172 glossing over them, or solving them. Successful customer-based project firms have a capacity to continually surprise their partners by their willingness to go the extra mile to satisfy problems to the degree they are capable. The customer satisfaction data we receive should point to some obvious gaps in our performance or miscues that we have to work to correct. We suggest that as part of the commitment to customer satisfaction, the project firm work in partnership with its clients at this stage of the process to show them the results of the surveys, and what the project firm is prepared to do to resolve the problems. This step gives the client the opportunity to offer their own input, suggest alternative solutions to the perceived problems, and work in partnership to develop a strategy for moving through the rough spots. We have been constantly gratified in our own work experiences by the amazement that is usually shown by client firms at this stage when we make our findings of their dissatisfaction available to them and show a willingness to work in collaboration with the customers to solve the problems. Our experiences suggest that for the vast majority of project client firms, this approach is by far the exception, not the rule. As the reader might imagine, it leaves a lasting impression and establishes a level of trust in the business relationship that usually leads to long-term relationships. 8. Implementing and monitoring the changes. The final step in the process for creating customerbased project organizations is to use the project team created in the beginning as the spearhead for implementing this program throughout the organization. One of the points of resistance we sometimes hear within a firm is the argument from some departments that they are shielded from the customers. Customer satisfaction is the responsibility of marketing, field engineering, top management, anyone but themselves. The reality is that there are few groups within project-based firms that have no contact with customers. Further, when we start making artificial distinctions between those departments that interact with

Page 173 clients and those who do not, we send the implicit message that customer satisfaction is not everyone’s concern. Either way, this attitude is dangerous and antithetical to establishing a corporatewide philosophy of customer-based project success.

CONCLUSION In the final analysis, for a customer-based project management philosophy to work to its maximum potential, it requires several things: (1) a clear commitment from the top management of the firm, demonstrating that all operating decisions regarding project development will respond to the concerns of the customer base, (2) a contact point (such as the quality assurance department) within the organization that serves as the focus for the change effort, (3) a detailed plan for moving the organization from its current state to one that embraces the new attitude, (4) a monitoring mechanism to measure and control the change process, and (5) an understanding throughout the firm that customer satisfaction is everyone’s concern. Each step in developing this approach is critical and each builds on the previous actions and activities. We routinely approach project development as a sophisticated process. We should accord this change process the same degree of serious planning and careful implementation.

NOTE 1.J.K. Pinto, P. Rouhiainen, and J.W. Trailer. (1998). “Customer-Based Project Success: Exploring a Key to Gaining Competitive Advantage in Project Organizations,” Project Management, 4(1), 6–12.

Page 174


Page 175

CHAPTER NINE PUTTING THE MODEL TO WORK The ARO Story Since the beginning of the 1970s, a Finnish corporation, Rauma, had been involved in the offshore industry, working mainly through its Mantyluoto fabrication facility in Pori on the West Coast of Finland. In the early days, the company’s key product was a semisubmersible drilling rig for drilling contractor customers both in Europe and in the United States. Due to the various gas shocks through the 1970s, the market remained strong for offshore drilling. As they approached the decade of the 1980s, Rauma had established a strong track record and was generally known in the marketplace for its high-quality work. By the beginning of the 1980s, their product range consisted of semi-submersible and jack-up type drilling rigs and drill ships. Their business model had evolved from the original structural steel fabrication to multidiscipline turn-key deliveries of complete rigs, including significant amounts of systems integration and outfitting. At their height, in the early 1980s, there were 3,000 people working at the yard, including their own and subcontracted workforces. Unfortunately, while volume was high, profitability was not at the same level.

Page 176 As a result, the combined effect of increased capacity among competitors in the Far East coupled with the recession that hit the offshore drilling industry in 1983 put Rauma’s offshore unit into a very precarious situation. For Rauma, these environmental effects led to serious erosion of profitability for their offshore division. Rauma still saw intrinsic value in the offshore business, and using the support from its other units in the forest-based and heavy metal industry, was trying to find new directions for its problem child throughout the 1980s. These steps included placing a strong emphasis on new business development, mainly targeted to the lucrative North Sea offshore construction market that was controlled by Norwegian and U.K.-based contractors and fabricators. Another avenue for considerable marketing effort was with their traditional business partner, the Soviet Union. Rauma was heavily involved in the plans for exploiting and utilizing the oil and gas reserves of the Soviet Arctic areas. The company also made a significant investment in product development, through focusing on deepwater technology. At the time, this area appeared to offer great potential in the nodule-mining sector. Again, however, external events were to prove a significant threat to the survival of Rauma’s offshore division. In the beginning of the 1990s, the Soviet Union had collapsed, freezing contract performance, and causing whole market opportunities for Arctic and Caspian oil exploration to dry up. At the same time, new product development efforts in area of deep-sea technology had brought some publicity and great technological achievements, but very little profit. Likewise, in the North Sea market, the company had achieved a minor business position but was struggling in a highly competitive subcontracting segment that traditionally carried relatively low profit margins. All in all, the situation was bleak; the effect of negative business cycles combined with hostile competitive

Page 177 forces was leading to a huge shrinkage in potential business volume and operational downsizing.

RESTRUCTURING By 1992, there was tremendous pressure within Rauma’s corporate management to divest themselves of their offshore business unit. These pressures led to several events: A decision was made to restructure the offshore division. The traditional fabrication yard organization was split into three different companies. First, by joining with a large Finnish consulting company, a new engineering firm was established on a 50/50 ownership basis. This new organization, named PI-Rauma was viewed as a marriage based on the strengths of both parties. The consulting company needed shipbuilding and offshore experience to establish itself in that industry. On the other hand, Rauma recognized that through the marketing channels the established consulting company offered, there would be a chance to gain additional onshore work in other industry segments. Second, the workforce at the fabrication yard was trimmed to the absolute minimum and the facility was reorganized to operate as a general subcontractor, both in offshore and other industries. This new fabricating firm was named Mantyluoto Works. The third company, Rauma Offshore Contracting, was formed from the personnel comprising the business development, project management, and administration subunits of the old fabrication yard organization. The mission of this group was to establish an offshore contracting business that was supposed to act independently from the other two companies, though using their services whenever possible. As a result, Rauma, the parent corporation, ended up creating three independent companies from their former offshore unit. Both the fabrication and engineering companies experienced some teething

Page 178 problems during their start ups; however, they were operating in their traditional businesses and were also believed to be lean enough to keep costs under control and to be competitive. Most observers, consequently, expected that they would prosper with their current configurations. Unfortunately, in the case of the new contracting business, Rauma Offshore Contracting, the situation was quite different. Because they were set to operate in a highly competitive, high-risk business, outside the small company itself, there were not many who believed in their chances of survival, let alone the possibility that they might be successful.

A NEW START Pekka Laxell, the vice president responsible for the offshore business at Rauma not only believed in the business itself, but also in the idea of the new independent contracting company. He realized that while the team had some handicaps, they still represented a unique concentration of expertise and experience that was rapidly disappearing from the market mired in a 10-year long recession. Another factor in the contracting firm’s favor was their control over a promising new product concept. This product was part of a new product development portfolio put together in the end of 1980s, and since given to Rauma Offshore Contracting to exploit. Furthermore, Pekka Laxell felt that the company’s new, project management business model was agile enough to generate sales rapidly, particularly when they could combine their designs with a series of flexible fabrication options, intended to present customers with the maximum set of alternatives. As a pilot test case for this project execution concept, the company inherited one ongoing, turn-key construction project situated in the Middle East. In spite of a number of daunting competitive hurdles, Rauma Offshore Contracting was being positioned by its parent company to attempt to compete in a difficult industry and sales

Page 179 climate. One final question, however, remained: Who would be the right person to lead the new company? In 1987, as part of Rauma’s worldwide business development efforts, a young engineer named Risto Neuvo was appointed to manage the company’s Singapore office. Neuvo’s background and education were in engineering, but he brought a wide-ranging set of skills to his new job, including time spent working in a design office as a technical designer and project manager for a range of smaller productbased delivery projects. During these years, he also developed strong people skills through working directly with customers in his project management capacity. For two years prior to his appointment to the Singapore office, he had managed a large machining shop. In that time, he oversaw a significant restructuring and downsizing process at the shop, giving him a sense of the cost-cutting reality. His last job before the Rauma Offshore assignment was a project manager involved in bidding large onshore high technology-based construction projects. By 1992, Neuvo had managed the Singapore office for five years. For almost that entire period Rauma’s shipbuilding and offshore industry had been sailing on the increasingly stormy financial waters. However, during this time, Neuvo had worked to build contacts and achieved some success in a very difficult marketplace. Still less than 40 years old, his youth may have caused some concern but his successes in the Far East had been beyond question. Neuvo was offered the leadership of Rauma Offshore Contracting, a start-up company of 50 people—almost all older than himself—with hardly any money, and a vague business idea. Furthermore, the company was located in a small, rather remote Finnish town that was not exactly the kind of place where he had planned to spend the best years of his career. On the other hand, he felt that the offshore business was presented a fascinating challenge and, should he be successful, the opportunity to be part of something big. As an additional sweetener, the position was

Page 180 very independent from corporate oversight and carried significant responsibilities—features he found very appealing. After considering the offer, Neuvo decided to take the job of managing director for Rauma Offshore Contracting. His honeymoon period was brief. Soon after taking over the contracting company, the realities of the serious challenges he faced began to pile up. Neuvo had envisioned a fully independent operating organization, free from Rauma corporate control concerning day-to-day operations. He perceived that the key to creating a motivated, committed organization was to minimize the involvement of the parent organization, an idea that increasingly came to be resented by the corporation’s functional managers. He found himself locked into repeated arguments with the corporate management, as they continued to attempt to exert influence on his unit’s operations. Although he eventually gained some control over a series of issues, most related to a guaranteed level of independent action, Neuvo was becoming increasingly worried about the fact that his initial small capitalization was rapidly running out. The Middle Eastern project they had inherited was generating some revenues but the project also created a series of operational problems that required continuous attention. At the same time, the marketing effort built around introducing their new product to U.S. oil companies, although relatively moderate in scale, was consuming money faster than expected. At this point, Neuvo and his new company were at a crossroads, personally and professionally. He recognized the risks in the job he had taken but was becoming increasingly suspicious that to Rauma, the parent company, he was already being written off. Was the corporate management using him to captain a ship they were convinced was sinking? Had Rauma Offshore Contracting simply been established as one step in the process of closing the business? What sustained Neuvo and his team through this time was the classic lifeboat mentality; recognizing that they were all at sea together and responsible for their own survival ultimately made it

Page 181 much easier to bring everyone on board and start turning things around in their favor.

Success Framework Although splitting up Rauma’s old offshore fabrication yard organization had created the basis for a new start for all three new companies, that move did not offer much benefit to the new contracting organization: Rauma Offshore Contracting. True, the personnel in the new organization were experienced, but the uncertain future continued to be worrisome. Further, there was still some general confusion about the new versus old corporate structures. Everyone knew their old positions no longer existed, but with the new company still shaking out, a number of questions surfaced. How should the three new companies interact with each other? How do we reconfigure ourselves as an entrepreneurial start-up, instead of being part of the larger organization? Can this new firm, populated with oldtimers, really show the flexibility to compete and succeed in an increasingly complex and competitive new marketplace? In recognizing that his team supported him perhaps more than he had first thought, Neuvo started to put his new operating philosophy in place. First, he reconfigured Rauma Offshore Contracting as an extremely flat and lean organization with the focus on minimizing the overhead cost and making sure everyone was participating in the actual project work. A company this size could not afford excessive bureaucracy or staff positions that performed with poor productivity. The decisions over these first moves were quite easy to make. Principally they were driven by the fact that the company had to create income fast and did not have many assets other than its people. Implementing these decisions was more difficult. Although experienced, most of the people had been in leadership positions in the old organization and were confused in transitioning to a business

Page 182 model that made them all first-line employees. For example, many of the personnel were almost completely lacking in rudimentary computer skills. In spite of the financial drain on the firm, Neuvo pushed through an extensive investment in computer systems and training. The message was clear: All people in the new organization have to develop new skills, new outlooks, and a hands-on approach to working with customers’ projects. There were to be no pockets within the organization isolated from client service functions. At the same time as the companywide program for learning computer skills, Rauma Offshore Contracting initiated steps to acquire ISO 9001 certification for the company. This internationally recognized symbol of quality standards was seen as an important step in bringing a much-needed competitive edge to the firm. As a first step toward certification, a great deal of energy was spent in thinking about the basic operating philosophy and business processes of the new company. It was also important that the whole organization be involved in this process. After developing some level of consensus regarding the basic business model, extensive efforts started to produce the necessary procedures and routines needed for running the business. All parts of the organization were responsible for figuring out their own key business processes and documenting them into procedures. For a workforce with an average of 15 to 20 years experience in the business, this was an unique opportunity to stop and think, ‘‘How would I do it right this time?” While the new documentation was not perfect, in general, it gave a much-needed framework for the operations of the company and to a certain extent, launched a new way of thinking. Furthermore, along with crash courses in improving employee skills in using modern technology and documenting past experiences into procedures, the reevaluation process created a new sense of team spirit that was to be the driving success force for the whole organization when business started to increase. Rauma Offshore Contracting, as a new project management contracting company, was separated from both the engineering and

Page 183 fabrication components of the old organization. In focusing on the new business mode, it was difficult to accept the fact that the business of the firm involved neither engineering nor fabrication, but centered instead on contracting and project management. This new business model posed some obvious questions, principally, “How can we do this in practice?” One way would be through selling project management services on an hourly basis in a consulting arrangement. This approach, by itself, however, was not going to meet the criteria for the return on investment that was set by the corporate management. Furthermore, it was felt that this model did not offer the kind of business volume that would have been enough for survival in the long run. Simply put, working exclusively as a contracting firm using project management as its core expertise meant that it was necessary to base the business on delivery contracts in which the whole scope of work had to be out-sourced, thus putting the new firm at the mercy of the supply chain. This, then, led to a reconsideration of the very basic questions regarding any business: What is the value we add to the customer? What are our risks and how can we cover ourselves? Even if we manage to sell something, how can we make enough money to survive in the long run? The game rules concerning the contracting businesses’ relationship to other business groups within the Rauma Corporation were clear. Rauma Offshore Contracting did not have any obligation to use its sister companies as suppliers if that did not improve its competitive position in any particular contract. However, rather soon after the restructuring the three companies, Rauma Offshore Contracting, Mantyluoto Works, and PI-Rauma, found the basis for forming a well-functioning supply chain network. Employees of the three new companies knew each other extremely well and were able to establish the trust level necessary to make the supplier-distributor relationship run smoothly. Each of the three companies focused on their own business opportunities. Just knowing that corporate management was not going to step in to adjudicate disputes about money

Page 184 or other operating decisions created a totally new level of appreciation among the firms. It also encouraged rapid feedback mechanisms between the parties concerning the effect of costs on any planned changes in the scope of work, schedule or specifications during the project. Altogether, the need to negotiate formal contracts between the sister companies, one acting as a supplier to the other, resulted in a new kind of emphasis on project planning and risk identification that eventually enhanced the quality of the whole operation. The close contractor-supplier relationship that worked well with the sister companies encouraged Rauma Offshore Contracting to apply the same model to their other key suppliers. The most outstanding example of this effort was shown in the relationship that the company developed with its major steel supplier. The continuous improvements that the steel supplier introduced in their delivery process in the form of faster and more flexible delivery, were immediately utilized in the delivery process of Rauma Offshore Contracting. Today, their major contract may involve 25,000 tons of steel plates ordered in 40 separate orders, each with specific plate sizes and qualities, the delivery time being three weeks from the order to the delivery at the yard. Compared to the traditional offshore projects, this has improved the delivery time of the product and created an additional competitive advantage by offering new kind of flexibility to the customers through concurrent engineering and fabrication, at the same time maintaining a reasonable level of risk. Concerning their project management processes, the old fabrication yard organization implemented a traditional model where project managers were the main interface with customers but were mostly dealing with the technical issues; that is, focusing on getting the job done. Functional managers were responsible for providing the resources. Toward the end of the old organization the role of project management and project managers started to change, driven by low profit levels and losses during several years.

Page 185 The focus was switching from technical matters to budget keeping. This development was supported by investments into project management tools, including the development of new project control software. When Rauma Offshore Contracting started, it adapted a model where the project manager had a very independent position, being solely responsible for the project, including maintaining the customer interface, performance of the product, schedule, and ensuring the profit. Neuvo’s basic philosophy was that if project managers were expected to assume a larger responsibility, they also had to have the freedom and power to make the necessary decisions. Following the same principle, the project responsibility was further subdivided underneath the project manager among a small team of project discipline engineers. On one hand, this was a natural and easy decision. The company had limited resources but was aiming for large contracts where practically the whole scope of work was outsourced through the supply chain. In a small project team, every individual was responsible for relatively large piece of work and budget, while still working mostly on their own. On the other hand, creating a new business model employing strong, independent project managers was also a difficult decision. The old company culture did not fully support this approach, and some people were also lacking the skills necessary to run this kind of operation. Finally, implementing the model was also at the time difficult because the increased power of the project managers occasionally ran into conflict with the opinions and views of the managing director. Mr. Neuvo, however, so well understood how dependent the success of his business was on high-profile project managers that he accepted the risk of wrong decisions rather than overruling the project manager in matters that were clearly their responsibility. The ISO 9001 quality standard was a good framework for developing Rauma Offshore Contracting’s project management systems and procedures. Because the resources of the new company

Page 186 were very limited, the decision was made to take advantage of most of the systems that existed and had been used in the old organization and just modify those to fit the new business model. The project control system was built on the same software that the sister company Mantyluoto Works was already using. Most of the people were familiar with this system and it helped to build an efficient interface with the sister companies that formed the core of the supply chain. The old system was considered sufficient for the schedule and progress planning and control. However, because of its size and the nature of its business, Rauma Offshore Contracting faced a need for very high quality cash flow management. To facilitate this requirement, the project management system had to produce accurate and timely cost data. Toward that end, great efforts were exerted to expand the project control system to include a detailed cost analysis function. In the 1970s and 1980s, during the period of intensive drilling rig construction, the old fabrication yard organization had learned to deal with large customer site teams at the yard. Although the subcontracting work for the North Sea main contractors in the later half of the 1980s for building offshore production facilities was smaller in scale and did not involve large customer site teams, the same basic work model was followed. Typically, both the main contractor and the end user oil company had their representatives at the yard. Working with the customer site teams was a daily routine and involved large parts of the organization. The upper management team was routinely interfacing with the higher levels of the customer organizations during business development, contract negotiations and project implementation. However, for most of the contractor personnel the customer site team was the customer that they were used to seeing daily. Hospitality toward foreign guests is generally strongly ingrained in the nature of the Finnish people. Partly because of this, but also because of the remote location of Finland in respect to the worldwide

Page 187 offshore marketplace, Rauma management was always very much in favor of encouraging the development of good customer relations at all levels of the organization. This had resulted in a number of close, friendly relationships with many of the customer representatives who worked at the yard. During the 25 years of the yard’s operation, these relationships ultimately led to quite an extensive network inside the oil industry. However, even more importantly, it had created a positive attitude toward any customer representative throughout the whole organization. This history of active concern for the customer was a good basis for the new contracting company to start developing their customer relationship management program. Rauma Offshore Contracting focused its business on the large offshore projects of oil company customers. This strategy was based on the background and experience that the company had in the Caspian Sea area and on the opportunities that their new deep water product seemed to offer in the Gulf of Mexico market. Another factor in their favor was the fact that the three new companies together had a relatively large pool of personnel with extensive drilling rig design and construction backgrounds. This base of expertise offered some competitive advantage in a market where such knowledge was rapidly disappearing. Unfortunately, the traditional customers were the drilling contractors and a few North Sea contractors. The company had done very little work directly for the oil companies in the past and was known by them simply as a drilling rig builder. In 1987, Rauma had established a one-man sales office in Houston. The systematic work done there to approach the oil companies coupled with a new partnership with an old drilling contractor customer led finally to a break-through in 1994. Rauma Offshore Contracting won a project management services contract with a major oil company for a Far East offshore project. This contract led to the creation of a relatively large joint team of engineers from both Rauma Offshore Contracting and PI-Rauma, the engineering

Page 188 company, in Houston during the design and construction phases of the project. Because this was the first contract of its kind in the history of Rauma, the feedback from the lessons learned was collected and utilized to further develop the company’s procedures and business model. The experience and confidence gained in working with a major customer on this project was without doubt one of the keys to entering into the first contract for the new deep water product that finally opened the doors for Rauma Offshore Contracting to the larger scale contracting business in 1995.

ENTERING THE BIG LEAGUES The first contract with the new breakthrough deep water floating production concept was with a relatively small independent U.S.-based oil company. In its attempt to search of new products for its fabrication yard, Rauma had since 1987 worked closely with a small California-based entrepreneurial technology company that had developed the product concept. During the years of marketing effort it, however, became obvious that Rauma and the small technology company did not possess sufficient credibility in the industry to launch this kind of new product on their own. After screening the possible partners, this obstacle was overcome by teaming up with a major U.S. offshore contractor that had both the recognized capability and the manufacturing capacity to provide the missing pieces to the competitive puzzle. The first contract for the new product was signed in February 1995. This turned out to be a breakthrough project in more respects than one. The customer took a considerable risk by employing new technology that had been used never before. At the same time they operated with very lean project management resources. However, the skillful project management on the customer side together with the good match of personalities on both the customer and contractor sides created an extraordinary atmosphere of trust in the project that was a key factor in making it a success. This started

Page 189 during the initial contract development at the time when the project mission and goals were first agreed. Later, the initially made clear definition of roles and responsibilities of each party supported innovative utilization of project management and information technology in solving the day-to-day project issues. For example, with the new product both conceptual and detailed designs had to be done in parallel with fabrication. The ability to make technical decisions fast was vital for the continuation of the process and success of the project. Communication using e-mail made it possible to take the full advantage of the eight-hour time difference between U.S. and Finland. When there was a detailed design or fabrication question that needed the approval from the customer to keep the fabrication going, the drawings were transferred electronically to the U.S. at the end of the working day in Finland. During the day, the customer management team reviewed the documents, often using their computer screens, and gave their comments or approval by return e-mail. Next morning when the people came to work at the yard, the answer was usually already waiting for them. This real time decision-making process concerning the technical questions is only one example of the innovative use of project management techniques that was typical in the project. The trust and true understanding of the project goals on both sides made it possible to solve promptly the cost issues that often are difficult in this kind of prototype developments. It is no surprise that the team ended up with a successful project that set a benchmark in the industry and established a firm basis for the future business of both the customer and the contractors involved. The customer relationship management philosophy that was found to be successful in the first major delivery project of Rauma Offshore Contracting has been further developed and refined through a number of larger projects with major oil companies that have followed since 1996. This development has involved systematic attempts to increase trust between the customer and the contractor, efficiently employ integrated customer-contractor project teams, utilize the

Page 190 opportunities from information technology, and minimize the size of both customer and contractor teams by close cooperation in day-to-day project routines. Following the successes of the past years, Aker Rauma Offshore, as it is named since becoming a fully-owned subsidiary of the Norwegian conglomerate Aker Maritime in 1995, has created a reputation for itself in the minds of customers in the offshore marketplace. Aker Rauma Offshore is well aware, however, that the stiff competition it faces guarantees that business success can never be taken for granted. To stay ahead of the curve in its market, the company is continuously seeking new ways to further develop its customer relationship management. As part of this effort, a formal program for assessing customer satisfaction was established two years ago. Their goal, through addressing a number of different, functional parts and levels of their customer organizations, is to collect feedback for both product and delivery process improvements. In the end of the decade of the 1990s, Aker Rauma Offshore’s interface with its customer base, especially since becoming part of Aker Maritime, has expanded enormously. The company’s program for building a customer-based project organization has involved a number of integrated steps to tap into the various stakeholder components of their customers. For example, the customer that is closest to most of the members of the project organization is the customer site team. That is why the customer satisfaction measurement program started from creating a procedure for measuring and improving site team satisfaction. After that they, together with one particular customer, have created a pilot case focusing on both the customer business unit responsible for operating the product and the operator team itself. To date, the customer satisfaction measurement program is an integrated part of Aker Rauma Offshore’s quality assurance system and continuous improvement process providing new data to support decision making of system improvements in each new project.

Page 191

SUCCESS On the basis of its performance figures, Aker Rauma Offshore has been very successful during the last few years. Between 1992 and 1998 the net sales of the company developed from less than 10 million U.S. dollars annually to more than 200 million in 1998, the peak year in the present history of the company. At the same time, the number of personnel went from 48 to 119. In respect to the return on investment, the company has achieved between 80 percent and 130 percent annually, placing them typically among the four top companies in Finland. At the same time, the company has been able to maintain outstanding levels of customer satisfaction and establish itself as a benchmark and a desired supplier in the minds of its key customers.

CONCLUSION Aker Rauma Offshore’s story is one that should cause all project-based organizations to reconsider their underlying philosophies for managing projects. A company, on the brink of failure and locked in a highly competitive industry, has not only survived but thrived through the development of a radically different way of thinking and operating. “Customer-based project management,” as they have termed it, is the key to their ongoing success. It is a story that clearly illustrates both the attitude and practical steps needed to attain the kind of competitive advantage all successful firms seek. In that sense, this chapter offers up more than simply another success story. It also illustrates an example of a company putting into practice the ideas that are being presented in this book: Success through a relentless customer focus.

Page 192


Page 193

CHAPTER TEN BUILDING THE CUSTOMER-BASED PROJECT ORGANIZATION Finding and maintaining competitive advantage is key to the long-term success of any business firm. The larger (and harder) question is how to create this degree of separation from the competition. What are the steps our organization can take to give us the operational ‘‘leg-up” on our competitors. Many companies experiment with various formulas: cost cutting, down-sizing and corporate reorganizations, total quality focus, and so forth. While all of these ideas may be useful and appropriate in their particular circumstance, this book has offered a different premise. For the projectbased organizations that will increasingly dominate the world stage, doing it right is not a sufficient substitute for getting it right; that is, being internally efficient is not the same (or as useful) as offering a product that fits customer needs. We made the argument that it is only in creating and maintaining a customer-based outlook that project organizations are best able to reap the benefits of a new, chaotic, but highly lucrative marketplace. Creating this customer focus is not easy, despite the obvious surface merits of such a philosophy. Indeed, we suspect that every firm we have ever consulted with, studied, or worked for would quickly assert that they have such a customer focus to their

Page 194 operations. The truth, however, is often less optimistic. We see too many examples of project organizations dominated by an internal mentality that ensures contractor-customer relationships quickly turning contentious, reactions to customer needs becoming grudging, and operating decisions dominated by bottom-line thinking. There are some serious problems at work here. First, these organizations automatically assume that decisions involving costs and customer satisfaction are always operating as trade-offs; that is, they represent a zero-sum game. The more we satisfy the customer, the more it will cost our firm. Hence, from the top down, project organization members are socialized to fight with customers from the time the contract is signed. Every product change, every schedule adjustment, and every dollar spent are serious points of contention between the parties and contractor-customer relations, while never effusive, quickly become hostile. Firms seek legal remedies and third-party arbitration for problems that never should have escalated to this point in the first place. A second problem with this bottom-line thinking is that each key stakeholder in the project begins making erroneous assumptions about the motives of the other parties from the beginning. The project organization operates under the belief that customers will try to hold out for expensive changes, routinely violate the terms of the contract, and threaten legal recourse when dissatisfied. Customers are equally convinced that contractors have to be watched like hawks as they will focus in making money through the change orders and in the worst cases are even willingly sacrificing quality for a few extra dollars on the bottom line. And so it goes. Everyone begins the project, not in healthy anticipation of success, but with foreboding of the inevitable problems. We spend our days as firefighters, putting out a continuous series of fires as they blaze into life. It does not have to be this way. Rather than taking council of our worst fears as we progress with new project development, an

Page 195 alternative does exist. We offer another model for running projects; a model that takes as its starting point the belief that the steps we take to develop, manage, and maintain strong customer/contractor relationships will pay huge dividends downstream. Making this approach work is not easy. It requires a recommitment on the part of the project firm to the principles we all intuitively acknowledge; for example, customer satisfaction is the true determinant of project success. It requires us to take these principles and apply them (and sometimes reapply them) to all aspects of our project operations. No one remains immune. The project engineers serve an important ambassadorial role with the customer just as the project manager or the sales department. In other words, the commitment must be total or it will falter. Respectively, the new approach requires the customer to appreciate the effort of the project firm toward their total satisfaction. Together, a completely new level of communication is needed between the parties to create the trust that is an absolutely fundamental driver for the success of this approach.

BUILDING HEAVYWEIGHT PROJECT ORGANIZATIONS The term heavyweight project organizations was coined by Steven Wheelwright and Kim Clarke in the Harvard Business Review.1 Their argument suggested that successful project organizations do not become successful by chance or luck, they take measured steps in their design and operating philosophy to get to the top and remain there. In identifying four basic types of project organizations, they show a natural progression toward the kind of firm that is equipped to successfully compete in the project-rich environment of the coming decades. Figure 10.1 shows a model in which three key elements in creating a successful shift in the right direction are shown. The three elements are the role of the project manager, the nature of

Page 196 Figure 10.1 Basic Types of Project Organizations

organizational resources and power, and the overall company focus. The four basic organization types range from the one most commonly found in business today, the functional project organization, all the way to the autonomous team organization. Let us consider some important aspects of these project organization designs, particularly as they relate to a progression from simplest to most sophisticated.

Functional Project Organization The functional project structure, in which projects are simply overlaid on the standard functional departmental design, is probably the simplest and least effective form of project company. Unfortunately, however, it is one of the most common types of project operating environments. There may be no one person who is given the role of project manager, the work of the project is typically simply divided

Page 197 up across departmental boundaries, and the focus is on optimal use of resources; in a word, efficiency. The problems encountered in running projects within this simple framework are well known. A number of researchers have investigated this design and point to some common pathologies, including poor communication, slow responsiveness to environmental shifts, excessive sacrifice of quality for dollar savings, and so forth.2

Lightweight Project Organization A somewhat better model for project firms is the lightweight structure. In this approach, there is an assigned project manager with responsibilities for the overall project development; however, the project manager usually has very limited power to accomplish the necessary tasks. Likewise, there is a natural conflict embedded in this approach in terms of the relations between the project team and the rest of the functional organization. Department managers retain control of resources, assign their own personnel to the project, and maintain the balance of power. Project managers suffer the classic problem: all the responsibility and none of the authority to accomplish the necessary steps toward project completion. Lightweight structures are only a marginal improvement over the simpler, functional style. The focus is still in the efficient use of resources; that is, making it cheaper and faster. Project managers are doing their best to promote the project goals, but when lacking power over resources, their main function remains often one of minimizing the customer frustrations.

Heavyweight Project Organization The third form of project organization represents a significant improvement over the first two. In the heavyweight project firm, the focus has altered dramatically to reflect the company’s more profound commitment to best project management practices. Project

Page 198 managers occupy a position with both responsibility for project success and the commensurate level of authority to guide the development process. Department heads have limited and well-defined roles in the project, power is split between the two centers of power (functional and project). The focus shift is much more dramatic; for the first time, the recognized emphasis is on the customer, rather than maximizing internal operating efficiencies. Because project managers in effect share power with the functional department heads, they are in a far better position to shift the focus to the customer, where it belongs. The heavyweight project organization represents the best acknowledgment of the resurgent role that projects have assumed in company success at the start of the new century.

Autonomous Team Organization The logical conclusion of a move toward the fully empowered project organization lies with the development of autonomous teams. Sometimes known as “skunkworks,” after the famous Lockheed Corporation programs, autonomous project teams represent the final acknowledgment by the firm of the priority of project-based work in the company. In these organizations, the project manager is given full authority, status, and responsibility to ensure project success. Functional departments are either fully linked to the projects or the project teams are accorded an independent resource base with which to accomplish their tasks. Again, as in the heavyweight project organization, the focus has shifted from the internal operating efficiency perspective to one that is aimed squarely at problem solving and, in this way, maximizing customer satisfaction in challenging projects. The problem with autonomous teams often is, however, that although they are efficient tools in making challenging projects happen, in the long run, they often face difficulties. When the focus is exclusively on problem solving, these teams

Page 199 tend to overlook cost efficiencies and systems development and may become too expensive. As a business model the autonomous team may be the right solution only in a very limited number of cases.

WHAT IS YOUR ORGANIZATION’S PROFILE? Heavyweight project organizations do not happen by accident. Consider their own organizations in comparison to this chart. If, as is likely, the majority find themselves working in functional project companies, there are some important points to remember in attempting to redirect the company’s activities where they properly belong. First, no one goes directly to the autonomous team stage when it comes to running projects. This project organizational form represents the last transitional stage in a systematically planned shift in corporate thinking. We gradually move to this step through making conscious decisions about how we are going to improve the way we run projects. The three metrics that help us in this process are listed in Figure 10.1: role of the project manager, resources and power, and focus. As we have discussed, successful project firms work to expand the authority of the project manager, often in the face of stiff resistance from functional department heads who like the power balance the way it currently exists. Giving project managers high status, authority to conduct performance evaluations of team members, authority over project resources, and direct links to the customers are some necessary elements in redirecting this power balance. Likewise, project managers who are constantly forced to rely on the good graces of functional managers for their team staffing, coordination, and financial and other resources already operate with one hand tied behind their backs. Heavyweight project organizations have realigned their priorities away from functional maintenance to market opportunism. That realignment only occurs when the resources needed to

Page 200 respond rapidly to market opportunities rest with the project team rather than being retained at some highly centralized level. Finally, as we have noted throughout this book, the shift in focus has begun to profoundly affect the manner in which the project organization, manager, and the team operate. The new focus, on the external customer, becomes the driving force for operations, not simply one of several competing demands placed on the project team for them to satisfy as best they can.

MAKING A CUSTOMER-BASED APPROACH WORK FOR YOU If your company’s goal is to successfully compete in the marketplace of the new century, you will in all probability be competing on the basis of projects: yours versus the other guys’. How you compete, how well you perform, and your long-term viability will depend on your project management savvy. We have offered a new way of thinking about projects that has been successful when applied in a systematic manner. It requires a critical examination of how your firm is currently running its projects, what your long-term goals really are (not just what you publicly state them to be), and how committed the company is to improving its processes. In earlier sections of the book, we offered a template for creating the protocol to begin moving in the right directions. In this final chapter, we would like to reemphasize some of the key steps in making customer-based project management work for you: l

Know your goals. The number of organizations that have backed into project management never ceases to amaze us. By this we mean the companies that have no overall understanding of project management, running projects, or using them as vehicles for new product development, system implementation, or corporate renewal. These firms often layer projects over

Page 201

l

their ongoing activities, appoint some internal people to manage the project, provide little training and support, and then profess surprise when the projects routinely fail. These companies do not know their goals for projects. They have not thought through the methodology for making project management work and have only the vaguest notion of what projects can do for corporate success. “Knowing your goals” means to establish a meaningful, companywide project management philosophy, one that is followed by all members of the firm, starting at the very top. Successful organizations often develop an overall operating framework that shows how all the parts fit into the whole. Quality, supporting infrastructure, and integrated project management are all necessary precursors to the ability to successfully adopt the customer-based project philosophy. Such a framework does not emerge by accident or happenstance. Each layer in this model builds on earlier supporting levels. Customer-based project management becomes the final completion of the philosophy. This point is important because many times companies are too quick to adopt the latest new thing as a quick fix to problems they are experiencing. Simply layering a professed interest in customers over a company that offers no supporting infrastructure or quality attitudes is a recipe for failure. Realizing the full benefits of such a philosophy requires a goal, a plan, and the will to make it happen. Remember who you work for. Successful project organizations are relentlessly customer driven. When conflicts arise, satisfying customer needs always serves as the tie-breaker. Knowing who you work for has some important elements that have shaped our thinking throughout this book and in running our own projects. First, it makes a firm goal of the need to establish good communication and nurture a partnering mentality with the customer, rather than one based on competing goals

Page 202 and contention. We have witnessed countless examples of the surprised and gratified reactions of our customers when they discover our willingness to go the extra mile to satisfy their needs. This reaction tells us something; first, it indicates that a customer-driven emphasis is still the exception in the workplace, not the norm; second, it gives companies with a customer focus an enormous advantage in the opportunity for repeat business. Institutional memory is a powerful thing. When a contractor has gone out of their way to satisfy customers, they remember. One objection we sometimes hear to this idea is best voiced by a project manager who stated, “This focus is fine, but if you go too far the customer will just take advantage of you. They will demand changes beyond the point they can be accommodated, push for price breaks and anything else they can get away with.” When we explored this point further with the project manager, it become clear that he or she worked for a firm that expected hostile relations with clients, routinely used contracts filled with restrictive terms, stiff penalty clauses and options for liquidated damages, and usually got the sort of relations they had come to expect. Their abiding assumption was that the customer was the enemy, if not now, they would be sometime soon. The key to avoiding this kind of expected escalation of conflict is to stop viewing customers as eventual foes in the project’s development and recognize them publicly as full partners. Customers seek to take advantage of the contractor when they do not fully understand the nature of the project’s development; that is, when they are left in the dark. One of the keys to solving this problem before it becomes a problem is full communication of the goals of the project and the success drivers of the customer together with active partnering and dual decision making. When customers understand the implications

Page 203

l

on bottom-line costs and development schedules of all the changes they keep asking for, they will recognize their joint role in making the project come in on time and budget. Yes, change orders will continue to occur. But with a mentality based on collaboration rather than the automatic assumption of hostile intent, the unnecessary change orders and long delays will be dramatically reduced. Everyone recognizes his or her responsibility for getting the project completed on time. Do your stakeholder homework. Who are the key stakeholders in your organization? Usually, there are two distinct groups: external stakeholders and internal stakeholders. Externally, there is the client, of course, but there are other key groups as well. Environmental groups, government agencies, competition, future potential customers are all examples of important external stakeholder groups that can positively or negatively affect how we manage our projects. Internal stakeholders are the various departments, key personnel, or power centers that can affect how well your project development proceeds. Once we have made the philosophical commitment to creating a customer-based approach to managing projects the next step in making the process work consists of doing our homework (i.e., learning all we can) about these stakeholder groups. What are their key goals? How can we start to formulate plans for gaining the cooperation? Business? Goodwill? Stakeholder analysis is complex because we have to recognize the various kinds of stakeholders, even within one client organization. As we noted in Chapter Five, a client organization may have multiple stakeholder groups (upper management, technology teams, project teams, operator groups, and site teams) connected with our firm. Stakeholder analysis first consists of recognizing these various impact players and then requires us to formulate strategies to attending to their diverse set of needs. In some cases, we find competing needs at various levels or among

Page 204

l

different stakeholders within the same client. It may be necessary to meet and negotiate with the customer to establish their overall priorities. Once we learn to recognize and communicate with the major stakeholders, we begin to formulate a systematic strategy for stakeholder management. The key lies in active communication—learning what it is they seek rather than simply assuming we know. Recognize where you provide value. Value chain analysis is a method for critically examining the operations of potential customers and learning the precise points at which our organization can contribute to their bottom line. Aker Rauma Offshore uses value chain analysis to compete effectively in a highly competitive business environment. Rather than presenting themselves as all things to all potential customers, they have adopted the customer-based project focus particularly to reduce potential risk for their clients. They understand that the key contracting decisions made by customers usually arise out of two principle questions: What is their price to us and how much do we have to add by way of contingency to cover our risks? In their pursuit of maximum customer satisfaction they have chosen to strongly focus on the ‘‘risk” side of the equation while striving to keep their cost competitive. That is, we will do everything necessary to reduce your perception of risk in using us as a contractor. As a result, they are extremely successful in spite of operating in an environment where the labor cost is higher than with many of their competitors. They have perceived, correctly, that price is only one decision variable used by the potential customers. Project firms that have adopted product thinking as part of their business philosophy are able to cover more uncertainty with less project specific planning and engineering than the ones that rely on working with any product concept and start each time with a clean slate. Here product thinking involves

Page 205 learning from the past experience and continuously developing the business processes, procedures and routines of the firm by taking these lessons learned into consideration. Firms that have adopted the product thinking are able to utilize proven modules from their earlier projects in their current operation. A great deal of the learning from the past is already incorporated into their systems and procedures that form the back bone of their delivery process. Figure 10.2 shows the process by which project firms typically add value and reduce the risks associated with uncertainty. Projects, even under the best of circumstances, come loaded with tremendous uncertainties. At the outset, we may start with only a general goal or model in mind: for example, the statement, “Here is what we are looking for.” During this early period, uncertainty is the rule. As we gradually refine the goals, we begin to formulate a product concept. The product concept is the concrete response to the perceived need for Figure 10.2 How Does Product Thinking Reduce Uncertainty?

Page 206 which we initiated a project. The sooner a firm is able to nail down a firm and mutually agreeable product concept, the sooner they can begin the project specific engineering needed to realize the project’s goals. At this point, uncertainty begins to moderate to the point when planning and engineering has advanced far enough to articulate a firm product offering. Here the amount of project specific planning and engineering is usually proportional to the reduction of the uncertainty involved in the project. Product thinking becomes the project organization’s answer to the uncertainty that is mutually held by contractor and client alike. Note that as more time elapses, the product firms up to the point where specific schedules and costs can be estimated and a clearer understanding of project risks articulated. All these activities are often precursors to an actual development process; that is, while this process seems lengthy, it is a necessary component of understanding the scope of the project and recognizing precisely how to add value to the client organization. The bottom line is to be able to present the potential customer with a detailed plan for project execution, based on cumulative learning and full input from all stakeholders involved in the project. l

Create a systematic plan for implementing the system. One common mistake made by many companies when confronted with an innovative idea is to simply layer it over existing systems, standard operating procedures, and employee attitudes. Almost invariably, these new and potentially useful ideas fail. They fail even when firms have the best of intentions and work hard to make them succeed. Bucking the current system, in the form of offering a new operating procedure, is incredibly difficult. New ideas require new methods for introducing them. Firms that have successfully transitioned to the type of customer-based project management we are advocating all

Page 207 share one feature in common; they did it by scrapping their old management model wholesale. From the ashes of outmoded techniques often come the will and the incentive to make the serious kinds of changes necessary to create a new operating model. A protocol for developing a customer-based approach to project management has been presented in this book. It shows, step-by-step, the process needed to identify the relevant stakeholder groups, work with each to determine their critical success factors, and develop and timing scheme that enables your organization to transition to the new model. This model will require some significant structural alterations, as more personnel are delegated to working in liaison roles with customers. For most project companies, customer contact is initially reserved for the sales staff. Once the contract is signed and initial specifications are agreed to, customers are handed off to engineering or other technical specialists to ensure technical compatibility and adherence to specifications. The actual points of contact with customers tend to be very few. The new system discussed in this book places much higher emphasis on the importance of developing multiple contact points with the various customer stakeholder groups. As part of this shift, all project organization members are reeducated to understand that they have responsibility to maintain high levels of customer satisfaction; it is no longer the work of a select few.

CONCLUSIONS Customer-based project management represents a deceptively simple idea that has been yielding big dividends for the firms that have the vision to adopt it. These companies have been quick to grasp the significance of offering a new model of customer service and the advantages they can attain in the marketplace through its use. This

Page 208 book has been written to provide a framework for other project-based organizations to achieve similar competitive advantage in their particular industries. “People don’t mind change, but they hate being changed” is an adage many of us are familiar with. It gets to the heart of one of the chief difficulties in improving business operations for many organizations. Internal resistance is often so strong that nothing short of crises can move a critical mass of people out of their ruts. It took the threat of Chapter 11 bankruptcy and a dynamic new CEO, Lee Iaccoca, to bring about significant change at Chrysler. Likewise, many firms seem almost content to muddle along with outdated operating ideas, old products, and sagging revenues. Until presented with a do-or-die set of options, little is likely to change within the majority of these systems. Project firms may rapidly to approaching a point of huge shake-out in their various industries. The economic models of the past century are proving too elusive in offering the answers for practicing business today. Already, stock market analysts speak in terms of the new economy versus the old economy. The technology of the Internet is redefining competitive advantage around the globe. The practice of project management, so important for the coming years, offers another example of a basis by which successful and failing firms will be distinguished from each other. Successful project management is no longer a simple, triple constraint option. Getting it out the door fast, cheap, and on spec is not enough to guarantee future profits in a new international business climate. A new way of thinking about running a project organization is required. How are we going to set ourselves apart from the competition? How can we most directly add value to our client base? What is our competitive advantage? These are not idle questions. They will redefine how we must conduct our business. The answers we come up with will go far toward determining how well we are poised to survive and prosper into the future.

Page 209 Customer-based project management requires us to reanalyze our priorities. Who is number one, the cost accountant or the customer? The functional leader or the project manager? Clearly, we are not suggesting that these people are unimportant to the company, but when our project management becomes an exercise principally in internal efficiency and cost control we are missing the larger picture. Projects are done for a purpose; their purpose lies not just in how they are done. Put another way, doing things right is never as important as doing the right things. This book has been an attempt to resort operating goals, to ask project organizations and their top management to take a hard look at their principle project drivers and if they do not like what they find, ask the obvious follow-on question: What are you prepared to do about it? How can we reinvigorate the way we run projects in this company? Is the customer really in charge or just someone to be charged? When we re-recognize the key nature of our relationship with our customer base, everybody wins.

NOTES 1. S.C. Wheelwright and K. Clarke. (1992). “Creating Project Plans to Focus Product Development,’’ Harvard Business Review, 70 (2), pp. 70–82. 2. R. Katz and T.J. Allen. (1985). “Project Performance and Locus of Influence in the R&D Matrix,” Academy of Management Journal, 28(1), 57–87; D.H. Gobeli and E.W. Larson. (1987). “Relative Effectiveness of Different Project Structures,” Project Management Journal, 18(2), 81–85; and R.C. Ford and W.A. Randolph. (1992). “Cross-Functional Structures: A Review and Integration of Matrix Organization and Project Management,” Journal of Management, 18(2), 267–294.

Page 210


Page 211

INDEX Accountant (stakeholder), 146, 147, 152, 156 Aker Rauma Offshore (ARO), 175–191 American Standard Co., 130 Automakers, 15–16, 66–67, 71, 208 Autonomous team organization, 196, 198–199 Baker/Murphy/Fisher study, 82–85 Behavioral vs. technical factors, 81, 83, 84 Benchmarking superior service and inventory control, 122–123 Beta-testing, 53, 71 Bid price, 28 Boeing, 27, 107–108 BOOT (build/own/operate/transfer), 111, 115 Bottom-line thinking (cost vs. performance), 73–74, 129, 133–134, 193–195. See also Constraint(s) Build-up phase, 81, 82, 83 Business world, strong trends in: economic period marked by low inflation, 4 global markets, 3 increasingly complex and technical products, 3 requirement for higher profit from investments, 4 shortened product life cycles, 2 small product launch windows, 2 Buyer-vendor coordination, 114 Change: project modifications, 76–77 strategy (for changing to customer-based project organization), 171–173 Chrysler, 208 Clarke, Kim, 195 Client(s). See also Customer(s) acceptance (critical success factor), 86, 90 communication with, 86, 90, 94–96, 166–167, 201 consultation (critical success factor), 86, 88 stakeholders, 146, 147, 148–149, 156

Close-out, 81, 82, 83

Page 212 Communication: asking key informants about decision process and criteria, 167 with client/customer, 94–96, 166–167, 201 critical success factor, 86, 91 feedback to contact personnel (both internal/external), 170 three-way path of, 91 Competence in project-based firms, 6–7 Competition, and value-chain analysis, 138, 139 Competitive price, 28–30 Competitors (stakeholders), 147, 150 Computer software development projects, outcome studies, 65 Conflict: with customer, 202–203 among stakeholders, 155–158 Constraint(s): cost/money/budget, 14, 41, 65–66, 133 performance, 14, 41, 66, 133 quadruple model (adding customer satisfaction/acceptance), 15, 41, 67–68 stakeholder’s conflicting demands and, 156 structural/technical/behavioral, 34 teams, 34 time/schedule, 14, 41, 65, 133 triple model, 14–15, 41, 65–66, 67–68, 133, 156 Contract, 26–28 Contractors, potential adversarial relationships with, 134 Control systems/procedures, 53, 54, 58, 112, 115–116, 118, 122–124 document, 53, 54, 58 inventory, 122–123 operational planning and, 123–124 supply chain management, 112, 115–116, 118 Coordination/planning, 112, 113–115 Cost, 7–8, 9, 14, 41, 65–66, 73–74, 133, 156 balancing cost consciousness with project performance, 73–74 increasing demands for cost-consciousness, 9 stakeholder conflict and, 156 in triple constraint model, 14, 41, 65–66, 133 Critical Path Method, 38 Critical success factors (CSFs), 76–102

background, 80–85 Baker/Murphy/Fisher study, 82–85 behavior vs. technical (relative importance of), 81, 83, 84 communication, 86 definitions, 86–92 implications, 93–100 Morris study, 81–82 Pinto/Slevin study, 85 relative importance of, 93

Page 213 research on, 82, 83, 92–100, 101 ten-factor model, 85–93 Customer(s): defined, 7 focus, 8–14, 201–203 organization (stakeholder), 148–149 relationship management, 17, 18, 29, 163 satisfaction (nature of), 11, 13 Customer-based project management. See also Project management background, 33–59 balancing cost consciousness with project performance, 73–74 case study (see Rauma case study) concepts important to, 14–23 critical success factors, 79–102 implementing in your organization, 161–173, 193–209 product thinking, 19–21 project risk, 21–23 project stakeholder analysis, 143–159 project success/failure, 14–19, 61–78 rationale for, 1–32 requirements for philosophy to work (five), 173 success framework, 17–19 supply chain management, 103–126 term defined, 9 value chains and projects, 127–142 win-win, 31 Customer-based project organization, creating, 161–173, 193–209 asking key informants about decision process and criteria, 167 developing change strategy, 171–172 developing/refining list of critical issues, 168 “doing it right” vs. “getting it right,” 193 external analysis, 166 goals of, 162–163, 200–201 heavyweight project organizations, 195–199 implementing/monitoring changes, 172–173 implementing new approach (making it a project), 164–173 internal analysis, 165–166 making contact with customer base, 166–167

making customer-based approach work for you, 200–207 measurement parameters, 169–171 model for becoming, 161–173 product thinking, 204–206 risk reduction, 205–206 schedule, 165 stakeholder analysis, 168, 203–204 systematic implementation plan, 206–207 value chain analysis, 204

Page 214 Customer-based project organization, creating (Continued) work breakdown structure (WBS), 164 Death spiral, 128 Delivery process, 21 Dell Computer Corporation, 131 Department/functional managers vs. project managers, 146, 147, 152–153, 197 Department of Interior, 50 Distribution, 106, 110–112, 132 Distribution channel analysis, 118 Document control procedure, 53, 54, 58 “Doing it right” vs. ‘‘getting it right,” 193 English Channel, 69 Environmental analysis, 112, 113 Environmental/political/consumer groups (stakeholder), 144, 146, 147 Eurotunnel, 34, 69 External analysis of business focus, 166 External concerns vs. internal performance, 133–134 External environment (stakeholder), 146, 147 External risks, 22 Fabrication, 106, 109–110 Failure rates. See Project failures Ford Motor Company, 15–16, 66–67, 71 Frame, David, 6–7 Functional managers (stakeholders), 146, 147, 152–153, 197 Functional project organization, 196–197 Gates, 48 General Electric, 26, 48, 105, 109, 132 Global competition, 3, 9, 62 Global outsourcing, 105 Goal(s), 112–113, 118, 162–163, 200–201 of model, 162–163 supply chain management, 112–113, 118 Goldratt, Eli, 108

Health/safety/environmental (HSE) risks, 21, 51 Heavyweight project organization, 195, 196, 197–198 Iaccoca, Lee, 208 IBM, 62 Implementation: failure, and lack of troubleshooting mechanisms, 100 hurdles, 16–17, 20 organizational effectiveness, 16–17, 20 organizational validity, 16, 20 technical validity, 16, 20 of model in your organization, 161–173, 193–209 process (four-stage life cycle): build-up, 81, 82, 83

Page 215 close-out, 81, 82, 83 main phase, 81, 82, 83 team formation, 81, 82, 83 steps in effective, 7 systematic plan for, 206–207 Inflation, 4 Infrastructure, 17–18, 163, 201 Instructions, 53, 54, 57–58 Internal analysis, 165–166 Internal stakeholders, 147 Intervenor groups (stakeholders), 151 Inventory/benchmarking, 120, 122–123 Investments, requirement for higher profit from (trend), 4 Just-in-time (JIT) inventory, 120 Laxell, Pekka, 178 Lightweight project organization, 196, 197 Lockheed Corporation, 198 Long-term vs. short-term assessment of success, 69, 74–75, 134 Metrics, 169–171, 196, 199 Mission/objectives, 53, 54, 86, 93–94 Money/budget constraint on projects, 14, 41, 65–66, 133 Monitoring/feedback (critical success factor), 86, 90 Morris study, 81–82, 87 Neuvo, Risto, 179–185 Oil industry, 5, 27 Operational planning and control (PSCM), 123–124 Organizational effectiveness, 16–17, 20, 127–128 Organizational validity, 16, 20 Organization risks (category of project risks), 22 Outcome evaluation, 61–78 Parent organization (stakeholder), 146 Pells, D., 49

Performance constraint, 14–15, 41, 66, 73–74, 133–134, 156 Personnel/staffing, 86, 88–89, 98 Pilot project, 54, 57, 58 Pinto/Slevin study, 85 PI-Rauma. See Rauma case study Plan/planning, 24–25, 26, 27, 46–52, 86, 97–98, 112, 113–115, 123–124, 206–207 critical success factor, 86 element of project contract, 26, 27 operational planning and control, 123–124 phase of project life cycle, 24–25 project execution plan (PEP), 46–52 project management plan (PMP) introduced by Pells, 49 scheduling system, 86, 97–98 supply chain management, 112, 113–115

Page 216 Plan/planning (Continued) systematic implementation plan, 206–207 Porter, Michael, 135 Price: competitive, 28–30 contract element, 26, 27 and risk-weighted assessment of customer’s project cost, 29 squeeze, 129 Procurement, 106, 107–109 Product(s): business trends, 2, 3 increasingly complex/technical, 3 must be used to be successful, 75 rapid obsolescence, 62 shortened life cycles, 2 smaller launch windows, 2, 69–70 thinking, 19–21, 204–206 Production-distribution coordination, 114–115 Profiling your organization, 199–200 Profit-oriented thinking (cost vs. performance), 73–74, 128, 129, 133–134, 193–195. See also Constraint(s) Project(s): competitive price, 28–30 constraints on (triple model: time/cost/performance), 14–15, 41, 65–66, 67–68, 133, 156 adding fourth constraint (client acceptance), 15, 41, 67–68 defining, 34–40 four common characteristics of, 35–36 clearly defined objectives, 38–39 complex/interrelated activities, 37–38 finite budget/schedule constraints, 36–37 uniqueness, 39–40 implementation phase (see Implementation) life cycle, 11, 24–26, 81, 82, 83 modification of, 76–77 outcomes (see Critical success factors (CSFs); Project failures; Project success) well known examples of, 34–35 Project execution plan (PEP), 46–52 how to compose, 52–59

phases in, 53 Project failures, 5–6, 7, 65, 72–73 common sources of project difficulties, 72–73 recent research examples, 5–6 Project life cycle, 11, 24–26 conceptualization, 24 as distinct phases, 24–25 execution phase, 25 planning phase, 24–25 termination phase, 25 two ways to view, 24 Project management. See also Customer-based project management advantages and challenges, 62 contract, gaining the, 26–28

Page 217 defining, 40–42 important concepts, 14–23 product thinking, 19–21 project risk, 21–23 project success, 14–17 success framework, 17–19 lines of responsibility, 63 new model for, 30–31, 162–163 opportunities and challenges, 2 outcome assessment (see Project success) points to remember, 73–77 in success framework, 29 terminology/processes (short primer), 33–59 underlying reasons for explosive growth and interest in, 1–2 unique setting of, 61–64 Project Management Association, 1 Project Management Institute, 35 Project Management Plan (PMP), 49 Project manager: vs. functional managers, 146, 147, 152–153, 197 organization and role of, 196–199 Project organization: autonomous team, 196, 198–199 functional, 196–197 heavyweight, 196, 197–198 lightweight, 196, 197 types of, 196 Project stakeholder(s), 143–159 accountants, 146, 147, 152, 156 analysis of, 121–122, 203–204 clients, 146, 147, 148–149, 156 competitors, 147, 150 conflict among, 155–158 cost/schedule/performance, and conflicting demands of, 156 customer organization, 148–149 environmental/political/consumer groups, 147 external environment, 146, 147 functional managers, 146, 147, 152–153

identifying, 146–154 internal, 147 intervenor groups, 151 managing, 154–155 parent organization, 146 project team, 146, 147, 153–154, 156 supply chain, 121–122, 147, 150–151 top management, 146, 147, 151–152, 156 Project success, 14–19, 29, 61–78, 133–135, 140–141, 163 basic elements of (success framework), 17–19, 29, 163 concept of, 14–17, 133–135 evaluating/classifying, 61–78 external concerns vs. internal performance, 133–134 framework of, 17–19, 29, 163 customer relationship management, 17, 29, 163

Page 218 Project success (Continued) infrastructure, 17, 29, 163 project management, 17, 29, 163 quality standard, 17, 29, 163 supply-chain management, 17, 29, 163 short-term vs. long-term assessment of success/failure, 69, 74–75, 134 over time, 68–73, 134 unique setting of project management, 61–64 value chains and, 140–141 Project supply chain management (PSCM), 17, 29, 30, 49, 103–126, 147, 150–151, 163 analysis of strengths/weaknesses, 117 approved vendors, 120 benchmarking, 122–123 buyer-vendor coordination, 114 challenges in effective, 119–125 components of supply chain, 106–112 control, 112, 115–116, 118, 123–124 coordination/planning, 112, 113–115 designing/setting up project supply chain, 112–119 diagram, 105 distribution, 106, 110–112, 118 environmental analysis, 112, 113 fabrication, 106, 109–110 goals, 112–113, 118 modeling, 118 operational planning/control, 123–124 proactivity, 119 procurement, 106, 107–109 production-distribution coordination, 114–115 project execution plan, 49 stakeholders and, 121–122, 147, 150–151 steps in developing a project supply chain, 112 top down approach, 117 tracking work in process, 120–121 vs. traditional supply chain management, 104, 105 vendor analysis, 118 what-if analysis, 124–125 Project team(s), 34, 42–46, 81, 82, 83, 146, 147, 153–154, 156, 196, 198–199

autonomous, 196, 198–199 behavioral constraints, 34 constraints on, 34 differences between department and project management, 45 formation phase, 81, 82, 83 functional organization with, 43 members as stakeholders, 146, 147, 153–154, 156 staffing, 42–46 structural constraints, 34 technical constraints, 34 Quality assurance (QA) standard, 17, 29, 30–31, 53, 54, 58–59, 109, 120, 138, 163, 166, 201 Quality chain, 30–31, 138

Page 219

Rauma case study, 175–191 first major delivery project, 188–190 framework, 181–188 Mantyluoto Works, 177, 183 new start, 178–188 PI-Rauma, 177, 183, 187 Rauma Offshore Contracting, 177–188 renamed Aker Rauma Offshore, 190 restructuring, 177–178 success record, 191 Request for Proposal (RFP), 12 Risk, 9, 21–23, 29, 205–206 categories of, 22 external, 22 health/safety/environmental (HSE) risks, 21, 51 minimizing, 9, 205–206 organization, 22 weighted assessment of customer’s project cost, 29 Schedule(ing): constraint, 14, 41, 65, 133 critical success factor (CSF), 86, 87–88 for implementing customer-based approach to project management, 165 setting up/maintaining system, 97–98 Schultz, Randy, 16 Scope, basic element of project contract, 26, 27 Short-term vs. long-term focus, 69, 74–75, 134 Skunkworks, 198 Slevin, Dennis, 16 Stakeholders. See Project stakeholder(s) Success framework, 17–19, 29, 163. See also Project success customer relationship management, 17, 29, 163 infrastructure, 17, 29, 163 project management, 17, 29, 163 quality standard, 17, 29, 163 Rauma case study, 181–188 supply-chain management, 17, 29, 163

Suppliers (stakeholders), 147, 150–151 Supply chain management, 17, 29, 163. See also Project supply chain management (PSCM) Teams. See Project team(s) Technical tasks (critical success factor), 86, 89 Technical validity, 16, 20 Technology: fabrication and, 110 project requirements, 96–97 utility of (vs. technology for technology’s sake), 75–76 Ten-factor model. See Critical success factors (CSFs): ten-factor model Time: short-term vs. long-term assessment of success/failure, 74–75, 134 triple constraint model, 14, 41, 65, 133

Page 220 Top management: critical success factor, 87, 98–99 stakeholder analysis, 146, 147, 151–152, 156 Training, 7, 53, 54, 89 Troubleshooting, 86, 92, 100 Value, 127–142, 204 chains, 127–142 customer-determined, 129–133 Value chain analysis, 135–140, 204 constructing client’s value chain, 136–138 four distinct steps in, 136 identifying activities/linkages inferior to competition, 139 identifying activities/linkages superior to competition, 138 overview, 137 targeting activities/linkages with high potential for impact, 139 Value chain management (VCM), 127–142 customer satisfaction as watchword, 131 vs. efficiency-only mentality, 129 vs. supply chain management, 127 Vendor(s): analysis, 118 approved, 120 buyer coordination, 114 Welch, Jack, 4 “What if” analysis, 99–100, 124–125 Wheelwright, Steven, 195 Work breakdown structure (WBS), 56, 164 Work in process, tracking, 120–121

Building Customer-Based Project Organizations

Learning by Design: Building Sustainable Organizations (Management, Organizations and Business)

Alliances, Coalitions and Partnerships: Building Collaborative Organizations

Building Feminist Movements and Organizations: Global Perspectives

Building Project-Management Centers of Excellence

How to run successful high-tech project-based organizations

Trust and trouble: Building interpersonal trust within organizations Organizational psychology

8 Steps to Building Innovating Organizations (Response Books)

International Directory of Building Research Information and Development Organizations

Building More Effective Organizations: HR Management and Performance in Practice

Building Innovation Capability in Organizations: An International Cross-case Perspective

Project

Global Organizations

Transforming Organizations

Franchise organizations

Transformative Organizations

Organizations Express

Inquiring Organizations

Experiencing Organizations

Transforming Organizations

Meta-organizations

Building

Project Silver Bug. Project № 9961

Brooklyn Project

Project Aura

Project Hush

Project Megiddo

Project Gutenberg

Building Customer-Based Project Organizations

Learning by Design: Building Sustainable Organizations (Management, Organizations and Business)

Alliances, Coalitions and Partnerships: Building Collaborative Organizations

Building Feminist Movements and Organizations: Global Perspectives

Building Project-Management Centers of Excellence

How to run successful high-tech project-based organizations

Trust and trouble: Building interpersonal trust within organizations Organizational psychology

8 Steps to Building Innovating Organizations (Response Books)

International Directory of Building Research Information and Development Organizations

Building More Effective Organizations: HR Management and Performance in Practice

Building Innovation Capability in Organizations: An International Cross-case Perspective

Project

Global Organizations

Transforming Organizations

Franchise organizations

Transformative Organizations

Organizations Express

Inquiring Organizations

Experiencing Organizations

Transforming Organizations

Meta-organizations

Building

Project Silver Bug. Project № 9961

Brooklyn Project

Project Aura

Project Hush

Project Megiddo

Project Gutenberg

Recommend Documents