Guideline I: Recognize the differences between due-date projects and money-making projects. The network structure may be the same, but a project to make money is started as soon as possible (to make money) and a project that is due by a given date is started as late as possible (to save money) while still providing protection for its completion. The project must be viewed as part of the larger system-what are the goal and objectives of the project with respect to the organization's goal and objectives?

Guideline II: Recognize all of the activities required to achieve the goal of a project and the organization. In application, the goal of the project is generally a milestone in a much larger system. Ensure that the project scope fully defines the activities necessary to achieve the project goal and is in line with the system (organization) goal.

Guideline III: Recognize that 100-percent resource utilization may be counter to the objectives of the project and the organization goal. Plan resource use within and across projects such that the project is completed on time, on budget, and to full specifications.

Guideline IV: The rules for constructing project activity times must be known and practiced by all resources, resource managers, and project managers. A.5 probability of completion for the activities and project is required to determine a correct network. Padding (or buffering) should be applied strategically at the project level.

Guideline V: Minimize the amount of multitasking by critical resources and the amount of multitasking on activities on the critical path of the project to reduce activity lateness. Use multitasking cautiously-understanding its impact on project completion. Strategically buffer non-critical paths, resource contention, and project completions to reduce the impact of Murphy's Law (Murphy).

Guideline VI: Develop and implement a methodology for prioritizing resource allocation within a project and across projects so that resources know what is most important from the organizational (system) perspective.

Guideline VII: The project manager must consider all activities and dependencies to be completed to achieve the project goals, as well as all conditions that must be met before an activity can begin when developing the project network.

Guideline VIII: Recognize the existence of finite capacity and activity duration variability by changing the planning, scheduling, and control of single and multiple projects to include a buffer time at the end of each individual project, as well as at points of convergence (technological convergence and convergence caused by resource contention) both within and across projects.

Guideline IX: Recognize that the current practice of minimizing costs by delaying activity expenditures might be counter to the objective of on-time delivery of the projects.

Guideline X: Recognize that measuring resource managers by resource utilization creates inflated activity time estimates, timing issues in the use of resources, multitasking within and across projects, and ultimately project lateness.

Guideline XI: Theory (research) must be revised to reflect and support practice. Activities on the Critical Chain or a near-Critical Chain should be scheduled to completion of the preceding activity instead of time. For example, traditional project management software usually provides schedules for resources and resources are available based on the schedule. Project research simulations initiate succeeding activities based on completion of proceeding activities. At a minimum, research should define its parameters from a systems perspective to match reality.

Guideline XII: Establish a clear and effective method for the planning and control of multiple projects looking at resource contention across projects. Recognize that not all projects can start as soon as possible. Projects should be pipelined based on the capacity of critical resources and staggered based on the capacity of those resources.

Macro Issues

Goals, Objectives, and Measures of a Project

Granger describes the hierarchy of objectives as follows: "There are objectives with objectives, within objectives. They all require painstaking definition and close analysis if they are to be useful separately and profitable as a whole" (1964, 63). Remember, the goal of a project is to complete a project successfully, which usually translates into the lower level objectives of minimizing the costs associated with the project, completing the project on time, and completing the project as described in the specifications.

But what is the real goal of the project? Project goals can be classified as two types: (1) projects that have to be completed by a given date, and (2) projects that when completed generate revenues and therefore should be completed as soon as possible. The first type of project should be started as late as possible and still guarantee delivery of the project by the desired date (this strategy saves money). The second type of project should be started as soon as possible and guarantee delivery of the project by the desired date (this strategy makes money). The second type of project is much more commonplace, yet it is often treated as if it were the first type.

Cause: PERT/CPM does not overtly recognize the difference between a project that must be completed by a promised due date (due-date project) and a project that must be completed in order to make money as quickly as possible (money-making project).

This is addressed by Guideline I.

Defining the Scope of a Project

In his research, Feldman (2001) identified the seven deadly sins of project estimating. Included are that not all tasks or costs are defined and that estimates do not represent scope completeness. What is the goal of the project with respect to the goal of the organization (system)? What then is the scope of a project to support these organization and project goals? If we are defining a project that entails the opening of a new car dealership (see Rydell Group, 1995 for details of this example), what are the activities that should be included in the project? What is the goal of the project? In this instance, it is to make money from the sale of cars. In the past, a dealership would decide to open a new franchise in a large town. This might have been executed as if it were composed of several projects: buying the land; soliciting bids; breaking ground, constructing the facility, furnishing the building, and contracting utilities; ordering inventories; hiring, staffing, and training employees; etc. It normally takes nine months from the beginning of the project until the doors of the facility are open-nine months of money flowing out of the firm. By using the systems perspective and recognizing that the goal is to make money on the project (i.e., the completion of the project is to have a money-making machine in place producing), they might restructure the network as a single project by running several activities in parallel-building, ordering furnishings, setting up utilities, etc.-and complete the project in three months. The project end is defined as opening the door for business instead of completing construction. This recognition of the type of project and its real scope allows the business to generate profits after three months instead of after nine months.

Cause: As traditionally applied, PERT/CPM does not recognize all of the activities required to achieve the goal of a project and the organization.

This is addressed by Guideline II.

The Project Management Dilemma

Williams (2001) states that scheduling presents a dual challenge in project management. On one hand, there is the need to match capacity to the demand placed on it-the resources must be available for use. On the other hand, idle capacity will cost the firm money-the resources must be fully utilized. The overall goal of most organizations is to be successful (to make more money in most cases), and all managers in the organization share this goal. A project manager is usually assigned to plan and execute a project successfully (on time, on budget, and to specifications). To ensure that the resources are available at the proper times, the project managers develop detailed schedules for each resource manager.

These resources, however, are not controlled by the project manager but are managed by resource managers. For the organization to be successful, the resource managers are charged with minimizing the operating expenses associated with using the resources. This directive to the resource managers usually translates into keeping the resources busy at all times. The resource managers are given a budget and measured against the budget and the efficient use of their resources. The dilemma is then between "The resource managers must have the resources available for the projects" and "The resource managers must keep their resources busy." There is a constant tug of war between project managers trying to complete projects within time, budget, and specifications and resource managers trying to make efficient use of resources.

In a multi-project environment, the resource managers being pulled across activities on different projects exacerbates this dilemma; each project manager believing that his or her project is the most important, most late, most critical, etc. In practice, the environment worsens. A product line manager might have a number of projects underway as does another product line manager. In a given time period, we can have a few projects in each product line competing with other projects in the product line or projects from different product lines competing for common resources. The resource manager is pulled from one activity to another, possibly without completing the first activity. The resource manager usually responds to the squeaky wheel, the project manager who yells the loudest, instead of having a formal mechanism for prioritizing activities within and across projects. In most situations, the resources also multitask (start one activity, stop, start another, stop, start another, stop, go back to the first, stop, go to the third, etc.) across activities, which generally extends the activity and completion times of each activity significantly and possibly delays the completion of one or more projects. This multitasking undoubtedly affects project quality as well.

Cause: The resource and project managers are unable to effectively plan resource use across activities in the same project or across activities in different projects.

Cause: Project managers are measured by their ability to meet their three objectives-complete projects on time, on budget, and to full specifications-whereas resource managers have the objective of utilizing their resources efficiently and are measured by their ability to keep resources fully utilized. These are conflicting objectives and have conflicting measures.

These are addressed by Guideline III.

Determining an Activity Time Estimate

In theory, we assume that the activity time is the mean time of the beta distribution (Miller, 1962). In reality, what time does the resource manager normally give? Is it the mean time? Seldom. Usually if a resource or resource manager is asked to provide a time estimate for a task, he or she pads the time a little (or a lot). If he or she ever misses that activity time and is chewed out by the project manager, then that time becomes more inflated to ensure successful activity completion. Think about it. If you provided a 50 percent task completion time estimate to your boss and were above the mean time 50 percent of the time, then your boss would probably think you were a poor worker. What probability of completion time do you give your boss? A completion time related to 50 percent or a time related to 95 percent? What if you finished the work early? Would you tell the project manager? You would probably not as his or her expectation would be that you should be able to complete future tasks in that amount of time. Yet, you gave the project manager a 95 percent probability of completion time to cover yourself. You would assume that if the project manager knew you finished early he would assume you provided inflated activity times and then would begin to question the time and costs you provided for other activities. Remember, we typically think the cost of a resource is based on the amount of time used by the resource to complete the job. If you consistently finished earlier than your time estimate, then the project manager would think you overpriced your resource. There is a strong tendency to both expand the time estimates of activities and, if the activity is finished early, not report the early finish.

Additionally, the project manager has a tendency to pad the project duration to ensure completion. Do you think the project manager is going to provide the boss a project completion time estimate that he or she is only 50 percent sure of completing? He or she probably gives a 95 percent probability of completion as well. You only have to be late one time on a major project to learn to pad your project times. What does the overall manager then do with your project time estimate? Cut the project time and cost and expect the same specifications. Why? The project manager started as a resource, then worked as a resource manager, then worked as a project manager, and is now a general manager and has practiced and knows the rules of the game.

Frequently, resources must be used to work on more than one activity at a time. Why? Two conditions come to mind. The first condition is the practice of multitasking discussed previously. The second condition exists where the resource runs into an unanticipated delay (interestingly the delay could be caused by a missing activity or a missing technological arrow on the network; hence, the need to use a beta distribution with pessimistic times) or must set aside the activity until later. This condition is discussed in the next section on identifying obstacles to completing an activity.

Cause: The rules and measures for determining activity time are ambiguous. For example, according to the assumptions of PERT theory, the resource (or resource manager) must provide a.5 probability time for activity times to build an accurate project network, yet the project manager expects a 1.00 probability of completion of the activity and project. If the resource finishes early or the project finishes early, then the expectation is for all of that resource's activities or project manager's projects to finish early.

This is addressed by Guideline IV.

Cause: The resource and project managers are unable to plan resource use across activities in the same project or across activities in different projects.

Cause: Murphy has struck and some activities have been delayed into the time allocated for other activities connected to the activity by technological precedence or by the use of a common resource (resource precedence).

These are addressed by Guidelines V and VI.

Development of a Project Network

In theory, the development of a project network is straightforward. First, we ask, "What are the activities of the project?" Then we ask, "What goes first? What goes next? What can be done in parallel?" These steps are over simplifications to say the least.

In reality, activities cannot start for a multitude of reasons not related to those activities preceding the delayed activity (e.g., the tools were not available, the materials didn't come in from the vendor, the workforce wasn't scheduled, the application was not made for a needed permit, etc.). In practice, each activity (node) in the network must be examined to determine what has to be present to perform the activity. The mere completion of the previous activities does not always constitute the starting condition for the activity. For example, in a recent upgrading of a computer network for a building, the work crew was scheduled, the users were notified that the building would be closed on the weekend, the computer was scheduled to be down, police were notified of workers crawling through ceiling spaces, etc., but the necessary cable did not arrive. Therefore, we find that while several activities were planned, one missing activity could delay the completion of the project and this activity was not anticipated. There are many penetration points in a project that if something is not present, the activity (or activities) and possibly the project will be delayed. We have no means or warning of such situations in the traditional project management literature-we do use a beta distribution and place 1/6 probability of this pessimistic activity duration occurring. We need to re-examine the steps used in constructing a project network to reduce the likelihood of pessimistic activity times occurring. We need to fail-safe the activities.

For example, in Critical Chain project network development (using Theory of Constraints [TOC]), network developers use a prerequisite tree to identify obstacles to achieving each intermediate objective (activity). They ask, "What is preventing us from starting this activity?" Numerous obstacles are identified; in most cases, these are items not included on the original network. Then an activity to overcome this obstacle is identified and included in the network. In this manner, the network developers identify and include many "assumed activities" in the project and many connecting arrows (dependencies) that were omitted in the original network. Most networks created in this manner have at least 25 percent more activities (nodes) and are 50 percent denser (more arrows). A quick review of the causes of project failure from the literature review of 40 years of failures shows: techniques of estimating are poorly developed (project completion estimates are usually optimistic); too detailed or too broad activity structure; lack of planning; ineffective scheduling; critical tasks are left off the project plan; and, again, poor planning. All of these "causes of project failure" can be caused by activities (nodes) and missing dependencies (arrows).

A project network should include all of the activities and dependencies required to achieve the goal of the project-legal requirements, purchasing, designing, production, accounting, finance, marketing, sales, personnel, etc. Most networks are used for the design and development stages and do not take a systems perspective to a project. The consequences are that the project may be completed in time (that time shown on the network), but the result of the project (making money or using the end product) is not achieved.

Cause: The project network is not developed to include all obstacles that must be overcome before an activity might begin.

This is addressed by Guideline VII.

Micro Issues

The micro issues relate to errors or shortcomings in using the project tools. We will use simple numerical examples of each problem. By careful study of these errors and their causes, a systems approach to project planning, scheduling, and control can be developed and tested to ensure it addresses each of these problems.

Gedanken exercises, or thought experiments, have traditionally been used in the sciences rather than in business. The method uses logic and simple mathematics to construct an illustrative example to validate a hypothesis. While the method has usually been applied to scientific research areas such as quantum mechanics or astral physics where time, space, or both separate the subjects of scrutiny from the researchers, gedanken exercises also have the advantage of holding all other variables constant in order that the effects of the variable being examined are isolated. This simplification allows the researcher to gain knowledge and understanding by examining fragments of the system one piece at a time rather than losing the effects of an individual variable in the noise of many interacting variables. With a full understanding of the behavior of each variable acting in isolation, the researcher might be able to construct a logically sound theory about the system.

The use of gedankens in this research is based upon the realization that there are many factors that contribute to the project completion delays found in project planning, scheduling, and control. Here, the use of gedankens allows for the examination of each factor in isolation so that the factor can be studied to determine its effects on project completion.

Single Project Gedankens

Problem 1: Variability and Convergence Points The first of the eight weaknesses attributable to the assumptions of PERT/CPM is that of variability of activity duration and points of convergence. Many, if not all, PERT/CPM networks have points where two (or more) activities must be completed before a third activity may begin. Assume activity times follow a beta distribution. In Fig. 2-3 Problem 1, activities A and B must be completed before activity C can begin. Since the expected duration of both A and B is 4 periods [E(A or B) = (2 + 4 4 + 6)/6 = 4], typical PERT/CPM planning would calculate that C will begin in period 4. However, if all possible combinations of the durations of both A and B are enumerated, the expected completion date of both A and B is 4.56 periods. The ultimate cause of the delay of activity C is the intersection of activities A and B (convergent point) when activity duration variability exists. With statistical fluctuations, convergent point calculations of start and finish times are incorrect.

Cause: Network conventions require that all paths converge to one end node.

Cause: Projects consist of dependent sequential activities, parallel paths, and convergent points.

Cause: Murphy exists.

Cause: PERT/CPM does not protect against Murphy.

These are addressed by Guideline VIII.

FIGURE 2-3 Eight problems with PERT/CPM management of single projects identified by Pittman (1994).

Problem 2: High Variability on a Non-Critical Path Figure 2-3 Problem 2 shows a simple PERT/CPM project with two paths. In typical PERT/CPM project management, the expected duration of each activity (assuming a beta distribution) is a simple point estimate based on the optimistic, most likely, and pessimistic estimates of activity duration. The expected duration of an activity is given by E(A) of an activity.

E(A) = (5 + 4 6 + 7)/ 6 = 6.

E(B) = (3 + 4 4 + 5)/ 6 = 4.

E(C) = (4 + 4 5 + 6)/ 6 = 5.

E(D) = (1 + 4 4 + 7)/ 6 = 4.

The upper path (C-D) would be expected to take 9 periods, and the lower path (A-B) would be expected to take 10 periods. The PERT/CPM critical path is therefore A-B taking 10 periods. However, when all possible durations of each activity are enumerated, the expected duration of the project is not 10 periods but rather it is 10.725 periods. Van Slyke (1963) and later Schonberger (1981) suggested that near-critical paths be managed to ensure that variability on these paths does not affect the critical path. It is interesting to note that had the two paths not converged, the variability of the non-critical path would not have affected the critical path; therefore, this is a special type of convergence problem. (The assumptions of PERT include that a project has only one exit node; therefore, any project with more than one path must have a point of convergence.) The ultimate cause of the delay of project completion is the intersection of a non-critical path (C-D) with the critical path (A-B) when high activity duration variability exists on the non-critical path.

Cause: Murphy exists.

Cause: PERT/CPM does not protect against Murphy.

These are addressed by Guideline VIII.

Problem 3: Scheduling to Time Rather Than the Completion of the Prior Activity The managerial practice of scheduling to time rather than the completion of the prior activity is also affected by activity duration variability. Figure 2-3 Problem 3 shows a simple three-activity PERT/CPM network. In practice, the typical PERT/CPM project manager generates and distributes to the resource managers a written or computer-generated schedule of planned activity start times for that resource manager's resource based upon the expected duration of the preceding activities. Given that the expected durations of activities A, B, and C are 4, 4, and 4, respectively, a typical PERT/CPM schedule would be as follows: If, however, all possible combinations of activity duration are enumerated and the activities are started on the scheduled start date (or later if the preceding activity has not been completed), the project will have an actual expected duration of 13.11 periods. Project managers fail to take advantage of favorable completion times when the project is managed according to the above schedule. It should be noted here that optimistic completion times are leveraged only by the last activity in the network since there are no other activities planned to follow it. This means that the managerial practice of scheduling to time rather than completion of the previous activity is magnified in larger projects. The core driver, activity duration variability, is a fact. The practice of traditional project management to schedule to time instead of completion of preceding activity eliminates the opportunity to take advantage of optimistic completions of activities and thus produces poor project results.

Cause: PERT/CPM does not recognize that some resources might be required for more than one activity.

Cause: PERT/CPM provides resource schedules based only on technological relationships and time estimates.

These are addressed by Guideline XI.

Problem 4: Increasing Planned Activity Times Resource managers (as opposed to project managers) have long felt pressure to complete their activity within the expected activity duration estimate. Resource managers then often increase the estimate of activity duration that they submit to the project manager to ensure that the activity is completed on time and to show high utilization of their resources. Low utilization of resources translates into excess resources that will be trimmed. Figure 2-3 Problem 4 shows a simple two-activity PERT/CPM project. The upper project is the network that would be developed if the resource managers were to submit estimates of activity duration based on the actual estimates of activity duration. In the upper network, the PERT/CPM expected project duration would be 12 periods. The lower network is the PERT/CPM project network that the project manager would construct if each resource manager were to increase the expected duration of his activity by 25 percent.