Assigning Resources to Tasks
I have already said that the first step in developing a schedule is to assume that you have unlimited resources, because this is the best situation you can ever assume, and if you can’t meet your project completion date with an unlimited resource schedule, you may as well know it early. However, once you have determined that the end date can somehow be met, you now must see whether your unlimited resource assumption has overloaded your available resources.
Normally you will find that you have people double- and triple-scheduled, which clearly won’t work. These kinds of resource overloads can be resolved only by using computer software, except for very simple schedules. This is where the software really excels, and yet estimates are that only a few percent of all the people who purchase software actually use it to level resources.
Consider the small schedule in Figure 7-5. It contains only four tasks. Two are critical, and two have float. Task A requires two workers if it is to be completed in three weeks, and tasks B and C need one person each. When it comes time to do the project, however, you find that there are only three workers available. How did this happen?
Figure 7-5. Schedule with resources overloaded.
It is possible that no more than three people were ever available, but because you followed the rule to schedule in parallel tasks that could logically be done in parallel, you inevitably overloaded your people. It is also possible that, when the plan was constructed, four workers were available but that one has since been assigned to another job that has priority over yours.
Whatever the reason, this schedule won’t work unless something is changed. There are a number of possibilities. There are three areas to examine. You should first see whether any task has enough float to allow it to be delayed until resources become available. In this particular example, it turns out that this is possible. The solution is shown in Figure 7-6.
Figure 7-6. Schedule using float to level resources.
Of course, this solution is a nice textbook example that just happens to work out. It is never so easy in a real project. Notice that task C has enough float that it can slide over and wait until activity B is finished. But what usually happens is that task C runs out of float before B is completed. Also, assume that task D needs three people, rather than two. As you can see, this complicates the situation considerably. This is shown in Figure 7-7.
Figure 7-7. Schedule with inadequate float on C to permit leveling.
Since this is the typical situation, we must be prepared to handle it. There are two more places to look for help. The first is the functional relationship among the variables:
| C = f(P, T, S) |
You should ask whether you can reduce scope, change the time limit, or reduce performance. Usually performance is not negotiable, but the others may be. For example, sometimes you can reduce scope, and the project deliverable will still be acceptable to the client. Of course, if you can get another person for a short time, you won’t have to consider reducing scope or performance. So you go shopping.
You ask the manager who “owns” the resources whether she can provide another person. She says sadly that she cannot and that she was even considering trying to take back another of the three she has already given you. Somehow you convince her not to do this. You then ask the project sponsor if it is okay to reduce scope. It is not.
It is also not okay to reduce performance. Nor can you find a contract employee in time to do the job. You are between a rock and a hard place. So you now ask whether there is another process that could be used to do the work. For example, if you can spray paint a wall instead of using a roller, it may go much faster.
Suppose you try this and again you come up empty-handed. You decide the only thing left to do is resign your job. You never really wanted to be a project manager, anyway. But wait. Perhaps there is something else you can do.
Think back to what I said earlier. You use up all the float on C, and it is now a critical-path task. When you tell your software to level resources, it wants to know whether you want to schedule within the available float (or slack, as it is also called). If you say yes, as soon as a task runs out of float, it won’t move over any further. This is also called time-critical resource leveling, because time is of the essence for your project. (It always is!)
However, suppose you answer “no” to the question, “Do you want to level within the available slack?” In this case, you are telling the software to continue sliding tasks over until resources become available, even if it means slipping the end date. (This is called resource-critical leveling.) When you try this with our example schedule, you arrive at the solution shown in Figure 7-8. Not bad, unless you can’t live with the slip.
Figure 7-8. Schedule under resource-critical conditions.
In fact, sometimes the slip is so bad that it seems almost ridiculous. Your project was originally going to end in December of the current year. Now the software says it is so starved for resources that it will end in the year 2013! Ridiculous! What good is a schedule that goes out that far?
It can be used to bring the issue to everyone’s attention. It shows the impact of inadequate resources and forces a trade-off as described earlier—that is, if everyone believes your schedule in the first place. I have just had an experience with a fellow who said that he didn’t believe the schedules in the first place, because he thought they were always unrealistic, so an unrealistic schedule subjected to fancy calculations didn’t prove anything to him.
I’m sure that’s true. However, if people are willing to accept the limitations of what we are doing when we plan a project, this is at least a way of showing the limitations you face. Everyone must understand that estimating is guessing, as is true of market and weather forecasting, neither of which has a stellar record. Moreover, all activities are subject to variation, as I have pointed out. If people don’t understand this, then I suggest you turn in your project manager’s hat for a better job.
Resource Availability
A major factor in dealing with resource allocation is the availability of each person to do project work. One guideline that industrial engineers follow is that no person is available to work more than 80 percent of the time. Considering an eight-hour day, that means 6.4 hours a day available for work, and prudence says to just make it six hours. The 20 percent lost availability goes to three factors called PFD. P means personal—every individual must take breaks. F is for fatigue—you lose productive time as people get tired. And D means delays—people lose time waiting for inputs from others, supplies, or instructions on what to do.
Experience shows, however, that the only people who are available to work even 80 percent of the time are those whose jobs tie them to their workstations. This is true for factory workers and others who do routine jobs like processing insurance claims (and even these people move around). With knowledge workers, you never get 80 percent of a day in productive work. The figure is usually closer to 50 percent, and it may be lower! One company that I know of did a time study in which people logged their time every hour for two weeks, and they found that project work accounted for only 25 percent of their time. The rest went to meetings, nonproject work that had to be done, old jobs that were finished long ago but came back to the person who originally worked on them, work on budgets for the next year, customer support, and on and on.
Most software programs allow you to specify the number of working hours needed for a task and the percentage of a day that a person will work on the task; the software then translates that into calendar time. So, as an example, if a person is working on your project only half time and the task she is doing is supposed to take twenty hours of actual working time, then it will be a week (or more) before she finishes it.
It is especially important that you know the availability of people to do project work, or you will produce schedules that are worse than useless. I say worse, because they will be misleadingly short, and they will wreak havoc with your organization. Do a time study to determine the number, then use it. And if people don’t like the fact that a lot of time is being lost to nonproject activities, then correct the problem by removing those disruptive activities.
The usual solution is that people must work overtime to get their project work done, because of all the disruptions that occur during the day. The problem is that studies have found that overtime has a very negative impact on productivity. So it is a losing battle. Short-term overtime is fine, but long spans just get organizations into trouble.
Key Points to Remember
|