March 5, 2007 – Deliverable-based Project Schedules: Fixed Work Sidebar

Before we move on to discussing duration and adding resources there is a side step we need to take to discuss different task types. When you are developing your project schedule, most tasks should be set as Fixed Work. As effort is expended or added to the task this allows the tool to re-calculate the duration and show the new estimated completion date.

In MS Project there are 3 types of tasks: Fixed Duration, Fixed Units and Fixed Work. I’m sure other scheduling tools have similar terms. Units (U) refers to the percent a resource is assigned to the task (the productivity factor discussed above). Duration (D) is the number of days a task takes to complete. Work (W) is the amount of effort expended or to be expended on the task. The formula for calculating Duration is D = W / U (ex. 8 hours / 80% = 10 hours = 1.25 days). This equation and variables are used to determine when the task will complete.

“Fixing” one of these variables tells the tool not to allow it to change. If Duration is fixed and you add more Work, the Units will increase to balance the equation. In order to complete a 16-hour task in 1 day the resource will need to be assigned 200%. If Units are fixed at 100%, reducing the Duration of a 16-hour task from 2 days to 1 day will force the Work to 8 hours in order to maintain the equation. Neither one of these options helps you track progress.

Selecting Fixed Work is more realistic. If you have an 8-hour task scheduled for 1 day and you decide to extend it to 2 days you want the Work to remain at 8 hours, not increase to 16. The time you allowed for the completion of the task increased, not the effort to do it.

This is a big topic from project managers trying to figure out what MS Project is doing to them. They change a duration or end date and suddenly the estimated hours either explode or shrink to nothing. Very frustrating.

On the flip side, there are tasks that should be Fixed Duration. These tasks include support, status reporting and others that are based on the calendar rather than the effort. Although I have never used it, there is probably a good application for Fixed Units. If you have an example, add a comment to this blog and I’ll pass it on.

The task type becomes important as we move to estimating the duration.

March 1, 2007 – Deliverable-based Project Schedules: Part 4

Whether you select a Product or Phase structure, the steps to building a deliverable-based schedule remain the same.

Enter All Tasks. The next step is to fill in all of the tasks associated with the identified list of deliverables. Those deliverables may be the list from the WBS or, like the Phase structured schedule; it may include the separate building blocks (i.e. Requirements Document, etc.).

Drill down to the task level for each deliverables. You can use the WBS or other tool, but eventually you will need to switch to the scheduling tool. Although we are not ready to assign effort to the tasks, the general rule of thumb for the size of a task is between 4 and 80 hours per resources. Anything less than 4 hours is a pain to track and doesn’t offer much payback for the effort. Anything greater than 80 hours is hard to grasp. We are pretty good at understanding and estimating things that can be done in 2 uninterrupted weeks (= 80 hrs). Anything larger becomes difficult to estimate and should be broken into smaller pieces.

Each deliverable should be reviewed with the group or at least the individual that will approve it so include the task Review Deliverable and the milestone Obtain Approval for each one. (Note: a milestone is a task with zero hours and zero duration used to mark an important event or accomplishment.)

Add another deliverable at the bottom of the schedule for Project Management. The tasks under it should include Project Status Reporting, Individual Status Reporting & Time Keeping, Team Meetings, Client Meetings and Management. Some people track project management time as part of each deliverable but it is easier and cleaner to pull it out as a separate item.

The ultimate goal is to have all of the tasks neatly tucked in as sub-tasks under one of the deliverables. Collectively the deliverables constitute the whole of your project scope and anything not part of a deliverable would then be out of scope. However, as you complete your list of tasks, there will be some that don’t seem to fit. There are several possible reasons for this:
1. A deliverable has been missed. Something needs to be added to the scope of the project. If the scope has been agreed to you may need a change request to add to it.
2. The task might have been dumped on you when it should really be out of scope. This might require some push back to define your responsibilities.
3. It may be a legitimate task but the responsibility of another group. You may want to track the completion of the task but not the effort.
4. The process or lifecycle may require the task (ex. creating internal assessment documents, updating review committee checklists, etc.). Since the deliverable is a product of the process, these types of tasks can be incorporated into its creation.
You may have to get a little creative with some tasks, but to effectively use the project schedule to track and report progress you don’t want a rambling task list with no structure.