Project Management in a Lean World-Translating Lean Six Sigma (LSS) into the Project Environment *

Projects are at the center of change in organizations. They are the vehicles for new product development, major process improvements, organization changes, and the like. Organization strategies therefore depend on projects for their execution making it vital that projects be carried out in the most effective way possible.

As the chapters of this section reveal, Theory of Constraints Critical Chain unlocks a series of new paradigms that enable major advances over traditional methods. New approaches consider availability of critical resources in the timing of new project releases and the planning of individual project schedules. New concepts in task estimating and tracking open the door to intelligently placed protective time buffers enabling managers to focus correctly on specific areas that need attention for project success. Elimination of unnecessary multi-tasking combines with a "relay-runner" approach to work flow to dramatically reduce project execution times and improve project quality. These simple but effective concepts focus management and resource efforts on the vital few tasks that determine organization success.

Key steps to implementation and sustainability are addressed. These techniques and the dramatic improvements in the field are explained. These include huge improvements in completing projects on time, to specification, and within budget. This section gives a clear picture of the Critical Chain concept and how to implement and execute it. Integration of Critical Chain with Lean and Six Sigma is included. While management of individual projects is addressed, special emphasis is put on multi-project environments as these are more pervasive.

CHAPTER 2.

The Problems with Project Management

Ed Walker

Introduction.

Most projects fail! Failure generally means the actual results of at least one of the three objectives of the project did not meet original expectations. The project scope was reduced (changed the original specifications), the project was delivered late (compared to the original due date), or the budget was exceeded (actual project costs exceeded projected costs). In some projects, two or even all three of these objectives were not realized.

Over the last four decades, two streams of research have emerged from project management. In the management science stream, numerous academic researchers have studied project networks (the theory) to identify specific problems with PERT/CPM (use of the Beta distribution, limited resources, parallel paths, etc.) or to determine the most efficient algorithm to identify the shortest time to complete a project. In the management arena, numerous academic researchers and practitioners have studied the project management environment to identify human problems (lack of project and technical skills, lack of teamwork, lack of communications, etc.) as causes of project failure. Seldom have these researchers acknowledged the work in the other research stream as possible causes for project failure. In many cases, the management scientists only discussed the problem under study as the cause of project failures. What is required, then, is an examination of the project environment as a system and determination of the causes of project failure.

Purpose and Organization of the Chapter

The overarching purpose of this chapter is to expose the problems associated with "traditional" project management. Specific solutions are not to be found here, but rather what is provided is a framework for developing a new project management method that uses a systems perspective to address the core problems of traditional project planning, scheduling, and controlling tools. A systems perspective is needed to fully assess the impact of an assumption related to an activity, to resource contention, or to converging paths on the results of a project.

Copyright 2010 by Ed Walker To accomplish this task, first the reader will be provided with brief overviews of both Gantt chart scheduling and PERT/CPM. Gantt charts were first developed nearly 100 years ago, while PERT (initially named Program Evaluation Research Task and later changed to Program Evaluation and Review Technique) and CPM (Critical Path Method) began their evolution approximately 50 years ago. Each of these methods has both advantages and disadvantages, which are summarized. Brief reviews of the literature related to the origins of project management and the high failures of projects since its origin, as well as literature related to both single and multiple project networks and resource allocation are then presented. The main body of the chapter is devoted to the development of guidelines that any new project management method must address. This is followed by a brief introduction to Critical Chain Project Management (CCPM) and finally a review of the recent CCPM literature.

Traditional Planning and Control Mechanisms in Project Management

Gantt Charts

A Gantt chart is a horizontal bar chart developed as a production control tool in 1917 by Henry L. Gantt, an American engineer and social scientist. Frequently used in project management, a Gantt chart provides a graphical illustration of a schedule that helps to plan, coordinate, and track specific activities in a project. These charts might be as simple as a hand-drawn image on graph paper, or as complex as purpose-built computer software. A simple Gantt chart used for a project is shown in Fig. 2-1.

The horizontal axis of the chart represents the total time span of the project (broken down into uniform time increments-days, weeks, months, etc.), while the tasks comprising the project are on the vertical axis. Horizontal bars are used to illustrate the start and end dates of individual activities (for example, task A has a duration of y days starting on day 1 and ending on day 5). In its simplest form, the Gantt chart shows all of the activities necessary to complete the project. Some of the activities must be completed in a specified sequence, while others might progress concurrently. Tasks B and C are processed sequentially and tasks B and D can be processed concurrently. One cannot start framing a home before the foundation is laid; but once framing is complete, the plumbing and electrical systems can be installed simultaneously.

More complex Gantt chart scheduling is often based on a work breakdown structure (WBS). To continue the previous example, the installation of the electrical system (the objective) might be broken down into manageable elements such as the installation of the breaker panel, pulling electrical wires through the home, pulling data cables, connecting the electrical wires to the breaker panel, inspection of the system by the building inspector, etc. It is then necessary to determine the start and end dates as well as responsibility for each. In such a chart, percent completion is tracked for each element and the objectives. A vertical line on the chart shows the current date (March 25) while the completed and noncompleted portions of each horizontal bar are shaded differently to allow visual inspection of the project's progress. For example, task B is late by two days and task D is early by one day.

FIGURE 2-1 Simplified Gantt chart of a project network.

The primary advantages of Gantt chart scheduling are that it can be easily understood by a wide audience and it provides a visual means to track project progress. The disadvantages are numerous. The chart becomes unwieldy for larger projects (more than about 30 activities) when it extends for more than a single page (or screen, if computerized). The chart does not indicate task dependencies, and therefore fails to communicate how falling behind on one activity might affect other activities. When using a WBS, often there is confusion between defining the WBS and defining the activities of the project. Additionally, as some elements of the WBS might be front- or end-loaded (more work at the beginning or end of the element), the percent progress reported might be over- or understated.

PERT/CPM in the Single Project Environment

CPM and PERT originated in 1957 and 1958, respectively, with CPM examining the tradeoffs between project duration reduction and increases in activity and project costs; and with PERT examining the uncertainty aspects of completion dates for development projects. CPM was originally developed for use with manufacturing plant rebuilds by DuPont and PERT for use with the Polaris nuclear submarine program by the Special Project Office of the Department of the Navy and the consulting firm Booz Allen Hamilton. From their origins to the present, both techniques (and their subsequent merger into one) have been heralded as breakthroughs in managing complex systems.

Once all of the activities are identified (a process that in itself is subject to controversy), a project network can be created. The network organizes the activities in such a way as to clearly show the technological precedence relationships-the simple fact that most activities must be preceded or followed by some other activity or activities. Figure 2-2 shows a typical activity-on-arrow project network. This network has six activities, each having an associated estimate of activity duration. PERT/CPM requires that a forward pass through the network be made to determine the early start (ES) and early finish (EF) times for each activity. Then a backward pass is made through the network using the EF time of the last activity as the late finish (LF) time of the last activity. This backward pass determines the late finish and late start (LS) of each activity. The difference between the LF and EF (or LS and ES) is the slack associated with each activity.

FIGURE 2-2 Typical activity-on-node project network.

Activities having zero slack are called critical activities because any delay in these activities will cause the project to be late. In Fig. 2-1, the critical activities are A, D, E, and F. These activities form what is referred to as the critical path. The primary advantages of PERT/CPM over Gantt charts are that technological precedence (activity dependency) is readily apparent and that it is relatively easy to determine how falling behind on one activity might affect other activities. Activities B and C (Fig. 2-2) have a calculated slack value of four. Therefore, if either of these activities is delayed by more than four days, then the critical path will be negatively impacted because both activities C and E must be completed before activity F can be started. The primary disadvantage of this method is the assumption of readily available capacity on the required resources. Much of the research that follows expands upon this basic premise.

Brief Review of Project Management Literature

The project management literature is enormous-several thousand articles and dozens of books. While project management has grown significantly, many of the problems initially identified almost five decades ago in both the macro-view (applications) literature and in the micro-view (or theoretical) literature still exist today. This literature review provides only a brief glimpse of the continuing themes of project management research since the late 1950s to today. The purpose is to show that the problems of project management have not been solved nor has the promise of project management been achieved over this time interval.

Origins of PERT and CPM

The project management literature is intertwined with descriptions of the benefits and problems of PERT and CPM. A brief account is provided illustrating this continuing dialog. PERT and CPM successes immediately caused top management interest. Several researchers provided articles describing the use of these new management tools. Malcolm, Rose-boom, and Clark (1959) provide a status report with a history of the development; examples of the flow plan; the elapsed-time estimates; the organization of the data; the computation of expected times, latest times, slack, and critical path; and probability of project completion by a given date. A description of the pilot application and its full-scale implementation and results to date are provided as well. Almost as soon as this detailed account of PERT appeared, Healy (1961) warned of a problem with the technique, that subdividing activities and their related times can change the project completion date probabilities. Clark (1961) and Millstein (1967) critique Healy's research based on the realities of managing with PERT, while Roseboom (1961) critiques Healy's research based on the whether his assumptions are realistic.

Miller (1962) provides a description of how to plan and control with PERT; and Levy, Thompson, and Wiest (1962) provide a similar description of the ABCs of CPM, both in the Harvard Business Review. At the same time, Pocock (1962) describes PERT, its payoff, and problems (PERT is a management responsibility; PERT is no automatic system; PERT often clashes with traditional organization patterns; learning to use a dynamic control system; poor applications; PERT cannot be a rigidly standardized technique). Kelley (1962) provides research supporting the mathematical basis of CPM, and Bildson and Gillespie (1962) provide an extension with a model of PERT (with activity time uncertainty) and CPM (with cost of activity crashing). Paige (1963) provides a detailed description of PERT/Cost. Several research articles followed which examined and attacked the PERT assumptions as being unrealistic or false. The purpose of providing a brief description of the early articles and the articles in the appendices related to various micro (theory) problems being argued even today is to illustrate the types of causes that academic researchers identify for the failures of projects.

Project Failures

In addition to the theory-based research, both anecdotal articles and surveys of different types of project organizations have been taken to determine the level of project failures and causes of failures. In 1957, C. Northcote Parkinson observed that "work expands so as to fill the time available for its completion"-now known as Parkinson's Law. Others (Marks and Taylor, 1966; Krakowski, 1974; Gutierrez and Kouvelis, 1991) have ascribed the presence of this law to project activities and the results on project duration.

Middleton (1967) surveyed project management organizations in aerospace industries. Respondents provided the following disadvantages of using a project management organization: more complex internal operations (51 percent), inconsistency in application of company policy (32 percent), lower utilization of personnel (13 percent), higher program costs (13 percent), more difficult to manage (13 percent), and lower profit margins (2 percent). Other disadvantages provided were the tendency of functional groups to neglect their jobs, too much shifting of personnel from project to project due to priorities, and duplication of functional skills in the project organization.

Avot states, "The many instances where project management fails overshadow the stories of successful projects" (1970, 36). He identified the major causes of project failure as the following: the basis for the project is not sound; the wrong man is chosen as project manager; company management is unsupportive; tasks are inadequately defined; the project management system is not adequately controlled; management techniques (e.g., too many reports) are misused; and project termination is not planned.

Brooks (1995), the project manager for the IBM OS/360, provides five major causes for lateness in information technology projects: (1) techniques of estimating are poorly developed (estimates are usually optimistic); (2) estimating techniques confuse effort with progress (the assumption is that men and months are interchangeable); (3) submission to the customer's desired (but unrealistic) due date; (4) schedule progress is poorly monitored; and (5) when schedule slippage occurs, the response is to add manpower.

Based on his project management experience, Hughes (1986) blames the majority of project failures on not following basic management principles such as an improper focus on the project management system instead of the project goals; fixation on maintaining first-time estimates; too detailed or too broad activity structure; lack of training in project management techniques; too many people assigned to the project (Parkinson's Law); lack of communication of goals; and rewarding the wrong actions. Black (1996) surveyed professional engineers to determine the causes of project failures. His top 12 causes of project failures are: 1. Lack of planning 2. The project manager 3. Project changes (scope creep, poor planning, etc.) 4. Poor scheduling 5. Skills of team members 6. Management support 7. Funding 8. Cost containment 9. Resources 10. Information management 11. Incentives (lack of rewards and penalties) 12. Lack of continuing risk analysis In the late 1980s and early 1990s, a series of articles by Pinto and Slevin (1987), Pinto and Prescott (1988), Pinto and Slevin (1989), and Pinto and Mantel (1990) examined the presence of critical success factors in project implementations; differences across the stages of the project life cycle; differences between construction and R&D projects; and project failures, respectively. The critical success factors are project mission definition, top management support, client consultation, personnel, technical tasks, client acceptance, monitoring and feedback, communication, and troubleshooting. Of the projects (Pinto and Mantel, 1990) accessed as failures in the strategic stages, the relevant criterion for failure was that related to external effectiveness: perceived value of the project and client satisfaction. In the tactical stages, the relevant criteria for failure were those related to trouble shooting, lack of adequate personnel, ineffective scheduling, lack of client acceptance, and inadequate technical support. One hypothesis (H3), "the perceived causes of project failure will vary depending upon the type of project assessed: construction or R&D" (1990, 271), proved to be true. In construction projects, the causes of failure were lack of technical expertise, support, and lack of adequate trouble shooting mechanisms. In R&D projects, a wide variety of causes of failure was identified with the cause depending on the definition of failure; inadequate troubleshooting impacts all definitions; implementation process: inefficient scheduling; client satisfaction: personnel and monitoring and feedback; and quality: lack of clear statement of project goals.

Brown (2001) reports that three-quarters of all projects are completed late and over budget according to a survey of 1800 executives, practitioners, and consultants. Pitagorsky (2001) puts the failure rate at 40 to 60 percent. According to James, 40 percent of all large IT projects end in "utter failure" while another 33 percent are "challenged, meaning that they were completed late, over budget or with fewer features and functions than originally specified" (2000, p. 40). Based on their 20 years of project management experience, Matta and Ashkenas (2003) provide two major causes of complex project failure-critical tasks (called white-space risk) are left off the project plan and the different activities won't come together in the end to produce the final project.

Neimat (2005) provides a detailed analysis of IT project failure research from the Standish Group by annual IT surveys of 18,000 executives showing the trends in failure rates from 1994 (over 80 percent of projects were challenged or failed) through 2000 (about 70 percent of projects were stressed or failed); a summary of several more recent research efforts examining IT project failures and a description of the Federal Bureau of Investigation (FBI) Virtual Case File project failure. His listing of causes of project failure is similar to the listings across the 40-year period: poor planning, unclear goals and objectives, objectives changing during the project (scope creep), unrealistic time or resource estimates, lack of executive support and user involvement, failure to communicate and act as a team, and inappropriate skills. Interestingly, the descriptions of the failure and success variables listed in the various articles across this 40-year time period are quite similar.

Single Project Management Literature

PERT/CPM is criticized for failing to provide achievable completion dates, for consistently underestimating budgets, and for using resources inefficiently (e.g., Klingel, 1966; Badiru, 1993; Meredith and Mantel, 2003, 134135, 649652). These failures might be traceable to a faulty initial plan or to an inadequate control process. A variety of methods for both planning and controlling projects has been espoused by researchers (Wiest and Levy, 1977; Badiru, 1993; Kerzner, 1994; Meredith and Mantel, 2003), yet no consensus on either modifications to or a replacement for the traditional PERT/CPM planning and control technique have resulted.

As most research has been conducted in the single project environment, most critiques of PERT/CPM have also been focused on the single project environment. Kerzner (1994) states that PERT: (1) is end-item oriented-it separates the planners from the doers; (2) assumes infinite capacity; and (3) fails to recognize the lack of history on which to base estimates. Other researchers have found similar problems and have criticized certain PERT/CPM characteristics. Wiest and Levy (1977) question (1) whether activities themselves and their durations (and associated distributions) and precedent relationships can be known in advance; (2) the lack of cyclical and conditional activities; and (3) the assumption of an inverse linear relationship between cost and duration (activity crashing). Van Slyke (1963) and later Schonberger (1981) found that activity variability causes project duration to exceed PERT estimates, that is, as activity duration variability increases so does the difference between planned and actual project duration. Both found that PERT assumes path independence and questioned whether variance on one path might cause another path to be "late." Van Slyke further identified the cause as interdependence of activities on the "independent" paths. Whether explicitly stated or simply suggested by the focus of their research, many researchers ultimately question the PERT/CPM assumption of infinite capacity and PERT/CPM's disregard of activity duration variability.

Multiple Project Management Literature

Not unlike other business environments, the management of multiple projects has certain problems that must be recognized prior to the development of new tools for planning and control. Recent research in the area of multiple project planning and control has recognized several shortcomings of the PERT/CPM method. Researchers have explored resource assignment rules to better plan multiple projects (e.g., Lee et al., 1978; Trypia, 1980; Kurtulus and Davis, 1982; Kurtulus, 1985; Kurtulus and Narula, 1985; Allam, 1988; Mohanty and Siddiq, 1989; Bock and Patterson, 1990; Deckro et al., 1991; Dean et al., 1992; Abdel-Hamid, 1993; Kim and Leachman, 1993; Lawrence and Morton, 1993; Speranza and Vercellis, 1993; Yang and Sum, 1993; Vercellis, 1994; Tsai and Chiu, 1996) and have investigated the issue of multiple project control on both an organizational basis (e.g., Coulter, 1990; Platje and Seidel, 1993; Payne, 1995) and a tactical basis (e.g., Tsubakitani and Deckro, 1990; Dumond and Dumond, 1993). With the exception of Dumond and Dumond (1993) and Tsubakitani and Deckro (1990), this research has examined a static multiple project environment.

The investigations into the planning, scheduling, and control functions of multiple projects have found several fundamental characteristics inherent in multiple projects: 1. Multiple projects are interdependent due to the use of common resources.

2. Some method must be used to prioritize the use of resources among multiple projects.

3. There is some trade-off between the utilization of resources and the on-time completion of individual projects.

4. Whether organizational or tactical, a control mechanism must exist to reduce the variance between planned and actual project completion dates.

Development of Guidelines

The widespread use of project management techniques and the general failure of projects to meet time, budget, or specification targets beg the examination of the fundamentals of project planning, scheduling, and control from a systems perspective. In the ensuing section, 12 guidelines for project planning, scheduling, and control based on this systems perspective are developed. These guidelines are posed as a starting point in the development of a comprehensive solution to project planning, scheduling, and control. Without this systems perspective of focusing on core problems of project failures, a proposed solution (such as better communications) may create more problems (such as having more project meetings and producing more reports) than it solves. The 12 guidelines are listed in the shaded box and are further explained in the text that follows.