Finalizing the Project Schedule

The last schedule was built by the JPPS planning team. At that point, you knew the core team by name but the full project team by position titles only. Now that you have all of the named members of the project team, you have all of the information you need to finalize the project schedule. Team-member availability must be factored into the schedule. Such things as other project schedule commitments and non-project time commitments (department meetings, training, work week schedules, previously approved vacations, and so on) will impact the current project schedule.

Micro-level planning is another step in the decomposition of the tasks that are assigned to an individual. It involves a decomposition to what I call subtasks. In some cases, these subtasks may be a very simple to-do list or, in more complex situations, they might appear as a very small project network. Remember that you are dealing with tasks that have met the six WBS completion criteria and are therefore relatively simple tasks of short duration.

Micro-level project planning begins with the lowest-level task defined in the WBS. Because it appears in the WBS, it will have management oversight by the project manager. The responsibility for completing this task within a defined window of time will be assigned to a task manager (or team leader, if you prefer). The task may be simple enough that all of the work of completing it is done by the task manager. In more complex situations, a small team assigned to the task manager will actually complete the work of the task. I use the word subteam in the discussion that follows, but you should keep in mind that the team may be only one person, the task manager.

The first thing the subteam must do is to continue the decomposition that was done in building the WBS, but this decomposition will be below the task level. As indicated previously, the subtasks might be nothing more than a simple to-do list that is executed in a linear fashion. More complex tasks will actually generate a task network diagram composed of tasks and their dependency relationships. Recall that the task must meet the completeness criteria discussed in Chapter 5. These tasks will each be less than two weeks' duration, so the subtasks that make them up will be of shorter duration. The decomposition should be fairly simple and result in tasks of one to three days' duration. I would be surprised if it took more than 10 subtasks to define the work of the task.

Using a project management software package to create the micro-level plan and its accompanying schedule is overkill. My suggestion is that you define the tasks and their dependency relationships, and schedule them on a whiteboard using sticky notes and marking pens. Figure 6-5 is an example of what that whiteboard display might look like. The task consists of seven subtasks that are shown in the upper portion of the figure along with their dependencies. The lower portion of the figure shows the time-scaled schedule for the three members of the subteam. The shaded areas of the schedule are non-workdays and days when a resource is not available. Half-day time segments are the lowest level of granularity used.

Figure 6-5: Example of a task dependency diagram and time-scaled resource schedule

This task is typical of others in the project plan. It is simple enough that all of the work can be done at the whiteboard. Updating is very simple. There is no need for software support, which simply adds management overhead with little return on the investment of time expended to capture and manage it.

In the next section, you learn how to develop and use work packages. What you have done so far is decompose a task into subtasks — you have a list of things that have to be done in order to complete the task. The work package describes exactly how you are going to accomplish the task through the identified subtasks. In other words, it is a mini-plan for your task.