By default, Project creates resource-driven tasks that are referred to as fixed-unit tasks. Here's a simple example. You have to plant a tree. One person needs two hours to plant a tree. If you add another person (another resource), together they need only one hour to complete the task. That is, two resources, each putting in an hour of effort, complete the two hours of work in only one hour. With resource-driven scheduling, when you add resources, the task duration becomes shorter; if you take away resources, the task takes longer to complete. And, on the flip side, the resource assignments to a task don't change when the work increases or decreases. By default, each task that you create in Project is a resource-driven, fixed-unit task type.
The reduction of time required on a resource-driven task is strictly a mathematical calculation in Project. For example, ten people get work done in one-tenth the time of one person. However, whenever two or more people work on a task, the time savings are seldom so straightforward. You must also factor in the time for those people to communicate, miscommunicate, hold meetings, and so on.
To pad or not to pad?
Although most people agree that delays are inevitable and that you should allow for them, people who schedule projects accommodate these delays in various ways.
Some schedulers build in extra time at the task level, adding a day or two to each task's duration — just in case. Unfortunately, padding each task may leave you with an impossibly long schedule, and it may suggest to your boss that you're not very efficient. Why should it take two days to run a three-hour test? It doesn't — but because you know that setting up the test parameters properly the first time is an error-prone process, you allow a couple of workdays to complete the testing. Just make sure that your boss understands that you're building a worst-case scenario; when you bring the project in early, he or she will be glad to share the praise.
Some project managers add one long task, maybe two weeks or so in duration, at the end of the schedule, and they name it something like Critical Issues Resolution Period. This task acts as a placeholder that covers you if individual tasks run late. This approach can help you see how the overall time left for delays is being used up as the project proceeds. For example, if the final two-week task is running a week late because of earlier delays, you know that you've eaten up half of the slack that the task represents.
Or, you can build a schedule with best-case timing. Then you can document any problems and delays that occur, and request additional time as needed. In the case of a project that you must complete quickly, you may need to work this way. However, best-case timing sets you up for potential missed deadlines.
Which approach should you use? Possibly a combination. For example, try building a best-case schedule. If the completion date is one week earlier than your deadline, by all means add a little time to the tasks that are most likely to encounter problems, such as those that are performed by outside vendors.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.