People build many different types of project schedules. There are the massive checklist and the one liner varieties. I’ve seen them with Phases, Activities, Tasks, Sub-Tasks, Sub-sub-tasks and sub-sub-sub-tasks. Some have randomly bolded Milestones and still others fail to communicate anything.
For projects that span more than a couple of months and a handful of individuals, a deliverable-based project plan offers the best way to track and report on it. Over the next several entries we’ll look at:
- Definitions
- Work Breakdown Structure (WBS)
- Creating the Schedule
- When is enough too much?
Definitions
Since there are 3 words there are obviously 5 definitions that we need to review.
Deliverable — A pre-defined, tangible work product. This could be a report, document, web page, server upgrade or any other building block to your overall project. The size of a deliverable may depend on the size of your project, but typically they should be between 4 and 6 weeks in duration and spread evenly across the project length. There is another huge discussion we could have on acceptance management at this point.
Project — A temporary endeavor to produce a unique thing. That thing can be a product, service or some thing.
Schedule — A tool that defines what tasks are to be done, by whom and when. This is different than a Project Plan, which explains the need for the fourth definition.
Project Plan — A formally approved document that lays the ground rules for how the project will be managed. The schedule management is a part, but it also includes change management plan, risk management plan, resource management plan and other pieces to guide project execution and control.
A Deliverable-based Project Schedule then is a tool to define and track the delivery of a unique product or service. Ideally all of the activities and tasks within the project will roll up to be part of the one of the project’s deliverables. Any tasks, then, that is not part of a deliverable may be out of scope for the project.
Work Breakdown Structure (WBS)
The work breakdown structure is a planning tool that documents the breakdown of the project into deliverables. The is accomplished by taking the ultimate product of the project and breaking it into smaller, more manageable pieces until you have identified all the building blocks of the project. If that project were to create a new home page, the final deliverable would be the completed page.
Get the team involved in this exercise. As the project manager, you should facilitate and document these brainstorming sessions. The key is to know when to stop drilling. One indication is based on the fact that deliverables are nouns. If you start listing verbs you are at the activity and task level and should stop. There may be a couple of key tasks you want to jot down as a reminder but you aren’t looking to detail the tasks at this point.
There are multiple ways to capture this information. Initially the diagram method works well for a whiteboard session. Using a spreadsheet or document works, too. Although it may seem logical to use a project-scheduling tool it may be premature. The tool will prompt you for more information on each piece and distract you from getting the team’s ideas out.
From our example the deliverables identified were the Design, Format, Sections 1, 2, 3 and 4. Each of these can be defined and handed to an individual or team to create.
Creating the Schedule
There is a certain order to the creation of the schedule. The steps are Enter All Tasks, Determine Predecessors, Estimate the Work, Estimate Duration, Assign Resources and Add Constraints.
But before you begin putting tasks to schedule you need to decide the most appropriate way to lay out your schedule. The answer to this depends on what your reporting needs are. Set the schedule up so that it minimizes the effort needed to extract the information for status and other reporting.
The two main ways to put a deliverable-based project schedule together are (1) by Phase or (2) by . You can set up your schedule to switch between the two but it is far too complicated for this venue.
Phase structured schedules follow a standard development lifecycle (Requirements, Analysis, Development, Testing, UAT, Implementation and Support) and divide the main deliverables into pieces that are accomplished in each phase. From our example of the new Home Page, the deliverable for Section 1 would have requirements, analysis, development, testing and implementation. These pieces would be combined for each of the deliverables and called out in each phase. So the Requirements Phase would produce a Requirements Document that would have a part describing the needs of Section 1. The Requirements Document would, in fact, be a separate deliverable as would the Technical Design Document, Test Plans and other combined efforts.
structured schedules are strictly set up based on the deliverables identified in the WBS. Each deliverable would be self-contained with Requirements, Development, etc. baked into it. This method is also useful if the deliverables are really unrelated and have no overlapping phases. A simplistic example of this would be scheduling a conference. There are many aspects (ex. Location, Entertainment, Speakers, Catering) that run parallel and are self contained. Each of these deliverables would have milestones along the way to track progress against.
So, although it is tempting to start typing tasks down, it helps to take a look at the structure before you add the substance.
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 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:
- 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.
- 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.
- 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.
- 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.
Determine Predecessors
When you are setting up your project schedule, enter the logical predecessors. These are the tasks that legitimately belong linked, like creating the document before you review it and ordering the hardware before you receive and install it. Fake predecessors are based on resource availability or just a random decision because something has to go first. These have their place throughout the project, but not when you are initially setting up the schedule.
The more tasks you can link with predecessors the better your scheduling tool can… well… schedule.
Estimate the Work
You may have noticed we haven’t assigned any resources yet. As you estimate the work for each task, think in terms of 1 person doing the work on that task uninterrupted. So, even if you anticipate it would take 2 people a week to complete a document, set the Work value to 80 hrs. Later we will add the specific resources.
While you are assigning the Work, you are probably thinking of a certain skill level or specific individual. These thoughts influence the estimate. Because of this you should document them as estimating assumptions and include them as part of your proposed schedule. No, this isn’t a fancy word for excuses. If you are expecting an expert Java programmer and end up with a novice, your assumptions were wrong and therefore your estimate will be off. With your estimating assumptions outlined you can recognize the impact and make adjustments accordingly (i.e. more or different resources, additional training, obtain more time, etc.).
Estimate Duration
“Why are we worried about the duration before we add the resources? ” you might ask. Good question. The reason is productivity. It is easier to bake it in up front than to try and force it in later.
Mentally everyone knows that, unless you work overtime, an 8-hour task takes more than a day to complete. This is a factor of our productivity. Over the course of a year people are, at most, about 80% productive. This is based on the following calculation.
2080 hours in a year (52 weeks * 40 hours / week)
- 72 hours for holidays
- 80 hours vacation
- 48 hours sick time
- 24 hours training (non-project related)
- 52 hours status reporting (1 hour / week)
- 52 hours team meetings (1 hour / week)
- 88 hours interruption (1.5 hours / week)
1664 hours remaining (80%).
Obviously some people have more vacation, others don’t get sick, some have more training, etc. but in general this holds true. Without taking this into account at the task level you are setting yourself up to be late.
Some project managers do this by assigning all of their resources at 80% available. In MS Project there is a resource field named Max Units that they set to account for the productivity factor. Unless someone is assigned to my project only part time, I keep them at 100% available and set the duration of the individual tasks to account for the extra time. After all, they are still expected to work 100% of the time.
MS Project allows you use a custom field to automatically calculate the 80% rule. To do this use the Duration 1 field and create the formula [Work / 0.8]. This will calculate 8 hours as 1.25 days and 40 hours to be 6.25 days. If you place the Duration 1 column in the schedule beside Duration, you can easily copy and paste the estimated values into the Duration column.
You can also type it manually for each task using the 8 and 40-hour duration estimates as guidelines.
When we add multiple resources to a task, they are each assigned at 80% to it. They will still be assigned 40 hours of effort for the week, but the tasks will be spaced to account for interruptions, status reporting, overlapping tasks, etc.
The resulting durations are starting points. After you add resources and begin to use and refine your schedule you can make adjustments to them.
Assign Resources
Just do it. Make sure at least 1 resource is assigned to each task and turn them loose. There are 2 tips I would throw out, though.
First, as I mentioned before, assign the resources 100% to your project unless they are physically on a different project for a set amount of time. This gives your scheduling tool the most options when calculating assignments.
Second, enter dollar values for your resources. If you are not tracking the value of your project you are not effectively managing your resources. A blended rate doesn’t truly cut it. If everyone cost you the same for your project wouldn’t you always pick the best ones? Think about professional soccer. What if you could get David Beckham or Tom Cutting for the same price? Not really a question, eh? My point is that each resource brings different strengths and different expenses to the mix. If you have a budget you need to balance both sides of the equation.
Add Constraints
Once you have the resources entered the final step in setting up the plan is adding the constraints. This includes updating the scheduler’s calendar with holidays, filling in vacation time, setting target dates with milestones, etc.
Wow. You have officially created the first pass at a deliverable-based project schedule. Which, of course, means it is scheduled for twice as long as you have and three times the budget. Now you need to go back and balance the resources, adjust the dependencies and make modifications to bring it into alignment with reality. But, these are all great topics for another day.
Before we run off, though, let’s recap. The objective was to build a plan based on deliverables. All of the tasks role up into one of the deliverable. Because we applied the 80% productivity factor we have a realistic view of the length of the project. We even added cost to the resources.
Assuming you baseline the original schedule and track it with Actuals and Estimates to Complete you can accurately report progress and project completion for each deliverable. Add columns to display the baseline and planned values for the start / end dates and costs and you can tell if you are within schedule and budget. This is the information management needs to determine the health of your project.
When is enough too much? We touched briefly on this when we were breaking down the tasks. The level of detail and amount of tracking you perform should be comparable to the amount of benefit you gain from it. If no one cares if you finish on time or within budget, then why bother tracking? Enough becomes too much when the effort outweighs the benefit gained from doing it.
