Project Management Institute

Integrating production control into schedule systems

Introduction

The usual project planning and control systems often fail to provide adequate guidance for scheduling day-to-day project activities. In today's complex projects, additional tools are necessary to assure that the work being performed in a given period meets the criteria of being the right work performed in the right way. This paper highlights conditions where the schedule systems may be found wanting as management tools for organizing daily activities. The paper also reviews the systems in use at one company that attempts to address this management need.

An element common to most projects is that the project results sought cannot be achieved until some real work is accomplished. Effective project plans may inspire vast armies of workers toward clear project objectives. Those plans may direct the broad priorities of the project team in engineering, procurement, and construction. Project controls may monitor the state of the progress hour by hour or tell us with absolute certainty where money is being spent and what work is getting done. Yet both systems may fail to provide adequate direction to the performance of day-to-day activities.

Whether the fundamental work of a project is pounding nails or pouring concrete, in the case of construction, or writing code and compiling programs, in the case of an IS project, real work is required. Real people have to perform hands-on work to achieve the purposes that justified the initiation of the project. Absent effective direction of this fundamental work, the project systems may accurately represent a path leading to a failed project.

Research sponsored by the Construction Industry Institute (CII) has shown that, in at least in one sample group, more than 80% of the capital projects failed to achieve their objectives (Jaselskis 1988). CII research has examined reasons for these failures and suggests that project failure is a companion to projects that:

• Lack clarity in the definition of objectives

• Establish unrealistic objectives

• Organize the project team poorly

• Neglect team building

• Suffer a breakdown in communication within the project organization

• Fail to establish effective control systems to provide early warning of risks and problems

• Ignore warning signs provided by their systems

• Disregard the intensity necessary to translate knowledge of problems into corrective action

• Undertake work with inadequate planning and preparation.

Taken together, these causes of failure suggest that projects are being performed in an environment where any of the links in a complex chain can initiate failure, and where only the reliable performance in all areas can ensure success. One is reminded that a chain of 10 dependent events, each 80% certain to happen, yields a combined success rate of 11%.

The areas listed above create a much more complex model of the origins of project success or failure than was envisioned by the inventors of CPM techniques. The better we understand our world, the more complex it becomes in the endless details.

An area of importance, which is only marginally dealt with by these high-level concerns, is in the area of production management. Production management can be defined as the exercise of those functions associated with performance of specific project tasks. A production management system can be thought of as extending from the identification of specific tasks through their performance. The ultimate cost effectiveness, and the timely completion, of the project can be highly dependent upon the management of these functions.

Grafting normal project control systems across production functions can adequately address many project situations. Well-crafted schedule systems can provide a great deal of information for management of production tasks. Still, these systems often fall short in providing the total production management information necessary.

Discovering the Limitations of Schedule Systems

It is useful to examine some project situations where the adequacy of schedule systems for managing production is questionable. Some of these situations may arise from obvious abuse of the scheduling system. Others are the result of structural concerns in the application of scheduling systems that are inherent in the tool. In each type of situation, the attempt has been made to give a simple clarifying example of the problem. Clearly, there is overlap between some of the situations depicted as distinct. The author also recognizes that some examples might have fit as well in other situations. As George Box put it, “All models are flawed; some are useful.”

Production Driven Projects

The first type of situation to be described deals with a project, or part of a project, that is production dominated. In some situations, the project workflow may be so totally driven by production issues that project management largely becomes production management. Examination of such a case helps answer the often-heard question: “How did Hoover Dam get built in 54 months, without a CPM schedule?” (Wolf 1996). The answer in some measure is tied to the superhuman efforts of some very effective construction bosses. In another measure it is tied to the issue that a high-level logic diagram for the project can be drawn in three boxes (see Exhibit 1).

Exhibit 1

Exhibit 1

Exhibit 2

Exhibit 2

There were lots of problems with manpower, logistics, and obtaining materials. There were challenges from external factors, including the national politics. But the basic problems of meeting the schedule were still production problems. Within the production functions, the logic of pour block 1 before block 2 was pretty straightforward. (See Exhibit 2.) Scheduling the daily concrete pours with a CPM schedule would not have added value to the management system.

Repetitive Activities

A second type of situation arises where some portion of a project is performed repetitively. For instance, a classic logic diagram for a simple concrete footing is shown in Exhibit 3. Drawing such a diagram can be an important step in analyzing a problem, or in developing a production system.

Where the usefulness of the schedule for production control may break down is when the task is performed repetitively. Let's say we have 100 nearly identical footings to place. Does this segment of the logic diagram now need 700 activities? Would it usefully define our production plan to represent this segment of the logic with 7-100 day activities with Start-to-Start relationships? (See Exhibit 4.) Neither solution is very useful. A useful logic diagram for work analysis does not scale well to the management of production.

The usefulness of this example may be disputed because of the mundane nature of the task. Everybody knows this sequence! There are no real alternatives! Then the question may become: What planning system would help us challenge those presumptions?

Exhibit 3

Exhibit 3

Exhibit 4

Exhibit 4

As a brief case study, my firm had a situation where roughly 100 footings were needed for a large pipe bridge. The required sequence was driven by the constraints. Chief among those constraints were timing constraints that appeared to force the placement of concrete in the winter. Our solution was to place concrete in the winter by prefabricating the footings in a headed warehouse. With the coming of spring we placed them on ground after performing mass excavation. The project schedule system helped identify the constraints. It did not suggest solutions or manage the production.

Resource Constraints

A third type of project situation is where the progress on the schedule is more constrained by available resources than by the physical constraints of the work.

As an example, take a drums and vessels maintenance turnaround in a refinery. At the point of turnover to the contractors, the schedule logic consists of the completion of a very few activities: Shutdown and flush the process units. The next stage activities multiply to the blinding and LOTO of units and vessels. At this point, dozens of work activities might become conceptually valid for scheduling, but the constraints of workforce size limit the simultaneous activities to a much smaller number. Certain vessels, generally because of the magnitude of the expected work, are clearly critical and get full attention. Dozens of others are subject to independent scheduling (see Exhibit 5).

Putting dozens of activities on a logic diagram, showing each as having equal validity, offers little useful information. Constraining them to the path planned for crew activity can encourage high maintenance for no gain. The logic diagram is again a useful planning and analysis tool. It is not adequate for production control. An alternate tool used in such a project is described in conjunction with the next type of situation.

Physical Logic Different Than Crewing Logic

In a refinery turnaround situation, the organization of the WBS conventionally tends toward organization by unit or vessel. This normal organization of information may not be useful in all areas where management action is called for. For instance, if we consider the work on three vessels (A, B, and C) in a process unit, we face the choice of building our schedule across the work of each vessel, or across similar work on the different vessels. (See Exhibit 6.) Neither organization of the task lists is likely to meet every information need.

Taken by vessel, the first schedule activities might be blinding, cleaning, opening man ways, and inspection of trays. Such activities are related by logical, physical, dependencies. This expression of the logic is the most common I encounter. For instance, the inspection of trays cannot be undertaken until the vessel is open.

Physical-constraint driven logic may not provide the guidance necessary to organize the work for production. For most efficient production, the performance of tasks is more likely to be by crews assigned to tasks of a similar nature on a sequence of vessels. For instance, the work of a crew might be, Blind A, Blind B, and Blind C. Attempting to track a production-based work sequence through the vessel oriented schedule logic can lead to confusion and difficulty. Such difficulty often arises with regard to the evaluation of work in progress.

Reconstruction of the schedule in production terms leads to difficulty when dependencies appear without a physical basis. For example, a schedule calling for blinding A, B, and C meets difficulty when a delay occurs in the release of B. Scheduling programs generally trip on start dates for succeeding activities (C) that occur when no start date is shown for the preceding activity (B).

On several recent projects my firm's planners have found an effective path to deal with this situation. The most common work activities for each vessel were identified as columns on a spreadsheet. Each row represented the sequence of activities applicable to a vessel. Each open column represented a required activity (common activities not required on a particular vessel were shaded). The spreadsheet was printed as a 4-foot wide wall chart divided by unit and area. As each activity was completed, the cell was dated and highlighted. While progress was reported to the overall turnaround management on a daily basis for incorporation into their master schedule, that master schedule broke down as a control tool and our wall chart became the de facto means of assessing progress. The same tool also addressed the problems described previously in the resource constraint situation.

Exhibit 5

Exhibit 5

Administrative Tasks

A fifth type of situation is where the progress of the project depends on the effective accomplishment of administrative tasks. The situation is often addressed through this syllogism: Production aspects of administration are susceptible to analysis using flow charts. Schedule logic diagrams are a specialized flow chart. Therefore, we will map the performance of administration using scheduling software. In the author's experience it is a misapplication of scheduling software to constrain an administrative system to comply with the limits of the software.

A classic example from my files is a hand-drawn schedule depicting a series of procurement activities in a major process project. Procurement operations for each group of equipment were detailed on the schedule in six steps from definition of the concept to issuance of a purchase order. The effort to obtain information from the schedule on these items was great. The usefulness of the information obtained was limited.

In contrast, the much more numerous activities from the issuance of the purchase orders until site delivery of the equipment were monitored in a database. Some 20,000 items of owner furnished equipment and instrumentation were tracked in the database. Expected delivery dates were carried to the schedule, but the administrative detail behind those projections was not tracked in the schedule.

Exhibit 6

Exhibit 6

Difference Between Physically Constrained and Performance Based Schedule Logic

Durations and Interface Points

Several related situations where scheduling systems might be inadequate are dealt with by Eli Goldratt in his book Critical Chain (Goldratt 1998). The two he highlights, of interest here, are:

• The basis and quality of projected activity durations

• The clarity of transitions between activities.

In the earlier procurement example, the schedule system did not clearly disclose that buried in every one of those equipment sequences was a surrendered month for fiddling around. That month was the cheapest one taken out of an already aggressive schedule.

The fiddling month was covered by two factors:

• Durations were generous. In the fashion identified by Goldratt, they were at least 80% confidence estimates.

• Transitions between activities were not expected to be crisp.

Goldratt deals well with the problem of generous durations. His analysis is recommended and will not be summarized here. Rather, we will deal with the problem of clear transitions. Most of the month recovered from each procurement group came neer did not trust the owner to make prompt decisions but found it politically inexpedient to say so. The engineer's way out of the dilemma was to pad the time for Evaluation of Proposals to cover the owner's indecision. The problem was easily fixed when it was identified. From a production management view a system that hides problems rather than confronting them yields poor results.

Driving Production From the Schedulers Convenience

The last situation examined is the most recently encountered. It comes from a recent troubled project where the unreasonable schedule requirements of the construction manager were a contributing factor to the problems. In this case the specifications clearly stated that it was the contractors responsibility to install piping by system. Completion dates for side-by-side piping systems were staged over several months. Delays in the detailed engineering meant that details were released on the same system driven schedule.

A significant set of problems arose when small pipe installed in pursuit of a system's completion was later found to be interfering with large pipe of another system. Difficulties in routing, additional fittings, and extensive rework added to the problems of a troubled project.

The source of the system-based requirements was found to be a desire to easily evaluate progress. The construction manager chose not to relax this requirement that had approached the realm of the insane.

A Current Model

How can a project deal with these situations? For many years the author accepted that the problems found in these situations represented mis-execution of scheduling methods. In more recent time he has leaned in the direction of attributing many of the problems identified as being mis-application of scheduling methods. Production management often requires its own set of tools, integrated with, but distinct from, scheduling tools. As with any feedback and control system care in selection and discipline in execution are necessary.

In the attempt to deal with this schedule-production issue in a general way our company has developed a model for interaction between production and schedule requirements. The system has been in use for eight years. It has worked well on a variety of projects.

The basic model starts with the division of the work scope into work packages. A work package is defined as the work of a single crew intended for performance in a continuous fashion. Beyond that, the boundaries are pretty flexible.

The intention is to accomplish several things by the definition of work packages:

• Divide the work into manageable elements

• Relate those elements to an efficient production scheme

• Deliver documentation of the work package to field crews in order to facilitate an understanding of scope, constraints, and means and methods

• Provide a means for assessing progress on project activities.

The full definition of the work package includes a listing of tasks, and a manhour estimate for the accomplishment of each task. The task list is then transferred to a computer listing from which progress is assessed against the completion state of each task. Progress on the work package is taken as the sum of the estimated hours for the completed tasks. Comparison to the actual hours expended provides a validation of the estimate and a critical feedback loop for future planning, both on the job and in future jobs. (See Exhibit 7.)

Two additional principles guide the definition of schedule activities and cost accounts:

• A schedule activity includes from one to many work packages. It does not include parts of work packages.

• A labor cost account covers performance of one to many work packages. A supervisor reporting labor cost deals with no more cost codes than the number of work packages his crew has worked on in a day (desirably, one of each).

The system is not intended to limit flexibility in the approach to work performance. It is not intended to prescribe work breakdown structures beyond their conformance to these basic principles.

Some examples of proscribed structures might clarify the application of these principles:

Exhibit 7

Exhibit 7

• Definition of work on a systems or material type basis that will be performed on a geographic basis. For example, defining the work by system when it must be performed lab by lab.

• Division of the work on a geographic basis that will be performed on a systems basis. For example, defining the work in a lab as a work package that includes both plumbing and high purity stainless steel that will be performed by different crews.

• Including work from different project time frames in the same work package. For example, startup is usually planned as a separate activity. Even if the work is performed by systems, startup of those systems is likely to represent a break in continuity of performance.

The structure and use of work packages emphasizes task completion. In addition, capsulizing the work in work packages helps address the need to ensure that obstacles are removed before work is scheduled for performance.

The state of completion of schedule activities can be assessed as the progress on the work packages that constitute the schedule activity.

Conclusions

Today's complex projects may involve thousands of individual tasks scattered across geography and time. The ultimate cost effectiveness, and the timely completion, of the project can be highly dependent on the management of these functions.

While the literature contains many cautions about the need to identify problems early and to focus on problem solving to bring projects to a successful conclusion, managing performance of the mundane level tasks of the project is often neglected. This production management function is often thought to be adequately handled by the normal project scheduling tools.

Those tools can leave the project management wanting for good information. They can also fail to provide adequate guidance to answer the question: What should a crew foreman be doing now.

With the flexible application of tools to project processes, we can overcome these problems.

Jaselskis, Edward. 1988. Cited in Hart, Hillary, Implementing Constructability. Austin, TX: Construction Industry Institute.

Goldratt, Eliyahu M. 1997. Critical Chain. Boston: North River Press.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
November 1-10, 2001 • Nashville, Tenn., USA

Advertisement

Advertisement

Related Content

Advertisement