IS IT BLACKJACK?
We'll start this month's column off with a trick question. Let's say that you play a certain game 30 times. Thirteen times, you come up with 17. Nine times you come up with 16. Six times you come up with 18. Once you get a 20, and once you get a 15. What game are you playing?
Sounds a bit like Blackjack, doesn't it? But it's not! How about Roulette? Wrong again! I know…it?s the Resource leveling game. Right on! These are the actual results that I obtained from a resource leveling test.
They say two things are certain in life: death and taxes. When it comes to computer-based resource leveling there are also a couple of things that you can bet on. First, don't expect to obtain an optimum solution. Second, you will rarely obtain the same solution, even within the same program. And, we might add, there are no assurances that the higher-priced or more fictionally endowed products will provide shorter or more consistent results.
That is not to assume that the software designers are either lax or inept regarding the resource leveling function. On the contrary, a lot of effort has gone into most of these products to support effective resource scheduling, and excellent resource leveling capabilities have been available for over 20 years. The problem is primarily one of tradeoffs, and of real-world considerations.
It may very well be possible to generate an optimized solution. However, you may not wish to pay the price for executing such routines. First, it would tend to require extensive computer resources. Second, it would require so many iterations that it would slow down the process to an unacceptable level. But even more important, it would require the user to make critical and unnecessary decisions long before they are needed, and then to relinquish control of this complex process to the computer. And because conditions change as the project is being scheduled and executed, the decisions made at the beginning may no longer be appropriate down the line. User intervention may be required to produce the right resource schedule.
The issue here is that there are usually sensitive criteria that must be considered when deciding which task should get the limited resources. In the first place, it would be tedious to define all of these decision factors to the computer (after all we are already protesting the amount of detail that must be entered to produce a decent project model). But more to the point, it would be even more difficult, and unrealistic, to make these determinations very far in advance of the period of work execution.
There are definite benefits to be gained from employing computerized resource leveling routines, especially to get the big picture. But if we want to be realistic, relative to detailed resource scheduling, we will need to take a short-term prospective, and fully interact with the computer.
Harvey A. Levine, principal, the Project Knowledge Group (21 Pine Ridge, Saratoga Springs, NY 12866) has been a practitioner of project management for over 30 years, primarily with General Electric Company, and is a past chairman of PMI. Mr. Levine has been adjunct professor of project management at Rensselaer Polytechnic Institute, Troy, NY, and is the author of ProjectManagement Using Microcomputers as well as numerous amides.
I have been researching this subject for quite some time, and the more involved in it I get the more I find it Byzantine and intriguing. With all my data analysis and recommendations, it is too complex to cover in a single column, so we will spread it over two issues. This month, we'll look at some of the issues and problems involving resource leveling. We'll study the resource leveling process itself, and examine the results of 13 products on some test projects. In the July issue, we will look at the resource scheduling attributes and calculations of these products. Then we will explore the practical uses of resource scheduling.
WHEEL OF MISFORTUNE
The Resource Leveling Process
Resource leveling is certainly not new, and neither are the issues pertaining to the best and practical methods to be used. I was recently browsing through a 1981 P/2 manual (PROJECT/2 from Project Software & Development, Inc.). P/2, then running on IBM mainframes and the DEC VAX, offered powerful resource scheduling options. The user had the choice of four leveling methods, two parallel and two serial modes.
The parallel mode, which is seldom used today, will usually produce a shorter duration resource-constrained schedule. The parallel method looks at the project by time periods. For each time period, it looks at all of the tasks that are scheduled to be worked and assigns resources according to the user preferred ranking criteria. Activities that cannot be scheduled in that time period, due to insufficient resources, are postponed until a later time period. Then the system moves to the next time period and reconsiders the next set of tasks that are ready to be worked.
The serial mode considers the project on an activity-by-activity basis, and generally takes less time to process. For any particular time period, it starts out as above. However, when it cannot schedule an activity on its earliest start period, it looks for the first available period (resource availability) and immediately schedules that activity at that future time. It is possible, therefore, that when the system gets to a later time period, that one or more tasks may already be scheduled, before checking for the best choice or closest support of the ranking criteria. We will find that the serial method of resource leveling is almost universally employed in today's popular products.
With either method, the user is often allowed to identify a set of Ranking Factors (sometimes called ordering, prioritization, or heuristics). These are conditions that will influence the selection of tasks where some tasks must be delayed. Common factors are date values (ES, EF, LS, LF), float values, task duration, assigned priorities, task IDs, and user sort sequences. During resource leveling, the system first looks at the precedence and imposed date results (the CPM schedule) and then the ranking factors. There is no sure way of telling (in advance) which ranking criteria will produce the shorter or smoother schedule. (Those 30 seemingly random numbers mentioned in the opening paragraph came from running the same test project on 13 programs. Those programs that allowed the setting of a preferred ranking criteria gave several different answers, depending on that setting.) Experimentation, with varied ranking factors, is necessary in order to get close to the best solution. In addition, in the serial method, the ranking criteria is used only when a task is first considered for resource scheduling. The tasks are not reordered during the process.
Even with the multiple options for advanced resource leveling, available in P/2, PSDI advised in that 1981 document that the system is not designed to achieve the optimal results. In addition to the demand on computer resources, they suggested that the process needs to be timely and dynamic. Today, almost 13 years later, that reasoning is still valid, and with the universal use of the serial method, optimization cannot be expected.
Within this column, we cannot hope to resolve at this time all of the issues of efficient and effective resource leveling. We will endeavor, however, to make our readers more aware of the realities of resource leveling, and of the capabilities and limitations of the popular project management software products, with regard to resource leveling. Perhaps as a byproduct, we will keep the heat on ourselves and the software developers to make resource leveling a more useful function than it is today.
PLACE YOUR BETS: A Review of Resource Leveling Results
When we wrap this subject up in the July issue, we'll present the results of resource leveling tests performed on 13 project management software products. It is startling to realize the range of answers obtained, and the effect on project duration and resource utilization. Here is an overview.
Test model A (mentioned earlier), consists of 12 resource-loaded tasks, requiring either one or two units of a single resource. There is a total of 30 person-days of effort. The unleveled CPM is 11 days. Leveling, with two units of the resource available, should be able to produce a 15-day schedule. Yet, in 30 trials (without invoking splitting options, where available), only one iteration produced the 15-day result. Others ranged from 16 to 20 days. (Splitting options, available on six of the programs, produced schedules of 15 and 16 days. However, activity splitting was not necessary to obtain a 15-day result via manual leveling.)
Let's say that you are the project or resource manager on this job. Would you be willing to pay for 40 person-days of effort (20 days for two people) when you could get the job done with 30 person-days of effort?
Test model B consists of seven tasks and two resources. Unleveled, the CPM duration is four weeks, but there is a resource overload in week one. After resource leveling, the result should still be four weeks, as there is room to move one task within the available float. Yet several products delayed more than one task, underutilizing available resources in week one, and adding one week to the project duration.
In both test cases, it was possible to obtain the optimal solution manually, following a set of predefine ordering rules. Yet, the process of serial leveling (routines to immediately place tasks that are ready to be worked), often resulted in periods of resource underutilization that were unnecessary.
Test model C is the most revealing. It consists of only three tasks and one resource. Only two of the tasks require the resource. Depending on the ranking factors used, resource leveling can add either one day or five months to the schedule. For those programs that offer a choice of ranking factors, it is up to the user to determine which method of prioritization will produce the better result.
And don't look for help from the user manuals and other documentation on resource leveling ranking factors. In one manual, I read that Late Start (LS) will usually produce the shortest resource constrained schedule. Another source suggested that least Total Float (TF) should be your first try. Yet, in my experiments, the best results in test model A were obtained using Early Start (ES) and test model C worked best with Late Finish (LF) or least (shortest) duration.
Tune in again in July for the details on the 13 products, including a discussion of options that affect resource leveling.
SPIN IT AGAIN, MY NUMBER'S COMIN' UP
This month, we have talked about how resource leveling works and where its limitations can lead you down the wrong path. In July, we will look at practical uses of resource scheduling. Here are some things that you should find interesting:
Long-term/short-term. Practical resource scheduling is best achieved via a balance of long-term resource aggregation (analysis of predicted resource loads), and short-term resource leveling (possibly with user intervention). We Will outline a recommendation that should suit most applications.
Use of total and free float. Have you been taught that we use CPM scheduling so that we can obtain a measure of float? And that we use these float values to help us make decisions on priorities, and to analyze project schedule risk? Get ready to learn all over again. When we use resource leveling, we can forget about using the resultant float values as a time management tool. I'll explain why in July.
Use of accomplishment value in place of float. There are other techniques available to help analyze project progress. Accomplishment value (based on popular earned value protocols) can be used, even without using the cost management features of your project management software.
A design for optimized resource scheduling. Is there a better way of doing resource scheduling using project management software? We will share some ideas on this subject and invite user and vendor feedback. Hopefully the PMI membership, through this forum on project management software, will help to influence the design of practical scheduling tools for the practitioner.
Whoops! Gotta run. They're opening up a new Blackjack table.