Resource Leveling to the Project

Look once again at Figure 6-8. Tasks 2, 3.2, and 3.3 are all scheduled to start on March 29. The scriptwriter is required for the first two of the three items and the producer for the last two. The scriptwriter’s calendar (Table 6-2) indicates that the scriptwriter can work a 54-hour week—6 days per week at 9 hours per day. The producer is available for a standard 40-hour week. The resource-loading table (Table 6-3) shows the above-mentioned tasks assigned to the scriptwriter and producer. Apparently both are expected to do two differ­ent jobs at the same time.

The scriptwriter’s conflict must be reduced. Figures 6-9 and 6-10 illustrate the prob­lem clearly. Both illustrations are MSP outputs. Figure 6-9 lists all tasks for which the scriptwriter is scheduled. Figure 6-10 indicates that the scriptwriter is overallocated by a factor of 2 during the period from March 29 to April 2.

Figure 6-9 also shows considerable slack in WBS 3.2. If we ask MSP to level resources, the software will move activities so that resources do not exceed their capacities—and will do so by using available slack first, where possible, rather than extending the project duration. (Clearly, the PM could do the same thing manually, but the job becomes com­plex and time-consuming on all but small projects.) Figures 6-11 and 6-12 show the effect of resource leveling on the scriptwriter’s workload. In this case the project duration was not affected because there was sufficient slack in WBS 3.2, and the leveling opera­tion used it. (PMBOK covers the topic of resource leveling in Chapter 6 on Time.)

To understand Figure 6-11 correctly requires an understanding of MSP. The figure appears to report that the scriptwriter is still working overtime on Tasks 2 and 3.2. This would also mean that there was an error in Figure 6-12 that shows no such thing. The scriptwriter’s efforts are, in fact, solely devoted to scriptwriting (Task 2), but the producer and the client are working on Task 3.2, so the task is shown as being underway. MSP has split Task 3.2, and the scriptwriter begins work on the task on Monday, April 12 after work on Task 2 has been completed. The second part of Task 3.2 does not begin until all work on Task 2 is complete. It is easy to verify that this has happened. Table 6-4 shows the resource allocation, after leveling the scriptwriter’s workload, using a daily calendar. The scriptwriter is not assigned more than 9 hours per day. On Monday, April 12 work transfers from Task 2 to Task 3.2.

The problem of the still overallocated producer is another matter. This is the same problem we discussed above concerning the client’s need to attend some meetings. The fact that the producer is overscheduled is not really a problem. Neither of the conflicting tasks (WBS task 3.2 and 3.3) requires 8 hours per day of work by the producer. The dura­tion of 5 days for Task 3.2 (Propose shoots), for example, indicates that the producer will be spending some time during a 5-day period on the job of proposing locations and set­tings for filming. Similarly, Task 3.3 (Hire secretary) will require the producer to inter­view some candidates for the secretarial position during the same 5-day period, but this will not be a full-time job either. The 5-day durations are an indication of when the tasks are expected to be complete. Task duration is not necessarily dictated by the amount of labor required to complete the task, but by the calendar time required to complete it. Sometimes, of course, the amount of labor may be the determinant of calendar time, but often it is not.

At this point a short digression is appropriate. As a student of project management reading this book, you probably know little of the reality of the projects used here as examples of this or that project management problem. As a PM working on a real-world project, you know a great deal more about the reality of your project than could possibly be explained in this book on the subject. The PM of the documentary project knows that there will be no problem raised by the apparent conflict in the allocation of the produc­er’s time. The PM could have used one of the methods we noted in the discussion of resource loading to handle the matter, but elected not to take the time and effort. This, then, is another of the trade-offs the PM must make. Not every facet of a project requires equal managerial care. The PM must decide where to expend his or her managerial efforts—and then take responsibility for the decision.

A resource allocation decision may be intended to avoid future problems rather than to cure a present problem. While the scriptwriter is not overallocated, the PM decided to add a second scriptwriter to WBS 2. The PM also leveled the producer’s apparent overal­location just to add some slack to the producer’s schedule. Both of these additions were made to ensure that the project was not made late by a glitch in the producer’s work or in the scriptwriting activity, which is on the project’s critical path. (See Section 6.5 for additional information about the advisability of having some excess capacity in pro­jects.) The result of all these moves is seen in Figure 6-13. The project can be finished 2 weeks or 16 days earlier than indicated in Figure 6-8.

When resources are added to a project, the PM may be asked to explain just how the project budget came to be underestimated. To answer such a question, the PM would be well advised to contact the administration of any large city that has recently built a sports stadium.

A more or less steady state demand for human resources is highly desirable—if it is not seriously inconsistent with the technological demands of the project. The cost of adding, laying-off, or permanently releasing human beings is very high for both hourly and salaried personnel. If the parent organization is quite large and is operating many projects that have reasonably high commonality in their demand for certain skills, it is often possible to set up “pools” for such skills as clerical, machine operation, and similar types of workers. When pools are used to supply resources for projects, careful records must be kept to ensure fast determination of skill availability and that the proper charges are made to all projects.

Pools of like resources from which labor can be added temporarily to projects tend to cut costs for the firm as a whole. Pools also cut the cost of managing the project. The PM’s job is made easier, and the cash flows of the project are less volatile. The PM will spend far less time trying to find and recruit personnel. Such pools, however, are useful only if the labor is not subdivided into highly specialized subtasks. Secretarial skills are less specialized than, say, the skills required to design, generate, or test computer software. The conclusion is that secretarial pools are feasible, but that software design, generation, and testing should be done by “teams” in which the required specialists are available.

Resource Loading/Leveling and Uncertainty

Figure 6-14 is a resource-loading chart for a software engineering group in a large firm. The chart depicts the total number of hours required of a resource group (all members from one department assigned to the firm’s projects) displayed against the group’s capac­ity. (MSP resource-loading information was exported to an Excel® spreadsheet and dis­played graphically. The process of producing such displays is not difficult.) There are 21 members of the group. They are scheduled for 40 hours per 5-day week by the firm. Figure 6-14 covers a 34-week period. The graph shows estimated work hours (28,282) committed by this team for projects that are currently on the company’s books. The delivery-date commitments are such that group workloads exceed the group’s capacity through much of March and April, for a brief period in the middle of May, and again in the latter part of June. (The total of these overloads is 1,747 hours, or a bit more than 83 hours per person.)

A rough estimate of group capacity is

21 (people)x 40 (hours per week)x 34 (weeks) = 28,560 labor hours

But a few corrections are in order. There are three national holidays in the period: Memorial Day, the Fourth of July, and Labor Day. The time lost for the holidays is

21×3(days)x8(h ours) = 504 labor hours

which lowers capacity to 28,056 labor hours. Assume further that 11 people take a 2- week vacation during the 34-week period, a conservative assumption given the fact that the period includes May through September. The time for 11 vacations is an additional capacity loss of

11 x 2 (weeks) x 40 = 880 labor hours

There are now 28,056 – 880 = 27,176 labor hours available, and even if the group’s work were evenly distributed across the 34-week period, the team’s capacity is about 1,100 less than the scheduled demand for work. The workload is 28,282/27,176 = 1.04 or 104 per­cent of capacity.

A 4 percent shortage of capacity does not seem like much. Why not increase the hours worked per week for these salaried software engineers to 41.6 hours per week? The added capacity will (roughly) equal the estimated workload. While such a move might help, it would not begin to solve the problem. For instance, is it likely that no engineers in the group will be ill and absent on any of the 170 workdays? Is it likely . . . no; is it possible that every task the group is scheduled to perform will be ready for the group’s work exactly on schedule? Is it possible that all required facilities and equipment will be available when needed? Is it possible that there will be no change orders extending the time required for any phase of the work the group is committed to complete? In reality, the probability that any of the above conditions will be met is, as mathematicians are wont to say, vanishingly small. But even if they were met, what about that large bulge of work required in March and April?

For many years, the study of Operations Management has included the subject of “line balancing.” (See Meredith and Shafer, 2016, pp 72 ff.) The purpose of line bal­ancing is to construct a manufacturing production line such that the individual pro­duction units on the line can generate the required amount of product with as little excess capacity as possible. Minimizing excess capacity in the elements of a production line is one test of production line efficiency. This concept, when applied to the resources used by projects—as it often is—is a precursor to disaster. Even in production lines, some excess capacity is required to deal with minor problems and variations that arise during the production process. In projects, the level of uncertainty surrounding the “production process” is so much greater that the amount of excess capacity in the work force needs to be much larger. If this flies in the face of managerial instinct, it is because that instinct is sometimes in error. We will revisit this problem in the follow­ing section.

The result of the situation displayed in Figure 6-14 is that all the projects to which this team of engineers is devoted are going to be late and over budget unless some drastic steps are taken to prevent it. The firm in question is known for high-quality work, and it is assumed that the projects will be completed more or less on time with a reasonable percent of the promised specifications in place and working. How this comes about is quite simple. Engineers in this firm are scheduled to work a 40-hour week. They do not, however, work 40-hour weeks. They average between 50 and 60 hours per week. At a 55-hour week, for example, the capacity of the group is approximately 37,500 labor hours. Given the 28,282 labor-hour workload, the system would operate, on average, at about 75 percent of capacity—which explains the engineering group’s ability to meet most of its delivery-date commitments.

Most project management software will, when asked politely, level out the loads (usage) for individual resources and warn the PM when a resource is scheduled for greater-than-capacity workloads. Whenever possible, the leveling will utilize any available activity slack rather than extend the duration of the project. When a resource is assigned to an activity, it is assigned for 100 percent of its availability unless the PM specifies otherwise.

It is often necessary to have significant excess resource capacity on projects because of the uncertainty that exists in all projects. Dealing with this issue is a major reason for the installation of a competent risk-management system.

Source: Meredith Jack R., Mantel Jr. Samuel J., Shafer Scott M., Sutton Margaret M. (2017), Project Management in Practice, John Wiley & Sons, Inc. 3th Edition.