In training sessions, my students traditionally have a tough time grasping the concept of task types and how they may be applied in the real world. I often get the question of “Which task type would you recommend for ‘XYZ’?” To which the response is almost always, “It depends.” In this post, I figured I’d spend a little time talking about my own personal practices, and see if that sheds some light on task type usage patterns.
First off, what are the available task types?
- Fixed Duration
- Fixed Work
- Fixed Units
These task types play the part of variables in the Duration X Units = Work equation that Microsoft Project uses as the basis for a fair number of scheduling calculations. (Note that the Duration X Units = Work equation should probably be more accurately depicted as Duration X Units (X Person Hours Per Day) = Work.)
The general way to identify which task type you would like to use is to ask yourself the question, “Which of those three variables, Duration, Units, or Work, do I know at this point? Which variable will not change?” That is the variable that should be fixed.
Planning the Project
Great in theory, but how does that work in practice? Let’s take an IT project as an example. As a consultant, I am often called upon to decompose the project scope and to identify the tasks required to complete the scope. Since work frequently on similar projects, i.e. Project Server deployments, I might start with a schedule template that already lists the tasks and dependencies.
So my first goal is to work through that schedule list and attach work estimates. At this point, I am not attaching duration or calculating a real schedule. All I am doing is working through the list, and adding an estimate of work to each task….80 hours here, 20 hours there, 4 hours there. Now here’s the trick. Unless I uncover something new during the planning/estimating process, those hours will not change. They probably will change when I get into the actual execution of the project, but we haven’t gotten there yet. Hence, I will set those tasks to Fixed Work. I don’t want those estimates to change.
Once I’ve gone through a first cut of the schedule and attached hours to the tasks – and set the tasks to Fixed Work, then I’ll go through and play with either the units of allocation of a resource or more likely the duration of a task. I run through the project and start assessing duration for each of the activities. Since work is fixed, and I am editing duration, the units field will recalculate – which is what I want. My duration estimates are usually based on client availability estimates, i.e. I will assume that requirements gathering may take longer or shorter depending on the number of people involved in defining requirements or the complexity of the project.
Again though, unless I uncover something new during this process, the work estimates do not change.
Tracking the Project
Once I’ve reviewed my estimates, added calendars and constraints, then smoothed the overallocations, I tend to flip all of my tasks from Fixed Work to Fixed Units. “Why?” you ask. Well, when you get into execution, that’s when I am pretty sure that my work estimates will change routinely. Similarly, I am pretty sure that my units will stay pretty stable – or at least they will do so for future estimates. Past estimates will be overridden by the actual hours entered in the system.
So every week, I fill in my timesheet, and my actual hours get transferred back to my plan. If I book more hours than I expected, units are fixed, and the duration comes in. If as happens more often, I book less hours than expected, units are still fixed, and the duration gets pushed out. If, based on partial completion, I change my work estimate, again units are fixed, and the duration is recalculated.
Hence, generally, in an IT environment that tracks hours, I would recommend using Fixed Units task.
So there you have it…..a long winded explanation of why “It depends” is a valid answer. My recommendation for this specific scenario would be Fixed Work during the estimating and Fixed Units during the execution of the project.