Scheduling Resourcesand CostsFrojeet network limes are not a sehedule until resources have been assigned.
Cost eslimates are not a budget until they have been lime-phased.
We have consistently stressed that up-front planning results in big payoffs. For those whohave diligently worked through the earlier planning processes chapters, you are nearlyready to launch your project. This chapter completes the final two planning tasks thatbecome the master plan for your project-resource and cost scheduling. (See Figure 8.1.)This process uses the resource schedule to assign time-phased costs that provide the project budget baseline. Given this time-phased baseline, comparisons can be made withactual and planned schedule and costs. This chapter first discusses the process for developing the project resource schedule. This resource schedule will be used to assign the timephased budgeted values to create a project budget baseline.
There are always more project proposaIs than there are available resources. The priority system needs to select projects that best contribute to the organization's objectives,within the constraints of the resources available. If aIl projects and their respectiveresources are computer scheduled, the feasibility and impact of adding a new project tothose in process can be quickly assessed. With this information the project priority teamwill add a new project only if resources are available to be formally committed to thatspecific project. This chapter examines methods of scheduling resources so the team canmake realistic judgments of resource availability and project durations. The project manager uses the same schedule for implementing the project. If changes occur during project implementation, the computer schedule is easily updated and the effects easilyassessed.
After staff and other resources were assigned to her project, a project manager listed thefollowing questions that still needed to be addressed:
Will the assigned labor and/or equipment be adequate and available to deal with myproject?
Will outside contractors have to be used?
Do unforeseen resource dependencies exist? Is there a new critical path?
How much flexibility do we have in using resources?
Is the original deadline realistic?
Clearly, this project director has a good understanding of the problems she is facing. Anyproject scheduling system should facilitate finding quick, easy answers to these questions.
The planned network and activity project duration times found in previous chapters failto deal with resource usage and availability. The time estimates for the work packages andnetwork times were made independently with the implicit assumption that resources wouldbe available. This may or may not be the case.
If resources are adequate but the demand varies widely over the life of the project, itmay be desirable to even out resource demand by delaying noncritical activities (usingslack) to lower peak demand and, thus, increase resource utilization. This process is calledresource leveling or smoothing.
On the other hand, if resources are not adequate to meet peak demands, the late start ofsorne activities must be delayed, and the duration of the project may be increased. This process is called resource-constrained scheduling. One research study by your author ofmorethan 50 projects found that planned project network durations were increased 38 percentwhen resources were scheduled.
The consequences of failing to schedule limited resources are a costly activity and project delays usually manifest themselves midway in the project when quick corrective actionis difficult. An additional consequence of failing to schedule resources is ignoring thepeaks and valleys of resource usage over the duration of the project Because projectresources are usually overcommitted and because resources seldom line up by availabilityand need, procedures are needed to deal with these problems. This chapter addresses methods available to project managers for dealing with resource utilization and availabilitythrough resource leveling and resource-constrained scheduling.
Up to now the start and sequence of activities has been based solely on technical or logical considerations. For example, a project network for framing a house might show threeactivities in a sequence: (l) pour foundation, (2) build frame, and (3) coyer roof A network for a new software project could place the activities in the network, as a sequence of(l) design, (2) code, and (3) test In other words, you cannot 10gicaIly perform activity 2until l is completed, and so on. The project network depicts technical constraints. (SeeFigure 8.2A). The network assumes the personnel and equipment are available to performthe required work. This is often not the case!
The absence or shortage of resources can drastically alter technical constraints. Aproject network planner may assume adequate resources and show activities occurringin parallel. However, paraIlel activities hold potential for resource conflicts. For exampIe, assume you are planning a wedding reception that includes four activities-(l)plan, (2) hire band, (3) decorate hall, and (4) purchase refreshments. Each activitytakes one day. Activities 2, 3, and 4 could be done in parallel by different people. Thereis no technical reason or dependency of one on another (see Figure 8.2B). However, ifone person must perform aIl activities, the resource constraint requires the activitiesbe performed in sequence or series. Clearly the consequence is a delay of these activities and a very different set of network relationships (see Figure 8.2e). Note that the
resource dependency takes priority over the technological dependency but does notviolate the technological dependency; that is, hire, decorate, and purchase may nowhave to take place in sequence rather than concurrently, but they must aIl be completedbefore the reception can take place.
The interrelationships and interactions among time and resource constraints are complex for even small project networks. Some effort to examine these interactions before theproject begins frequently uncovers surprising problems. Project managers who do notconsider resource availability in moderately complex projects usually learn of the problem when it is too late to correct A deficit of resources can significantly alter projectdependency relationships, completion dates, and project costs. Project managers must becareful to schedule resources to ensure availability in the right quantities and at the righttime. Fortunately, there are computer software programs that can identify resource problems during the early project planning phase when corrective changes can be considered.These programs only require activity resource needs and availability information toschedule resources.
See the Snapshot from Practice: Working in Tight Places for a third constraint thatimpinges on project schedules.
eqllIip,mtmt, and material that can be drawn on to accomplish someav,ü)slbillity or unavailability of resources will often influence the way
ln rare situations, physical factors cause activities that wouldnormally occur in parallel to be constrained by contractual orenvironmental conditions. For example, in theory the renovation of a sail boat compartment might involve four to five tasksthat can be done independently, However, since space allowsonly one person to work at one time, ail tasks have to be performed sequentially, Likewise, on a mining project it may be
physically possible for only two miners to work in a shaft at atime. Another example would be the erection of a communication tower and nearby groundwork. For safety considerations,the contract prohibits groundwork within 2,000 feet of thetower construction.
The procedures for handling physical factors are similar tothose used for resource constra ints.
1. People This is the most obvious and important project resource. Human resourcesare usually c1assified by the skills they bring to the project~for example, programmer,mechanical engineer, weIder, inspector, marketing director, supervisor. In rare cases sorneskills are interchangeable, but usually with a loss of productivity. The many differing skillsofhuman resources add to the complexity of scheduling projects.
2. Materials Project materials coyer a large spectrum: for example, chemicals for ascientific project, concrete for a road project, survey data for a marketing project.
Material availability and shortages have been blamed for the delay of many projects.When it is known that a lack of availability of materials is important and probable, materials should be included in the project network plan and schedule. For example, deliveryand placement of an oil rig tower in a Siberian oil field has a very small time window during one summer month. Any delivery delay means a one-year, costly delay. Another exampIe in which material was the major resource scheduled was the resurfacing andreplacement of sorne structures on the Golden Gate Bridge in San Francisco. Work onthe project was Iimited to the hours between midnight and 5:00 A.M. with a penalty of
$1,000 per minute for any work taking place after 5:00 A.M. Scheduling the arrivaI ofreplacement structures was an extremely important part of managing the five-hour worktime window of the project. Scheduling materials has also become important in developing products where time-to-market can result in loss of market share.
3. Equipment Equipment is usually presented by type, size, and quantity. In sornecases equipment can be interchanged to improve schedules, but this is not typicaLEquipment is often overlooked as a constraint. The most common oversight is to assumethe resource pool is more than adequate for the project. For example, if a project needsone earth-moving tractor six months from now and the organization owns four, it is common to assume the resource will not delay the pending project. However, when the earthmoving tractor is due on-site in six months, aU four machines in the pool might beoccupied on other projects. In multiproject environments it is prudent to use a commonresource pool for aU projects. This approach forces a check of resource availabilityacross aU projects and reserves the equipment for specific project needs in the future.Recognition of equipment constraints before the project begins can avoid high crashingor delay costs.
Most of the scheduling methods available today require the project manager to classifythe project as either time constrained or resource constrained. Project managers need toconsult their priority matrix (see Figure 4.2) to determine which case fits their project.One simple test to determine if the project is time or resource constrained is to ask, "Ifthe critical path is delayed, will resources be added to get back on schedule?" If theanswer is yes, assume the project is time constrained; ifno, assume the project is resourceconstrained.
A time-constrained project is one that must be completed by an imposed date. Ifrequired, resources can be added to ensure the project is completed by a specifie date.Although time is the critical factor, resource usage should be no more than is necessaryand sufficient.
A resource-constrained project is one that assumes the level of resources availablecannot be exceeded. If the resources are inadequate, it wiU be acceptable to delay the project, but as little as possible.
In scheduling terms, time constrained means time (project duration) is fixed andresources are flexible, while resource constrained means resources are fixed and time isflexible. Methods for scheduling these projects are presented in the next section.
allocation methods available requires sorne limiting assumptions to keep attention on the heart of the problem. The rest of the chapter dependsentirely on the assumptions noted here. First, splitting activities will not be allowed. Thismeans once an activity is placed in the schedule, assume it wiU be worked on continuously until it is finished; hence, an activity cannot be started, stopped for a period oftime,and then fini shed. Second, the level of resources used for an activity cannot be changed.These limiting assumptions do not exist in practice, but simplify learning. It is easy for
new project managers to deal with the reality of splitting activities and changing the levelof resources when they meet them on the job.
Time-Constrained Projects: Smoothing Resource DemandScheduling time-constrained projects focuses on resource utilization. When demand for aspecific resource type is erratic, it is difficult to manage, and utilization may be very poor,Practitioners have attacked the utilization problem using resource leveling techniques thatbalance or smooth demand for a resource. Basically, allieveling techniques delay noncritical activities by using positive slack to reduce peak demand and fill in the valleys for theresources. An example will demonstrate the basic procedure for a time-constrained project.See Figure 8.3.
For the purpose of demonstration, the Botanical Garden project uses only oneresource (backhoes); all backhoes are interchangeable. The top bar chart shows theactivities on a time scale. The dependencies are shown with the vertical connectingarrows. The horizontal arrows following activities represent activity slack (for exampIe, irrigation requires six days to complete and has six days slack). The number ofbackhoes needed for each task is shown in the shaded activity duration block (rectangle). After the land has been scarified and the plan laid out, work can begin on thewalkways, irrigation, and fencing and retaining walls simultaneously. The middle chartshows the resource profile for the backhoes. For periods 4 through 10, four backhoesare needed.
Because this project is declared time constrained, the goal will be to reduce the peakrequirement for the resource and thereby increase the utilization of the resource. A quickexamination of the ES (early start) resource load chart suggests only two activities haveslack that can be used to reduce the peak-fence and walls provide the best choice forsmoothing the resource needs. Another choice could be irrigation, but it would result in anup and down resource profile. The choice will probably center on the activity that is perceived as having the least risk of being late. The smoothed resource loading chart showsthe results ofdelaying the fence and walls activity. Note the differences in the resource profiles. The important point is the resources needed over the life of the project have beenreduced from four to three (25 percent). In addition the profile has been smoothed, whichshould be easier to manage.
The Botanical Garden project schedule reached the three goals of smoothing:
The peak of demand for the resource was reduced.
Resources over the life of the project have been reduced.
The fluctuations in resource demand were minimized.
The latter improves the utilization ofresources. Backhoes are not easily moved from location to location. There are costs associated with changing the level of resources needed.The same analogy applies to the movement of people back and forth among projects. It isweil known that people are more efficient if they can focus their effort on one projectrather than multitasking their time among, say, three projects.
The downside of leveling is a loss of flexibility that occurs from reducing slack. Therisk of activities delaying the project also increases because slack reduction can createmore critical activities and/or near-critical activities. Pushing leveling too far for a perfectly level resource profile is risky. Every activity then becomes criticaL
The Botanical Garden example gives a sense of the time-constrained problem and thesmoothing approach. However, in practice the magnitude ofthe problem is very complex foreven small projects. Manual solutions are not practicaL Fortunately, the software packages
available today have very good routines for leveling project resources. Typically, they useactivities that have the most slack to level project resources. The rationale is those activitieswith the most slack pose the least risk. Although this is generally true, other risk factors suchas reduction of flexibility to use reassigned resources on other activities or the nature of theactivity (easy, complex) are not addressed using such a simple rationale. It is easy to experiment with many alternatives to find the one that best fits your project and minimizes risk ofdelaying the project.
Resource-Constrained ProjectsWhen the number of people and/or equipment is not adequate to meet peak demandrequirements and it is impossible to obtain more, the project manager faces a resourceconstrained problem. Something has to give. The trick is to prioritize and allocateresources to minimize project delay without exceeding the resource limit or altering thetechnical network relationships.
The resource scheduling problem is a large combinatorial one. This means even amodest-size project network with only a few resource types might have several thousandfeasible solutions. A few researchers have demonstrated optimum mathematical solutions to the resource allocation problem but only for small networks and very fewresource types, The massive data requirements for larger problems make pure mathematical solutions (e,g., Iinear programming) impractical. An alternative approach to theproblem has been the use of heuristics (rules of thumb) to solve large combinatorialproblems. These practical decision or priority rules have been in place for many years.
Heuristics do not always yield an optimal schedule, but they are very capable of yielding a "good" schedule for very complex networks with many types of resources. The efficiency of different mIes and combinations of mIes has been weil documented. However,because each project is unique, it is wise to test several sets of heuristics on a network todetermine the priority allocation mIes that minimize project delay. The computer softwareavailable today makes it very easy for the project manager to create a good resource schedule for the project. A simple example of the heuristic approach is iIIustrated here.
Heuristics allocate resources to activities to minimize project delay; that is, heuristicsprioritize which activities are allocated resources and which activities are delayed whenresources are not adequate. The following scheduling heuristics have been found to consistently minimize project delay over a large variety of projects. Schedule activities usingthe following heuristic priority mIes in the order presented:
1. Minimum slack.
2. Smallest duration.
3. Lowest activity identification number.
The parallel method is the most widely used approach to apply heuristics. The parallelmethod is an iterative process that starts at the first time period of the project and schedules period-by-period any activities eligible to start. In any period when two or more activities require the same resource, the priority mIes are applied. For example, if in period 5three activities are eligible to start (i.e., have the same ES) and require the same resource,the first activity placed in the schedule would be the activity with the least slack (mIe 1).However, if ail activities have the same slack, the next rule would be invoked (mIe 2), andthe activity with the smallest duration would be placed in the schedule first. In very rarecases, when ail eligible activities have the same slack and the same duration, the tie is broken by the lowest activity identification number (mIe 3), since each activity has a uniqueID number.
When a resource limit has been reached, the early start (ES) for succeeding activitiesnot yet in the schedule will be delayed (and ail successor activities not having free slack)and their slack reduced. In subsequent periods the procedure is repeated until the projectis scheduled. The procedure is demonstrated next, see Figure 8.4. The shaded areas in theresource loading chart represent the "scheduling interval" of the time constrained schedule (ES through LF). You can schedule the resource any place within the interval and notdelay the project. Scheduling the activity beyond the LF will delay the project.
The programmers are Iimited to three. Follow the actions described in Figures 8.4 and 8.5.Note how the Iimit ofthree programmers starts to delay the project.
0-1 Gnly activity 1 is eligible. It requires 2 programmers.Load activity 1 into schedule.
See Figure 8.4
1-2 No activities are eligible to be scheduled.2-3 Activities 2,3, and 4 are eligible to be scheduled. Activity 3 has the least slack (01-
apply rule 1.
Load Activity 3 into schedule.Activity 2 is next with slack of 2; however, activity 2 requires 2 programmers and
only 1 is available.Delay activity 2. Update: ES =3, slack =1.The next eligible activity is activity 4, since it only requires 1 programmer.Load activity 4 into schedule.
See Figure 8.5
3-4 Activity 2 is eligible but exceeds limit of 3 programmers in pool.Delay activity 2. Update: ES =4, slack =O.
4-5 Activity 2 is eligible but exceeds limit of 3 programmers in pool.Delay activity 2. Update: ES = 5, LF = 11, slack = -1.Delay activity 7. Update: ES = 11, LF = 13, slack =-1.
5-6 Activity 2 is eligible but exceeds Iimit of 3 programmers in pool.Delay activity 2. Update: ES = 6, LF = 12, slack = -2.Delay activity 7. Update: ES = 12, LF = 14, slack = -2.
6-7 Activities 2,5, and 6 are eligible with slack of -2,2, and 0, respectively.Load activity 2 into schedule (rule 1).Because activity 6 has 0 slack, it is the next eligible activity.Load activity 6 into schedule (rule 11.The programmer limit of 3 is reached.Delay activity 5. Update: ES =7, slack =1.
7-8 Limit is reached. No programmers available.Delay activity 5. Update: ES =8, slack =O.
8-9 Limit is reached. No programmers available.Delay activity 5. Update: ES = 9, LF = 11, slack = -1.
9-10 Limit is reached. No programmers available.Delay activity 5. Update: ES = 10, LF = 12, slack = -2.
10-11 Activity 5 is eligible.Load activity 5 into schedule.(Note: Activity 6 does not have slack because there are no programmers available3 maximum.l
11-12 No eligible activities.12-13 Activity 7 is eligible.
Load activity 7 into schedule.
Observe how it is necessary to update each period to reflect changes in activity earlystart and slack times so the heuristics can reflect changing priorities. When using the parallel scheduling method, the network in Figure 8.5 on page 243 reflects the new schedule date of 14 time units, rather than the time-constrained project duration of 12 timeunits. The network has also been revised to reflect new start, finish, and slack times foreach activity. Note that activity 6 is still critical and has a slack of 0 time units becauseno resources are available (they are being used on activities 2 and 5). Compare the slackfor each activity found in Figures 8.4 and 8.5; slack has been reduced significantly. Notethat activity 4 has only 2 units of slack rather than what appears to be 6 slack units. This
occurs because only three programmers are available, and they are needed to satisfy theresource requirements of activities 2 and 5. Note that the number of critical activities(l, 2, 3, 5, 6, 7) has increased from four to six,
This small example demonstrates the scenario of scheduling resources in real projectsand the resulting increase in the risk ofbeing late. In practice this is not a trivial problem!Managers who fail to schedule resources usually encounter this scheduling risk when it istoo late to work around the problem, resulting in a project delay.
Since manually using the parallel method is impractical on real-world projects becauseof size, project managers will depend on software programs to schedule project resources.
rp,:()I'vina compliwas described
above. We will use the EMR project to demonstrate how this is done using MS Project. Itis important to note that the software is not "managing" the project. The software is simply a tool the project manager uses to view the project from different perspectives andconditions. See the Snapshot from Practice on page 250 for more tips on assessingresource problems.
EMR is the name given to the development of a handheld electronic medical referenceguide to be used by emergency medical technicians and paramedics. Figure 8.6 contains atime-limited network for the design phase of the project. For the purpose of this example,we assume that only design engineers are required for the tasks and that the design engineers are interchangeable. The number of engineers required to perform each task is notedin the network, where 500 percent means five design engineers are needed for the activity.For example, activity 5, feature specs, requires four design engineers (400 percent). The project begins January l, and ends February 14, a duration of 45 workdays. The time-limited(constrained) bar chart for the project is shown in Figure 8.7. This bar chart incorporates thesame information used to develop the project network, but presents the project in the formof a bar chart along a time line.
Finally, a resource usage chart is presented for a segment of the project-January 15 toJanuary 23; see Figure 8.8A. Observe that the time-limited project requires 21 design engineers on January 18 and 19 (168 hrs/8 hrs per engineer 21 engineers). This segment represents the peak requirement for design engineers for the project. However, due to theshortage of design engineers and commitments to other projects, only eight engineers canbe assigned to the project. This creates overallocation problems more clearly detailed inFigure 8.8B, which is a resource loading chart for design engineers. Notice that the peakis 21 engineers and the limit of 8 engineers is shown by the gray shaded area.
To resolve this problem we use the "leveling" tool within the software and first try to solvethe problem by leveling only within slack. This solution would preserve the original finishdate. However, as expected, this does not solve all ofthe allocation problems. The next optionis to allow the software to apply scheduling heuristics and level outside of slack. The newschedule is contained in the revised, resource-limited network chart presented in Figure 8.9.The resource-Iimited project network indicates the project duration has now been extended to2/26, or 57 workdays (versus 45 days time Iimited). The critical path is now 2,3,9,13.
Figure 8.10 presents the project bar chart and the results of leveling the project schedule to reflect the availability of only eight design engineers. The application of the heuristics can be seen in the scheduling of the internaI, external, and fèature specificationactivities. Ali three activities were originally scheduled to start immediately after activity l,architectural decisions.
8l
EMR Project Network View Schedule before Resources Leveled
Voice recognition SW
~Start: 1/18 ID: 6
~Finish: 1/27 Dur: 10 days
Res: Design Engineers [400%]
Internai specs Case
.... Start: 1/6 ID: 3~
Start: 1/18 ID: 7~r-
Finish: 1/17 Dur: 12 days Finish: 1/21 Dur: 4 days
This is impossible, since the three activities collectively require 14 engineers. The software chooses to schedule activity 5 first because this activity is on the original critical pathand has zero slack (heuristic # 1). Next, and concurrently, activity 4 is chosen over activity 3because activity 4 has a shorter duration (heuristic # 2); internaI specs, activity 3, is delayeddue to the limitation of 8 design engineers. Notice that the original critical path no longerapplies because of the resource dependencies created by having only eight design engineers.
Compare the bar chart in Figure 8.10 with the time-limited bar chart in Figure 8.7. Forexample, note the different start dates for activity 8 (screen). In the time-limited plan(Figure 8.7), the start date for activity 8 is 1/18, while the start date in the resource limitedschedule (Figure 8.10) is 2/16, almost a month later!
While resource bar graphs are commonly used to illustrate overallocation problems, weprefer to view resource usage tables like the one presented in Figure 8.8A. This table tellsyou when you have an overallocation problem and identifies activities that are causing theoverallocation.
i
8
O@o -;3 CT1il ru~. :5:ru n~ CCl-N iïl
'" "ffi ±
g fO... CIl
n '"'" =-II> "~ c-Il> =-Er
<Cl::a"::l";;"II>
~~f~::+ = = -<:::r l» El) 1
<Cl <Cl ....m (1) CD l»
~ ;" a ;g' :; ~ ~
g ~ àCD CD _.
II> "!II a
Start: 2/22 ID: 13
Review design
Voice recognition SW
Start: 2/12 ID: 7
Star!: 1/16 ID: 10
Start: 1/26 ID: 11
Start: 1/21 ID: 12
Star!: 2/2 ID: 6
Screen
Start: 2/16 ID: 8
Start: 1/28 ID: 9
Finish: 211 Dur: 7 days
Res: Design Engineers [300%]
Finish: 1/20 Dur: 5
Res: Design Engineers [200%]
Digital devices
Database
Computer 1/0
Microphone-soundcard
Finish: 2/17 Dur: 2 days
Res: Design Engineers [300%]
Finish: 2/11 Dur: 10
Res: Design Engineers [400%]
Finish: 1/25 Dur: 5
Res: Design Engineers [300%]
Finish: 2/15 Dur: 4 days
Res: Design Engineers [200%]
Case
Start: 1/6 ID: 5
Start: 1/6 ID: 4
Finish: 1115 Dur: 10 days
Res: Design Engineers [400%]
Finish: 1/12 Dur: 7 days
Res: Design Engineers [400%]
Feature specs
Internai specs
External specs
Dur: 57 days
ID: 1
EMR Project Network View Schedule after Resources Leveled
One of the strengths of today's project management software is the ability to identify and provide options for resolving resource allocationproblems. A project manager who uses MS
Project to plan projects shared with us the following checklist fordealing with resource conflicts after preliminary assignment ofresources has been made.
1. Assess whether vou have overallocation problems (see Redin the resource sheet view.)
2. Identify where and when conflicts occur by examining theresource usage view.
3. Resolve the problem bya. Replacing overallocated resources with appropriate
resources that are available. Then ask if this solves theproblem.
If not:
b. Use the leveling tool and choose the level within slackoption.
Does this solve the problem? (Are resources still overal·located?)
ii Check the sensitivity of the network and ask if this isacceptable.
If not:
c. Consider splitting tasks.
i Make sure to readjust task durations to take intoaccount additional start·up and shutdown time.
4. If 3 does not work then either:
a. Use level tool default option and ask if Vou can live withthe new completion date.
If not:
b. Negotiate for additional resources to complete the project.
If not possible
c. Consider reducing project scope to meet deadline.
While this checklist makes specifie references to MS Project, thesame steps can be used with most project management software.
The Impacts of Resource-Constrained SchedulingLike leveling schedules, the limited resource schedule usually reduces slack, reduces flexibility by using slack to ensure delay is minimized, and increases the number ofcritical andnear-critical activities. Scheduling complexity is increased because resource constraintsare added to technical constraints; start times may now have two constraints. The traditional critical path concept of sequential activities from the start to the end of the projectis no longer meaningful. The resource constraints can break the sequence and leave thenetwork with a set of disjointed critical activities. Conversely, parallel activities canbecome sequential. Activities with slack on a time-constrained network can change fromcritical to noncritical.
Splitting tasks is a scheduling technique used to get a better project schedule and/or toincrease resource utilization. A planner splits the continuous work included in an activity by interrupting the work and sending the resource to another activity for a period oftime and then having the resource resume work on the original activity. Splitting can bea useful tool if the work involved does not include large start-up or shutdown costs-forexample, moving equipment from one activity location to another. The most cornmonerror is to interrupt "people work," where there are high conceptual start-up and shutdowncosts. For example, having a bridge designer take time off to work on the design problem of another project may cause this individual to lose four days shifting conceptualgears in and out of two activities. The cost may be hidden, but it is real. Figure 8.11depicts the nature of the splitting problem. The original activity has been split into three
separate activities: A, B, and C. The shutdown and start-up times lengthen the time forthe original activity.
Sorne have argued that the propensity to deal with resource shortages by splitting is amajor reason why projects fail to meet schedule. We agree. Planners should avoid the useof splitting as much as possible, except in situations where splitting costs are known to besmall or when there is no alternative for resolving the resource problem. Computer software offers the splitting option for each activity; use it sparingly. See Snapshot fromPractice: Assessing Resource Allocation.
It is important to remember that, if resources are truly limited and activity time estimatesare accurate, the resource-constrained schedule will materialize as the project is implemented-not the time-constrained schedule! Therefore, failure to schedule limitedresources can lead to serious problems for a project manager. The benefit of creating thisschedule belore the project begins leaves time for considering reasonable alternatives. Ifthe scheduled delay is unacceptable or the risk of being delayed too high, the assumptionof being resource constrained can be reassessed. Cost-time trade-offs can be considered.In sorne cases priorities may be changed. See Snapshot from Practice: US. Forest ServiceResource Shortage.
Resource schedules provide the information needed to prepare time-phased work package budgets with dates. Once established, they provide a quick means for a project manager to gauge the impact of unforeseen events such as turnover, equipment breakdowns, ortransfer of project personnel. Resource schedules also allow project managers to assesshow much flexibility they have over certain resources. This is useful when they receiverequests from other managers to borrow or share resources. Honoring such requests creates goodwill and an "IOU" that can be cashed in during a time ofneed.
A major segment of work in managing U,S.Forest Service (USFS) forests is selling maturetimber to logging companies that harvest thetimber under contra ct conditions monitored by
the Service. The proceeds are returned to the federal government The budget allocated to each forest depends on the twoyear plan submitted to the U.S. Department of Agriculture.
Olympic Forest headquarters in Olympia, Washington, wasdeveloping a two-year plan as a basis for funding. Ali of the districts in the forest submitted their timber sale projects (numbering more than 50) to headquarters, where they were compiledand aggregated into a project plan for the who le forest. The firstcomputer run was reviewed by a small group of senior managers to determine if the plan was reasonable and "doable."Management was pleased and relieved to note ail projectsa ppeared to be doable in the two-year time frame until a question was raised concerning the computer printout. "Why are ail
the columns in these projects labeled 'RESOURCE' blankT' Theresponse from an engineer was, "We don't use that part of theprogram."
The discussion that ensued recognized the importance ofresources in completing the two-year plan and ended with arequest to "try the program with resources included." The newoutput was startling. The two-year program turned into a threeand-a-half-year plan because of the shortage of specific laborskills such as road engineer and environmental impact specialist Analysis showed that adding only three skilled people wouldallow the two-year plan to be completed on time, ln addition, further analysis showed hiring only a few more skilled people,beyond the three, wou Id allow an extra year of projects to alsobe compressed into the two-year plan. This would result in additional revenue of more than $3 million. The Department ofAgriculture quickly approved the requested extra dollars foradditional staff to generate the extra revenue,
When making individual assignments, project managers should match, as best they can,the demands and requirements of specifie work with the qualifications and experience ofavailable participants. In doing so, there is a natural tendency to assign the best people themost difficult tasks. Project managers need to be careful not to overdo this. Over time thesepeople may grow to resent the fact that they are always given the toughest assignments. At thesame time, less experienced participants may resent the fact that they are never giventhe opportunity to expand their skill/knowledge base. Project managers need to balancetask performance with the need to develop the talents of people assigned to the project.
Project managers not only need to decide who does what but who works with whom. Anumber of factors need to be considered in deciding who should work together. First, tominimize unnecessary tension, managers should pick people with compatible work habitsand personalities but who complement each other (i.e., one person's weakness is the otherperson's strength). For example, one person may be brilliant at solving complex problemsbut sloppy at documenting his or her progress. It would be wise to pair this person with anindividual who is good at paying attention to details. Experience is another factor. Veteransshould be teamed up with new hires~not only so they can share their experience but alsoto help socialize the newcomers to the eustoms and norms of the organization. Finally,future needs should be considered. If managers have some people who have never workedtogether before but who have to later on in the project, they may be wise to take advantageofopportunities to have these people work together early on so that they can become familiar with each other. Finally, see the Snapshot in Practice: Managing Geeks for some interesting thoughts about how Novell, Inc., puts together teams.
For clarity we have discussed key resource allocation issues within the context of a singleproject. In reality resource allocation generally occurs in a multiproject environment wherethe demands of one project have to be reconciled with the needs of other projects.
Eric Schmidt, after a successful career at SunMicrosystems, took over struggling Novell, Inc.,and helped turn it around within two years, Oneof the keys to his success is his ability to man
age the technical wizards who develop the sophisticated systems, hardware, and software that are the backbone ofelectronically driven companies. He uses the term "geek" (andhe can, since he is one, with a Ph.D, in computer sciencel tadescribe this group of technologists who rule the cyberworld.
Schmidt has some interesting ideas about assigning geeks toprojects. He believes that putting geeks together in projectteamswith other geeks creates productive peer pressure. Geeks carea great deal about how other geeks perceive them. They aregood at judging the quality of technical work and are quick tapraise as weil as criticize each other's work. Some geeks can be
unbearably arrogant, but Schmidt claims that having them worktogether on projects is the best way to control them-by lettingthem control each other.
At the same time, Schmidt argues that too many geeks spoilthe soup. By this he means that, when there are tao many geekson a developmentteam, there is a tendencyfor intense technicalnavel gazing. Members lose sight of deadlines, and delays areinevitable. To combat this tendency, he recommends using geeksonly in small groups. He urges breaking up large projects intosmaller, more manageable projects so that small teams of geekscan be assigned to them. This keeps the project on time andmakes the teams responsible ta each other.
* Mitchel Russ, "How ta Manage Geeks," Fast Company (June 1999).pp. 175-80.
Organizations must develop and manage systems for efficiently allocating and schedulingresources across several projects with different priorities, resource requirements, sets ofactivities, and risks. The system must be dynamic and capable ofaccommodating new projects as weil as reallocating resources once project work is completed. While the sameresource issues and principles that apply to a single project also apply to this multiprojectenvironment, application and solutions are more complex, given the interdependencyamong projects.
The following lists three of the more common problems encountered in managing multiproject resource schedules. Note that these are macro manifestations of single-projectproblems that are now magnified in a multiproject environment:
1. Overall schedule slippage. Because projects often share resources, delays in one project can have a ripple effect and delay other projects, For example, work on one software development project can grind to a haIt because the coders scheduled for the nextcritical task are late in completing their work on another development project.
2. Inefficient resource utilization. Because projects have different schedules and requirements, there are peaks and valleys in overall resource demands. For example, a firmmay have a staff of 10 electricians to meet peak demands when, under normal conditions, only 5 electricians are required.
3. Resource bottlenecks. Delays and schedules are extended as a result of shortages ofcritical resources that are required by multiple projects. For example, at one LatticeSemiconductor facility, project schedules were delayed because of competition overaccess to test equipment necessary to debug programs. Likewise, several projects ata U.S. forest area were extended because there was only one silviculturist on thestaff.
To deal with these problems, more and more companies create project offices ordepartments to oversee the scheduling of resources across multiple projects. Oneapproach to multiple project resource scheduling is to use a first come~first servedmIe. A project queue system is created in which projects currently underway takeprecedence over new projects. New project schedules are based on the projected availability of resources. This queuing tends to lead to more reliable completion estimates
Interviewer: Congratulations on acceptance of your multi
project scheduling proposaI. Everyone tells me you were very
convincing.
Middle Manager: Thanks. Gaining acceptance was easy this
time. The board quickly recognized we have no choiE:e if we are
to keep ahead of competition by placing our resources on the
right projects.
Interviewer: Have you presented this to the board before?
Middle Manager: Yes, but not this company. 1presented the
sa me spiel to the firm 1 worked for two years ago. For their
annual review meeting 1was chargedto present a proposai sug
gesting the need and benefits of central E:apacity resource plan
ning for managing the projects of the firm.
1tried to build a case for bringing projects under one umbrella
to standardize practices and to forecast and assign key people to
miSSion critical projects. 1 explained how benefits such as
resource demands will be aligned with mission critical projects,
proactive resourE:e planning, and a tool for catE:hing resource
bottleneE:ks and resolving conflicts.
Almost everyone agreed the idea was a good one. 1felt good
about the presentation and felt confident something was going to
happen. But the idea never really got off the ground; it just faded
into the sunset.
With hindsight, managers really did not trust colleagues in
other departments, so they only gave half-hearted support to
central resource planning. Managers wanted to protect their
turf and ensure that they would not have to give up power. The
culture there was simply too inflexible for the world we live in
today. They are still struggling with E:onstant confliE:ts among
projects.
l'm glad 1made the switch to this firm. The culture here is
much more team-oriented. Management is committed to improv
ing performance.
and is preferred on contracted projects that have stiff penalties for being late. The disadvantages of this deceptively simple approach are that it does not optimally utilizeresources or take into account the priority of the project. See the Snapshot fromPractice: Multiple Project Resource Scheduling.
Many companies utilize more elaborate processes for scheduling resources to increasethe capacity of the organization to initiate projects. Most of these methods approach theproblem by treating individual projects as part ofone big project and adapting the scheduling heuristics previously introduced to this "megaproject." Project schedulers monitorresource usage and provide updated schedules based on progress and resource availabilityacross aIl projects. One major improvement in project management software in recentyears is the ability to prioritize resource allocation to specifie projects. Projects can be prioritized in ascending order (e.g., 1,2,3,4, ...), and these priorities will override scheduling heuristics so that resources go to the project highest on the priority list. (Note: Thisimprovement fits perfectly with organizations that use project priority models similar tothose described in Chapter 2.) Centralized project scheduling also makes it easier to identify resource bottlenecks that stifle progress on projects. Once identified, the impact of thebottlenecks can be documented and used to justify acquiring additional equipment, recruiting critical personnel, or delaying the project.
FinaIly, many companies are using outsourcing as a means for dealing with theirresource allocation problems. In sorne cases, a company will reduce the number ofprojectsthey have to manage internally to only core projects and outsource noncritical projects tocontractors and consulting firms. In other cases, specifie segments of projects are outsourced to overcome resource deficiencies and scheduling problems. Companies may hiretemporary workers to expedite certain activities that are falling behind schedule or contractproject work during peak periods when there are insufficient internaI resources to meet thedemands of aIl projects. The ability to more efficiently manage the ebbs and flows of project work is one of the major driving forces behind outsourcing today.
Once resource assignments have been finalized we are able to develop a baseline budgetschedule for the project Using YOUf project schedule, you can lime-phase work packagesand assign them to their respective scheduled activities to develop a budget schedule overthe life of YOUf project Understanding the reason for time-phasing YOUf budget is veryimportant. Without a time-phased budget good project schedule and cost control areimpossible,
Why a Time-Phased Budget Baseline Is NeededThe need for a time-phased budget baseline is demonstrated in the following scenario. Thedevelopment of a new product is to be completed in 10 weeks at an estimated cost of$400,000 per week for a total cost of $4 million. Management wants a status report at theend of five weeks. The following information has been collected:
Planned costs for the first five weeks are $2,000,000.
Actual costs for the first five months are $2,400,000.
How are we doing? It would be easy to draw the conclusion there is a $400,000 costoverrun. But we really have no way of knowing. The $400,000 may represent moneyspent to move the project ahead of schedule. Assume another set of data at the end offive weeks:
Planned costs for the first five weeks are $2,000,000.
Actual costs for the first five weeks are $1,700,000.
Is the project costing $300,000 less than we expected? Perhaps. But the $300,000 mayrepresent the fact that the project is behind schedule and work has not started. Could it bethe project is behind schedule and over cost? We cannot tell from these data. The manysystems found in the real world that use only planned funds (a constant bum rate) andactual costs can provide false and misleading information. There is no way to be certainhow much of the physical work has been accomplished. These systems do not measurehow much work was accomplishedfor the money spent! Hence, wilhout time-phasing costto match your project schedule, il is impossible to have reliable information jor controlpUlposes.
Creating a Time-Phased BudgetBy using information from YOUf WBS and resoUfce schedule, you can create a time-phasedcost baseline. Remember from the WBS for the PC Project in Chapters 4 and 5 we integrated the WBS and OBS organization breakdown structure so the work packages couldbe tracked by deliverable and organization responsible. See Figure 8.12 for an example ofthe PC Prototype Project arranged by deliverable and organization unit responsible. Foreach intersection point of the WBS/OBS matrix, you see work package budgets and thetotal cost. The total cost at each intersection is called a cost or control account For exampIe, at the intersection of the Read/write head deliverable and the Production departmentwe see there are three work packages with a total budget of $200,000. The sum of aIl costaccounts in a column should represent the total costs for the deliverable. Conversely, thesum of the cost accounts in a row should represent the costs or budget for the organizational unit responsible to accomplish the work. You can continue to "roll up" costs on theWBS/OBS to total project costs. This WBS provides the information you can use to time
,.------------------------1 Disk storage 1-------------,units
$5,160
phase work packages and assign them to their respective scheduled activities over the lifeof the project.
Recall, from the development of your work breakdown structure for each work package, the following information needed to be developed:
1. Define work (what).
2. Identify time to complete a work package (how long).
3. Identify a time-phased budget to complete a work package (cost).
4. Identify resources needed to complete a work package (how much).
5. Identify a single person responsible for units ofwork (who).
6. Identify monitoring points for measuring progress (how well).
Number three, time-phasing the work package, is critical for the final step of creatingyour budget baseline. The process of time-phasing work packages, which is illustratednext, is demonstated in Figure 8.13. The work package has a duration of three weeks.Assuming labor, materials, and equipment are tracked separately, the work package costsfor labor are distributed over the three weeks as they are expect to occur~$40,000, $30,000,and $50,000 for each week, respectively. When the three-week work package is placed inthe network schedule, the costs are distributed to the time-phased budget for the same threescheduled weeks. Fortunately, most single WPs become an activity and the process of
Work Package Duration 3 WAAk.c: Total labor cost $120
Time-Phased Labor Budget ($000)
WorkResource
Labor Work Periods--WeeksPackage rate 1 1 2 1 3 1 4 1 5 1 Total
Code Quality $xxxx!$40
1
$301
$501 1 1
$1201.1.3.2.3 testers week
distributing costs is relatively simple. That is, the relationship is one-for-one. Such budgettiming is directly from the work package to the activity.
In a few instances an activity will include more than one work package, where thepackages are assigned to one responsible person or department and deliverable. In thiscase the work packages are consolidated into one activity. As seen in Figure 8.14, thisactivity includes two WPs. The first, WP-l. 1.3.2.4. 1 (Code), is distributed over thefirst three weeks. The second, WP-1.1.3.2.4.2 (Integration), is sequenced over weeks3 and 4. The actvity duration is four weeks. When the activity is placed in the schedule, the costs are distributed starting with the schedule start-$20,000, $15,000,$75,000, and $70,000, respectively.
These time-phased budgets for work packages are lifted from your WBS and areplaced in your project schedule as they are expected to occur over the life of the project.The outcome ofthese budget allocations is the project cost baseline (also called plannedvalue~PV), which is used to determine cost and schedule variances as the project isimplemented.
Figure 8.15 shows the Patient Entry Project network schedule, which is used to placethe time-phased work packages' budgets in the baseline. Figure 8.16 presents the projecttime-phased budget for the Patient Entry Project and the cumulative graph of the projectbudget baseline. In this figure you can see how the time-phased work package costs wereplaced into the network and how the cumulative project budget graph for a project isdeveloped. Notice that costs do not have to be distributed linearly, but the costs should beplaced as you expect them to occur.
You have now developed complete time and cost plans for your project. These project baselines will be used to compare planned schedule and costs using an integrativesystem called earned value. The application and use ofproject baselines to measure performance are discussed in detail in Chapter 13. With your project budget baseline established, you are also able to generate cash flow statements for your project like the onepresented in Figure 8.17. Such statements prepare the finn to cover costs over the lifespan of the project. Finally, with resource assignments finalized you are able to generate resource usage schedules for your project (see Figure 8.18). These schedules mapout the full deployment of personnel and equipment and can be used to generate individual work schedules.
R. Sexon 24 hrs 40 hrs 40 hrsHardware specifications 24 hrs 40 hrs 40 hrsPrototypesAssemble preproduction modelsOC driversComplex utilitiesIntegration first phaseSystem HIS testIntegration acceptance test
Usage and availability of resources are major problem areas for project managers.Attention to these areas in developing a project schedule can point out resource bottlenecksbefore the project begins. Project managers should understand the ramifications of failingto schedule resources. The results of resource scheduling are frequently significantly different from the results of the standard CPM method.
With the rapid changes in technology and emphasis on time-to-market, catching resourceusage and availability problems before the project starts can save the costs ofcrashing projectactivities later. Any resource deviations from plan and schedule that occur when the project isbeing implemented can be quickly recorded and the effect noted. Without this immediateupdate capability, the real negative effect ofa change may not be known until it happens. Tyingresource availability to a multiproject, multiresource system supports a project priority processthat selects projects by their contribution to the organization's objectives and strategic plan.
Assignment of individuals to projects may not fit weIl with those assigned by computersoftware routines. In these cases overriding the computer solution to accommodate individual differences and skills is almost always the best choice.
The project resource schedule is important because it serves as your time baseline, which isused for measuring time differences between plan and actual. The resource schedule serves asthe basis for developing your time-phased project cost budget baseline. The baseline (plannedvalue, PV) is the SUffi of the cost accounts, and each cost account is the sum ofthe work packages in the cost account. Remember, ifyour budgeted costs are not time-phased, you really haveno reliable way to measure performance. Although there are several types of project costs, thecost baseline is usually limited to direct costs (such as labor, materials, equipment) that are underthe control ofthe project manager; other indirect costs can be added to project costs separately.
Fill in the limes below for a resource activity schedule.
ID/RES ES LS EF LF SL
1-EE1--+--+--+--+--;
2-EE1----+--+--+--+----1
3-ME1----+--+--+--+----1
4-EE
Develop a loading schedule for each resource below. (Figure 8.3)
1. Given the network plan that fol1ows, compute the ear1y, late, and slack times. What is theproject duration? Using any approach you wish (e.g., trial and error), develop a loadingchart for resources, Electrical Engineers (EE), and resource, Mechanical Engineers (ME).Assume only one of each resource exists. Given your resource schedule, compute the
1. How does resource scheduling tie to project priority?
2. How does resource scheduling reduce flexibility in managing projects?
3. Present six reasons scheduling resources is an important task.
4. How can outsourcing project work al1eviate the three most common problems associated with multiproject resource scheduling?
5. Explain the risks associated with leve1ing resources, compressing or crashing projects,and imposed durations or "catch-up" as the project is being implemented.
6. Why is it critical to develop a time-phased baseline?
3. Compute the early, late, and slack times for the activities in the network that follows,assuming a time-constrained network. Which activities are critical? What is the timeconstrained project duration?
Note: Recall, in the schedule resource load chart the time-constrained "schedulinginterval (ES through LF) has been shaded. Any resource scheduled beyond the shadedarea will delay the project.
early, late, and slack times for your project. Which activities are now critical? What is theproject duration now? Could something like this happen in real projects?
2. Given the network plan that follows, compute the early, late, and slack times. What isthe project duration? Using any approach you wish (e.g., trial and error), develop aloading chart for resources Carpenters (C) and Electricians (E). Assume only oneCarpenter is available and two Electricians are available. Given your resource schedule,compute the early, late, and slack times for your project. Which activities are now critical? What is the project duration now?
Assume you have only three resources and you are using a computer that uses softwarethat schedules projects by the parallel method and following heuristics. Schedule only oneperiod at a time!
Minimum slack
Smallest duration
Lowest identification number
Keep a log of each activity change and update you make each period-e.g., period 0-1,1-2, 2-3, etc. (Use a format similar to the one on page 241.) The log should include anychanges or updates in ES and slack times each period, activities scheduled, and activitiesdelayed. (Hint: Remember to maintain the technical dependencies ofthe network.) Use theresource load chart to assist you in scheduling (see pages 242-243).
List the order in which you scheduled the activities of the project. Which activities ofyour schedule are now critical'1
Recompute your slack for each activity given your new schedule. What is the slack foractivity 1'1 4'1 5'1
Scheduled resource load chart with ES and slack updates
ID RES DUR ES LF SL 0 2 3 4 5 6 7 8 9 10 11 12 13 14 15
4, Develop a resource schedule in the loading chart that follows. Use the parallel methodand heuristics given. Be sure to update each period as the computer wouId do. Note:Activities 2, 3, 5, and 6 use two of the resource skills. Three of the resource skills areavailable.
Legend
9 10 11 12 13 14 158765432
List the order in which youractivities are scheduled1__ 1__ 1__ 11__ 1__ 1__ 1
ID RES DUR ES LF SL 0
1 1 4 0 5 1 EtE2 2 5 0 5
3 2 4 4 10
4 1 5 5 10 3e3:EmResources scheduled
Resources available 1 3 1 3 3 v v 3 3 v v ;j ;j 3 3 v v
What is the schedule slack for 1__• 2__• and 4__?Which actîvîtîes are critical now? _
Use the following heuristics:Minimum slackSmallest durationLowest identification number
Develop a resource-constrained schedule in the loadîng chart below.
Complete a time-constrained plan in the project network.
5. You have prepared the following schedule for a project in which the key resource is abackhoe. This schedule is contingent on having 3 backhoes. You receive a cal1 from YOUf
partner, Brooker, who desperately needs 1 of your backhoes. You tell Brooker youwould be willing to let him have the backhoe ifyou are still able to complete your project in Il months.
Develop a resource schedule in the loading chart that follows to see if it is possibleto complete the project in Il months with only 2 backhoes. Be sure to record the orderin which you schedule the activities using scheduling heuristics. Activities 5 and 6require 2 backhoes, while activities l, 2, 3, and 4 require 1 backhoe. No splitting ofactivities is possible. Can you say yes to Brooker's request?
Legend
9 10 11 12 13
Chapter 8 Scheduling Resources and Costs 265
8765
729
7 6 9
a 2 a
432
Schedule the resource load chart with ES and Slack updates
Arrow, K. 1., and L Hurowicz, Studies in Resource Allocation Process (New York:Cambridge University Press, 1997).
Brucker, P., A. Drex1, R. Mohring, L. Newmann, and E. Pesch, "Resource-constrainedProject Schedu1ing: Notation, Classification, Models and Methods," European Journal ofOperational Research, Vol. 112, 1999, pp. 3-42.
Burgess, A. R., and 1. B. Kellebrew, "Variations in Activity Leve1 on Cyelieal ArrowDiagrams," Journal ofIndustrial Engineering, Vol. 13, March-April 1962, pp. 76-83.
Chames, A, and W. W. Cooper, "A Network Interpretation and Direct Sub Dual A1gorithmfor Critical Path Schedu1ing," Journal oflndustrial Engineering, Ju1y-August 1962.
Demeulemeester, E. L, and W. S. Herroelen, Project Scheduling: A Research Handbook(Norwell, Mass: Kluwer Academie Publishers, 2002).
Fendly, L G., "Towards the Development of a Complete Multi Project SchedulingSystem," Journal ofIndustrial Engineering, Vol. 19, 1968, pp. 505-15.
Reinersten, o., "Is ItAlways a Bad Idea to Add Resources to a Late Project?" ElectricDesign, October 30,2000, pp. 17-18.
Talbot, B. F., and 1. H. Patterson, "Optimal Methods for Scheduling Under ResourceConstraints," Project Management Journal, December 1979.
Wiest, 1. o., "A Heuristic Model for Scheduling Large Projects with UnlimitedResources," Management Science, Vol. 18, February 1967, pp. 359-77.
Woodworth, B. M., and C. 1. Willie, "A Heuristic Algorithm for Resource Leveling inMultiproject, Multiresource Scheduling," Decision Sciences, VoL 6, July 1975, pp. 525-40.
Woodworth, B. M., and S. Shanahan, "Identifying the Critical Sequence in a ResourceConstrained Projeet," International Journal ofProject Management, Vol. 6, 1988, pp. 89-96.
Power Train, Ltd.
We have smashing systems for reporting, tracking, and controlling costs on
design projects. Our planning ofprojects is better than any 1 have seen at
other companies. Our scheduling seemed to serve us well when we were
small and we had only a few projects. Now that we have many more projects
and schedule using multiproject software, there are too many occasions
when the right people are not assigned to the projects deemed important toour success. This situation is costing us big money, headaches, and stress!
Claude Jones, Vp, Design and Operations
Power Train, Ltd. (PT), was founded in 1960 by Daniel Gage, a ski lIed mechanieal engineer and machinist. Prior to founding PT he worked for three years as design engineer fora company that designed and built transmissions for military tanks and trucks. It was a
natural transition for Dan to start a company designing and building power trains for farmtractor companies. Today, Dan is no longer active in the management of PT but is stillrevered as its founder. He and his family still own 25 percent of the company, which wentpublic in 1988. PT has been growing at a 6 percent clip for the last five years but expectsindustry growth to level off as supply exceeds demand.
Today, PT continues its proud tradition ofdesigning and building the best-quality powertrains for manufacturers offarm tractors and equipment. The company employs 178 designengineers and has about 1,800 production and support staff Contract design projects fortractor manufacturers represent a major portion of PT's revenue. At any given time, about45 to 60 design projects are going on concurrently. A small portion oftheir design work isfor military vehicles. PT only accepts military contracts that involve very advanced, newtechnology and are cost plus.
A new phenomenon has attracted management of PT to look into a larger market. Lastyear a large Swedish truck manufacturer approached PT to consider designing power trainsfor its trucks. As the industry consolidates, the opportunities for PT should increasebecause these large firms are moving to more outsourcing to cut infrastructure costs andstay very flexible. Only last week a PT design engineer spoke to a German truck manufacturing manager at a conference. The German manager was already exploring outsourcing of drive trains to Porsche and was very pleased to be reminded of PT's expertise in thearea. A meeting is set up for next month.
Claude Jones joined PT in 1989 as a new MBA from the University of Edinburgh. Heworked as a mechanical engineer for UK. Hydraulics for five years prior to returning toschool for the MBA. "1 just wanted to be part of the management team and where theaction is." Jones moved quickly through the ranks. Today he is the vice president of designand operations. Sitting at his desk, Jones is pondering the conflicts and confusion thatseem to be increasing in scheduling people to projects. He gets a real rush at the thoughtof designing power trains for large trucks; however, given their current project schedulingproblems, a large increase in business would only compound their problems. Somehowthese conflicts in scheduling have to be resolved before any serious thought can be givento expanding into design of power transmissions for truck manufacturers.
Jones is thinking of the problems PT had in the last year. The MF project is the first tocome to mind. The project was not terribly complex and did not require their best designengineers. Unfortunately, the scheduling software assigned one of the most creative andexpensive engineers to the MF project. A similar situation, but reversed, happened on theDeer project. This project involved a big customer and new hydrostatic technology forsmall tractors. ln this project the scheduling software assigned engineers who were notfamiliar with small tractor transmissions. Somehow, thinks Jones, the right people need tobe scheduled to the right projects. Upon reflection, this problem with scheduling has beenincreasing since PT went to multiproject scheduling. Maybe a project office is needed tokeep on top ofthese problems.
A meeting with the information technology team and software vendors was positive but notvery helpful because these people are not really into detailed scheduling problems. The vendors provided aIl sorts of evidence suggesting the heuristics used-least slack, shortest duration, and identification number-are absolutely efficient in scheduling people and minimizingproject delays. One project software vendor, Lauren, kept saying their software would allowPT to customize the scheduling ofprojects and people to almost any variation selected. Laurenrepeated over and over, "If the standard heuristics do not meet your requirements, create yourown heuristics that do." Lauren even vohmteered to assist in setting up the system. But she is
not willing to spend time on the problem until PT can describe to her exactly what criteria willbe used (and their sequence) to select and schedule people to projects.
Potential expansion into the truck power train business is not feasible until the confusionin project scheduling is solved or reduced significantly. Jones is ready to tackle this problem, but he is not sure where to start.
