1

Strategic Role of the PM Toolbox

Conventional wisdom holds that individual project management (PM) tools are enabling devices to reach an objective or, more specifically, a project deliverable. While this traditional role of PM tools is more than meaningful, we believe that there is more to the tools than that. In particular, PM tools can be used as basic building blocks to construct a PM toolbox. In this new role, the PM toolbox supports the standardized project management (SPM) process. The goal of this chapter is to

• Clarify the new role.
• Explain its strategic importance.

To accomplish these objectives, we first present an overview of the new role. Then, special aspects of the role are explained.

The New Role of the PM Toolbox

As shown in Figure 1.1, a typical SPM process includes process phases, milestones, technical deliverables, and managerial deliverables. Supporting it in its new role is the PM toolbox (at this time, we only focus on managerial deliverables and the PMtoolbox). Two principles are important in the support. First, each managerial deliverable is specifically supported by a specific tool or tools. That means that each of these tools is selected because of its systematic procedure to help produce the deliverable. Second, the PM toolbox is constructed to include all tools necessary to complete the whole set of SPM processes' managerial deliverables, which we have emphasized in Figure 1.1 by shading the deliverables and toolbox. This implies that the PM toolbox is designed for the specific SPM process. If this principle were not met, we would not have the toolbox. Rather, we would have a set of individual tools, performing the conventional role of PM tools. Technical deliverables and their tools are project type-specific and are beyond the scope of this book.

The value of the new role of the PM toolbox is obvious. Designed as a set of predefined PM tools, the PM toolbox supports SPM process by providing a practical and tangible, yet systematic, way of producing a set of the process's managerial deliverables. That this support has a strategic meaning can be seen in Figure 1.2. As shown by upward arrows, the PM toolbox supports SPM process that helps implement PM strategy, which supports the competitive strategy of the company in its quest for survival and growth. For this upward chain of support to work, competitive strategy has to drive PM strategy, which drives SPM process, which drives PM toolbox design (downward arrows). Evidently, the new role of the PM toolbox is played in the wider, strategic context of PM. That calls for dissecting the context, its elements, and their relationships, which we will do next.

Figure 1.1 An example of the standardized project management process with the corresponding project management toolbox.

Figure 1.2 Project management toolbox pyramid.

PM Strategy Supports Competitive Strategy

Looking into the strategic context of PM will help us understand the special aspects of the new role of the PM toolbox, which is how the PM toolbox's support of the SPM process has to be aligned with the competitive strategy. Since the alignment is driven from the top of the pyramid (see Figure 1.2), we start from there—the competitive strategy.

The essence of such strategy lies in creating competitive advantages that give a company an edge over its rivals [1]. To equip themselves with the advantages, companies rely on their organizational resources [2]. Visualize, for example, PM as an organizational resource. Useful for this visualization can be the framework of generic competitive strategies (further competitive strategies), shown in Figure 1.3 [3].

The core of differentiation strategies (high differentiation/high cost quadrant in Figure 1.3) is an ability to offer customers something different from competitors. This may include fast time –to market (which we used as an example in Figure 1.3), high quality, innovative technology, special features, superior service, and so on. When striving for product superiority, companies pursuing these strategies build in whatever features customers are willing to pay for. That enables them to charge the premium price to cover the extra costs for differentiating features [4].

Figure 1.3 Examples of project management strategies, processes, and toolboxes supporting competitive strategies.

Companies focusing on low-cost strategies aim at establishing a sustainable cost advantage over rivals (low cost/low differentiation quadrant in Figure 1.3). The intent is to use the low-cost advantage as a source of underpricing rivals and taking market share away from them. Another option is to earn a higher profit rate by selling at the going market price [5]. This is pursued with a good basic product that has few frills, along with a continuous quest for cost reduction without giving up quality and crucial features.

Best-cost companies combine upscale features with low cost (low cost/high differentiation quadrant in Figure 1.3). This should lead to superior value by meeting or exceeding customer expectations on product features and surpassing their expectations on price. At the same time, the aim is to become the low-cost provider of a product that has good-to-excellent features and use that cost advantage to underprice rivals with comparable features. Because such a company has the lowest (best) cost compared with similarly positioned rivals, the strategy is called best-cost strategy. The blank quadrant in Figure 1.3 of high cost/low differentiation is not a viable option in competitive battles for survival and prosperity.

Now let's use the framework of competitive strategies to see how PM helps create the competitive advantages. Examples of three companies—Intel, Armstrong World Industries (AWI), and Oregon Anesthesiology Group (OAG)—will help us illustrate the point. Intel's competitive strategy is one of differentiation (see Figure 1.3). The strategy targets innovation and time-to-market speed as competitive advantages. In it, a significant role belongs to product development projects, whose job is to roll out new computer chips faster and faster. This is where PM comes into play, focusing on shrinking the chip development projects cycle times and hitting the market before the competition. We have observed the same passion for schedule acceleration in projects implemented in other non-product development activities of Intel as well, from large fab construction to small quality improvement projects. This certainly is not a random act. Rather, it is a management choice to deploy PM in order to help build the advantages through the accomplishment of ever-shorter project cycle times throughout the company.

Other companies with the differentiation strategy also work hard to create competitive advantage through the reduction of project cycle times. Firms such as General Electric, NEC, Northern Telecom, and AT&T managed to reduce their average cycle times by 20 percent to 50 percent [5]. The power of fast cycle time lies in its consequences. For example, in product development, the company that hits the market before there is competition will often enjoy premium pricing, extended product sales life, higher profit margins, and increased market share [6–8].

AWI's competitive strategy is quite different from Intel's. Instead of differentiation and time-to-market emphasis that Intel relentlessly pursues, AWI has set out to become the cost leader in the industry (low cost/low differentiation quadrant in Figure 1.3). As a plant manager put it: “We have been in the business of manufacturing building materials for over 70 years. Technological change is not a major factor in our industry; rather, it is the ability to compete on low cost. To develop the ability and become the leader in the industry, we have had to streamline every possible manufacturing-related process and continuously lower the bar for our manufacturing cost goals. Part of that effort has been the process for managing our cost cutting and manufacturing process development projects.” An equal zeal for cost cutting in other non-manufacturing projects of AWI is also noticeable. Manufacturing and non-manufacturing areas are apparently where PM focused on lowering project cost goals, and they support AWI's low-cost advantages.

This is no secret to other firms using PM to support the same low-cost strategy. The reason is in the increased magnitude of project cost and the cost pressures many leading companies are facing. When an enterprise resource-planning project may cost $300M [9] or fab may cost $4B [10], companies have to reduce the cost and pressures with the goal of creating low-cost competitive advantages [11]. Such PM support helps them build larger market share and higher profits [2].

Intel and AWI's competitive advantages exploit their schedule- and cost-focused PM, respectively. In contrast, OAG (Oregon Anesthesiology Group) relies on a best-cost PM (low cost/high differentiation quadrant in Figure 1.3). In this corporation of some 190 medical doctors, the goal is to have the best cost relative to competitors whose health care services are of comparable quality [4]. Accordingly, their PM aims at accomplishing such cost and quality goals. Says a vice president of OAG, “In a cutthroat market as ours, health management organizations have been putting a relentless pressure on all care providers to cut costs. To stay afloat, we standardized our PM protocols in all of our information systems and continuous quality improvement projects. That helped us bring our projects within cost and quality goals. If not so, our customers will take their business somewhere else.” Using its cost/quality advantage, OAG has been able to hold a commanding share of its market.

Other experts confirm that a cost/quality combination is pursued as a project goal in some firms [12]. The bottom line is that the companies focused on the best-cost strategy and related competitive advantages need PM that supports such strategy.

In summary, these examples provide a context that we need to construct a common base of understanding:

• Companies choose their competitive strategies.
• Companies align their PM strategy with the competitive strategies.

First, companies select competitive strategies as a means of competing with their rivals in the marketplace. Although each type of the competitive strategy has the same goal—create competitive advantages—ways to accomplish the goal differ. One builds the advantages on the basis of differentiation, another on low cost, and still another on best-cost approach. Second, companies strategize their PM. The objective is to align PM strategy with the selected competitive strategy. Consequently, in the case of Intel, AWI, and OAG, each company's perspective of how PM strategy should be focused is different: schedule focus (Intel), cost focus (AWI), and cost/quality focus (OAG). No wonder then that some prominent researchers view PM as one of the crucial threats, as well as an opportunity that managers encounter in their competitive battles [13].

While PM strategy has a significant role to play, it is by no means the only driver in the competitive strategy pursuit. Rather, other business strategies—often referred to as functional strategies [2]—are required to make the competitive strategy work. In particular, also contributing are research and development, marketing, manufacturing, human resource strategies, and so on.

So far we have been shedding light on the context of the PM toolbox's support of the SPM process. We need to continue with the context, providing more details on the SPM process, before we return to the details of the role.

Standardized PM Process Supports PM Strategy

As shown in Figure 1.2, the SPM process supports the PM strategy. Or, to put it differently, the SPM process serves as a mechanism for delivering PM strategy. To clarify this, we will offer the following:

• Some empirical examples that the SPM acts as a support mechanism for PM strategy
• The SPM process elements through which the support occurs
• The meaning of standardized
• The way to align SPM process with PM strategy

We begin with the examples of the empirical evidence. In a recent report the Fortune 500 PM Benchmarking Forum asserts that 85 percent of their members use standardized approaches and procedures when managing projects [14]. Similarly, many software organizations utilize the Capability Maturity Model. They aim at delivering their projects through the standardized PM process. Driven by the same goal of standardizing their PM processes, some organizations seek ISO 9000 certification of their PM. Finally, other organizations implement PM maturity models in an attempt to gradually improve management of projects through an SPM process [15].

To summarize, there is a significant interest in SPM process as a delivery mechanism for PM strategy [16]. In delivering PM strategy, SPM process implements several elements (Figure 1.1):

• Project life cycle phases
• Managerial and technical activities
• Deliverables
• Milestones

Project life cycle is viewed as a collection of project phases determined by the control needs of the organizations involved in the project. Consequently, a variety of project life cycle models are in use in corporations today. Some of them are traditional models, including phases of concept, definition, execution, and finish. While they may be losing their appeal for their generic nature, the new ones that are more industry-specific have emerged and gained in popularity. One example is the concurrent engineering process, which for ease of understanding is illustrated in Figure 1.1 as being sequential. Another example includes the evolutionary-delivery model in software development projects [17].

Project life cycle phases are composed of logically related project activities. The activities can be divided into two groups: managerial and technical activities. The former are activities by which we manage a project; develop the project scope and construct the project schedule are typical examples. They are similar across project types—construction, software, marketing, or financial type of project.

Where these project types really vary is with regard to technical activities. For example, technical activities characteristic of software projects would include requirements definition or beta testing. Such activities do not exist in a construction project, where examples of typical technical activities are pre-job meeting and punch list development. In short, technical activities take care of managing the project product. Naturally, then, they are project-type-specific and reflect the nature of the project product.

Both PM and technical activities usually culminate in the completion of deliverables—that is, tangible products in the SPM process. Managerial activities produce managerial deliverables (also called PM deliverables) such as scope defined or risk review (Figure 1.1). Technical activities lead to technical deliverables—for example, product data sheet, system test, and manufacturing ramp ready. As we refer to these deliverables in Figure 1.1, note that we opted to show deliverables only along with milestones that signify the end of a phase. To simplify the figure, managerial and technical activities are left out.

When not explained, the word standardized in SPM process may create confusion. What does it really mean? If we define SPM process as a standardized sequence of project activities (that culminate in project deliverables), then standardized means the degree of absence of variation in implementing such activities [18]. Let's use Figure 1.4 to explain this. On one extreme, there may be a complete variation in a PM process. Literally, every time the PM process is performed, it is performed in a different way. Obviously, 100 percent variation means that standardization is equal to 0. This is often referred to as an ad hoc approach. On the other extreme, a certain process may be 100 percent standardized, meaning that every time it is performed in the same way. In this case, variation is 0 percent. Between the two extremes lies a continuum of many PM processes with different ratios of the standardization and variation.

Take, for example, process L on the x-axis, one of the many possible PM processes. As Figure 1.4 shows, the degree of standardization and the degree of variation add up to 100 percent. If we go down the diagonal line to other PM processes, while the degree of standardization will increase, the degree of variation will decrease, but their sum will remain constant at 100 percent. Moving up the diagonal line will lead to a higher variation and lower standardization, still with the sum of 100 percent. Using plain language, the lower the variation, the higher standardization, and vice versa, and the more varied the implementation of project activities, the less standardized they are.

Speaking in practical terms, this means that organizations have a host of options when developing an SPM process—they can be more standardized or less standardized. Therefore, they need to decide on the level to which they want to standardize the PM process. The rationale of standardization is to create a predictable process that prevents PM activities from differing completely from project to project, from project manager to project manager. Put simply, SPM process saves project people the trouble of reinventing a new process for each individual project [19]. As a result, the process is repeatable despite changes in customer expectations or management turnover. The higher the standardization, the higher the repeatability.

Figure 1.4 Continuum of project management processes.

The decision about how much to standardize the SPM process is the decision about the ratio of standardization and variation (popularly called flexibility). It is driven by PM strategy, or more precisely, by the types of projects the PM strategy deals with. Generally, PM strategy for projects of higher certainty will strive for higher levels of standardization and lower levels of flexibility. According to experts, the majority of projects in organizations belong to this group [20]. PM strategy for projects that face high uncertainty dictates lower standardization and higher flexibility. More details about this are provided in Chapter 16. When we use the term SPM process in this book, we mean it is standardized over 50 percent.

We started this section arguing that the SPM process supports PM. For this to be possible, the SPM process has to be aligned with PM strategy. In particular, when PM strategy is schedule focused, cost focused, or cost/quality focused, the SPM process will follow suit. That means the SPM process's disciplined and interrelated set of phases, deliverables, and milestones will be schedule focused, cost focused, or cost/quality focused (see Figure 1.3). Closely intertwined with the process are other PM components—project organization, information technology, culture, and leadership. In other words, the SPM process does not act alone but in synergy with these PM components in delivering PM strategy.

PM Toolbox Supports Standardized PM Process

In providing details of how the PM toolbox functions in its new role of supporting the SPM process, we do the following:

• Define PM tools and toolbox.
• Describe two options for the PM toolbox.
• Explain how SPM process drives the alignment of the PM toolbox.
• Compare benefits of one-tool-at-a-time versus the PM toolbox approach.
• Clarify the standardization of the PM toolbox.

Defining the PM Tools and Toolbox. PM tools include procedures and techniques by which a PM deliverable is produced. Similarly, A Guide to the Project Management Body of Knowledge [21, 22] and other sources use the term “tools and techniques” in place of what we define as PM tools. Two examples of such tools are the Team Charter and Monte Carlo analysis. They differ in the type of information they process. The Team Charter provides a systematic procedure to process qualitative information about authorizing a team to implement a project. On the other hand, Monte Carlo analysis is a risk-planning tool that also specifies the systematic procedure. This time it does that by means of an algorithm in order to quantify risks. In other words, it is a quantitative tool. The heart of both the qualitative and quantitative groups of tools—and all PM tools belong to one of these groups—is in their systematic procedure. Note that we don't talk about PM software tools here. True, many PM tools that we discuss in this book exist in a software format. However, our focus is not on such formats. Rather, we concentrate on the substance of PM tools: their systematic procedure.

Two Options for the PM Toolbox. We define the PM toolbox as a set of predefined PM tools that a project manager can use in managing an SPM process. Two options are available in using the PM toolbox. In the first option, each tool in the toolbox is chosen to support specific managerial deliverables in the SPM process. For example, two tools in Figure 1.1 numbered S.1 are WBS (Work Breakdown Structure) and Scope Statement. They support the accomplishment of the managerial deliverable S.1 Scope Defined (in this figure other PM tools and managerial deliverables they support are also correspondingly numbered). Also, the PM toolbox is designed to comprise all tools one needs to implement the whole SPM process and accomplish its set of deliverables.

In the second option, the idea is to replace managerial deliverables with the PM toolbox. As for Figure 1.1, that means taking the managerial deliverables out and putting the PM toolbox in their place. The idea here is to conceive individual tools in the PM toolbox as proxies for managerial deliverables. Take, for example, the managerial deliverable Schedule Developed. It can be replaced with a specific tool—Gantt Chart or Milestone Chart. Or, think of the managerial deliverable Projects Selected. Instead of this deliverable, we can use a PM tool called Scoring Model, which rates, ranks, and selects new projects. Obviously, the second option demands us to think of PM tools in radically new ways. Rather than focusing on the process of the tool, as has been traditionally done, we emphasize its use to produce an output—which is actually the deliverable. Therefore, each tool in the PM toolbox can be visualized as a deliverable. Similarly, the PM toolbox can be envisaged as a set of managerial deliverables in the SPM process. The first benefit here is that we simplify the SPM process by taking one layer out of it—managerial deliverables. Still, the project manager and his or her team have a road map (systematic procedure) to create the whole set of managerial deliverables.

How SPM Process Drives the Alignment of the PM Toolbox. Real-world companies use both options for the PM toolbox, the first one more frequently [23]. Whichever option is chosen, the PM toolbox has to be aligned with the SPM process. As illustrated in Figure 1.3, the focus of PM strategy is aligned with the competitive strategy. Since SPM process is part of this PM focus, it is logical that the PM toolbox will have the same focus. In particular, the SPM process of schedule focus, cost focus, or cost/quality focus will drive the PM toolbox to have schedule focus, cost focus, or cost/quality focus, respectively.

Comparing Benefits of One-Tool-at-a-Time versus the PM Toolbox Approach. Regardless of their competitive strategy, today's companies that are suppliers of projects face a competitive reality: their customers have taken charge. Customers tell the companies what they want, when they want it (as fast as possible—high speed), how they want it (as good as possible—better quality and customer satisfaction), and how much they are willing to pay (as low as possible—low cost) [20]. And the companies listen; satisfied customers are critical for a company's economic returns. In 1997 companies that reached higher customer satisfaction created over 100 percent more shareholder wealth than their competitors, with lower customer satisfaction scores [24]. As a result, there is no such a thing as the customer; there is only this customer, the one using his or her power and ability to demand. To respond to these demands, leading companies make sure that they build an SPM process capable of delivering projects with the following:

• Speed
• Repeatability
• Concurrency

A crucial role in this effort belongs to the PM toolbox. Let's explore each one in turn.

Speed. This is the ability of an organization to deliver a project in a fast manner. While what is meant by fast may vary, it means that fast is competitive. In one case, fast meant that the cycle time had to be reduced from 18 months to 9 months for an organization to keep up with the competition. For this to be possible, many components in the SPM process must be present. For example, there must be within- and across-phase overlapping of project activities, non-speed-adding activities have to be eliminated as well as any other redundancies, and so on. What this really means is having an SPM process that is streamlined to be fast to deliver per-customer demands.

Repeatability. Delivering a project with speed is not enough unless it is repeatable. That means there is the organization's ability to deliver a stream of consecutive projects consistently per customer requirements, one after another, every time. We call this longitudinal repeatability. If that requirement is speed, for example, then each delivered project is consistently fast. Repeatable projects minimize variation in how they are executed, improving speed and quality. Improvements in quality lead to lower cost because they result in less rework, fewer mistakes, fewer delays and snags, and better use of time. With higher speed, better quality, and lower cost, the organization can better respond to customer demands and make them satisfied.

Concurrency. In addition to speed and repeatable consecutive projects, responding to the customer demands also requires an ability to deliver a host of simultaneous projects, which are typically interdependent. We call this lateral repeatability, a different challenge from the longitudinal one. Here, some projects are large, others small. Since they are interdependent and share the same pool of resources, the challenge is to execute all of them in parallel, as a concerted group. No variation is allowed in any one; each needs to maintain speed and quality. If they don't, they will make others slip, increase cost, and make the customer unhappy. Similar to the longitudinal repeatability, minimizing the variation in each project will trigger speed and quality improvements that lead to lower cost, again contributing to meeting customer demands and satisfaction.

To reach this level of speed, repeatability, and concurrency, the heroic approach of “get the best people, pour all resources they need, and they will produce a great project” cannot help. Rather, a strong SPM process supported by PM tools is necessary. Empirical evidence that PM tools impact project success already exists [25][26]. The problem is when a project manager is given an SPM process but is left with a task of determining which tool and how to use it to support the process.

Selecting PM tools one at a time demands a substantial amount of resources and expertise. It is not reasonable to presume that each project manager—especially if he or she is less-than-experienced, as is the case with many—would have the resources and expertise to quickly, smoothly, and consistently select his or her own set of tools. Rather, such managers end up struggling to find the right PM tools and how to use them, introducing variability in the SPM process. This may lower the speed and make projects less repeatable and concurrency less likely (see Table 1.1). In contrast, project managers given the SPM process and the PM toolbox know exactly which tool and how to use it in order to support the process. In other words, they have a standardized PM toolbox capable of supporting an SPM process with minimum variation. As a result, their projects may have higher speed, more repeatability, and concurrency (Table 1.1)

Table 1.1: One-Tool-At-A-Time vs. the PM Toolbox Approach

Standardization of the PM Toolbox. Very often, project managers assume that the PM toolbox is of a one-size-fits-all nature. This, of course, is incorrect. The PM toolbox can come in many sizes, shapes, and flavors, as we will show in Chapter 16. Logically, this is an issue related to the SPM process and types of projects the process serves. Since the PM toolbox is aligned with the SPM process, it is apparent that the level of standardization of the SPM process impacts the standardization level of the PM toolbox. For example, an SPM process that is highly standardized will probably be supported by a highly standardized PM toolbox, and vice versa.

Concluding Remarks

PM tools serve two roles in supporting the SPM process. First, in their conventional role, the tools are enabling devices for reaching a project deliverable in the SPM process. Second, in their new role, they serve as basic building blocks to construct the PM toolbox, which supports the SPM process.

Many organizations rely on the SPM process when delivering PM strategy. The process is a standardized, disciplined, and interrelated set of phases, deliverables, and milestones that each project goes through. Closely intertwined with the process are other PM components. These include project organization, information technology, culture, and leadership. Together, they help deliver PM strategy.

PM strategy is crucial in supporting the execution of the competitive strategy of an organization. Truly, project management strategy is carefully concocted and aligned with the specific type of competitive strategy. The goal, of course, is to deliver a desired punch—schedule-focused, cost-focused, or cost/quality-focused PM strategy. Combined with other business strategies, project management thus has become a business strategy of choice in today's corporations.

In the world of cutthroat competition, it takes competitive advantage to win. These advantages come in all sorts of shapes. Some are called fast time-to-market advantages [27]. Others are of the low-cost nature. Still others are in having the lowest cost for a certain level of quality. No matter what they are, the advantages do not come about spontaneously. Rather, they are an outcome of organizations executing their competitive strategies. In summary, the role of the PM toolbox is to support SPM processes that help deliver PM strategy. By supporting the competitive strategy, the PM strategy helps create competitive advantages for the company

The ability to design a PM toolbox is closely related to the reader's knowledge of individual PM tools. To help the knowledge get to the appropriate level, chapters that follow will review the tools. Then, in chapter 16 we will offer the methodology to design the toolbox.

References

1. Hamel, G. and C. K. Prahalad. 1989. “Strategic Intent.” Harvard Business Review 67(3): 92–101.

2. Harrison, J. S. and C. H. S. John. 1998. Strategic Management of Organizations and Stakeholders. St. Paul, Minn.: South-Western College Publishing.

3. Porter, M. E. 1985. Competitive Advantage. New York: The Free Press.

4. Thompson, A. A. and A. J. I. Strickland. 1995. Crafting and Implementing Strategy. Chicago: Irwin.

5. Adler, P. S., et al. 1996. “Getting the Most out of Your Product Development Process.” Harvard Business Review 74(2): 134–152.

6. Calantone, R. J. and C. A. D. Benedetto. 2000. “Performance and Time to Market: Accelerating Cycle Time with Overlapping Stages.” IEEE Transactions on Engineering Management 47(2): 232–244.

7. Nevens, T. M., G. L. Summe, and B. Uttal. 1990. “Commercializing Technology: What the Best Companies Do.” Harvard Business Review 68(3): 154–163.

8. Smith, P. and D. Reinertsen. 1990. Developing Products in Half the Time. New York: Van Nostrand Reinhold.

9. Mclemore, I. 1999. “High Stake Games.” Business Finance (5)30–33.

10. Iansiti, M. and J. West. 1997. “Technology Integration Turning Great Research into Great Products.” Harvard Business Review 75(3): 69–79.

11. Wheelwright, S. C. and K. B. Clark. 1992. Revolutionizing Product Development. New York: The Free Press.

12. Clark, K. B. and T. Fujimoto. 1991. Product Development Performance. Boston: Harvard Business School Press.

13. Cusumano, M. A. and K. Nobeoka. 1998. Thinking Beyond Lean. New York: The Free Press.

14. Tony, F. and R. Powers. 1997. Best Practices of Project Management Groups in Large Functional Organizations. Drexel Hill, Pa.: Project Management Institute.

15. Kerzner, H. 2001. Strategic Planning for Project Management. New York: John Wiley & Sons.

16. Kerzner, H. 2000. Applied Project Management. New York: John Wiley & Sons.

17. Kemerer, C. F. 1997. Software Project Management. Boston: McGraw-Hill.

18. Stevenson, W. J. 1993. Production and Operations Management. Boston: Irwin.

19. Sobek, D., J. Liker, and A. Ward. 1998. “Another Look at How Toyota Integrates Product Development.” Harvard Business Review 76(4): 36–49.

20. Hammer, M. and J. Champy. 1993. Reengineering the Corporation. New York: Harper Business.

21. Project Management Institute. 2000. A Guide to the Project Management Body of Knowledge. Newton Square, Pa.: Project Management Institute.

22. Thamhain, H. J. 1999. “Emerging Project Management Techniques: A Managerial Assessment.” Portland International Conference on Management of Engineering and Technology. Portland, Oregon.

23. Coombs, R., A. McMeekin, and R. Pybus. 1998. “Toward Development of Benchmarking Tools for R&D Project Management.” R&D Management 28(3): 175–186.

24. University of Michigan Business School and American Society for Quality. 1998. American Customer Satisfaction Index: 1994–1998. Ann Arbor: University of Michigan Press.

25. Pinto, J. K. and J. E. Prescott. 1990. “Planning and Tactical Factors in the Project Implementation Process.” Journal of Management Studies 27(3): 305–327.

26. Might, R. 1989. “How Northern Telecom Competes on Time.” Harvard Business Review 67(4): 108–114.

27. Eisenhardt, K. M. and S. L. Brown. 1998. “Time Pacing: Competing in Marketing That Won't Stand Still.” Harvard Business Review 76(2): 59–69.