Preparing The Schedule

Preparing The Schedule

One of the things project managers are supposed to do is to meet the schedulewhich, of course, implies having a schedule to meet. The schedule is one of the two major parts of the project plan (the budget being the other), and, complex as it is, it is a by-product of the work that has already been done. Putting together a schedule requires a list of activities and their dependencies and durations. With these pieces and at least one fixed date, the schedule follows automatically.

This point bears repeating: A schedule is a consequence of planning; it is not primary. Some project management tools allow the user to move activities around, in effect creating their schedules directly. While this facility can have some limited use (see "Resource Leveling"), you should change schedules only by changing the activitieseither their durations or their dependencies. The activities determine the schedule, not the other way around.

Producing the schedule is a three-stage process. First, create the initial schedule (using project management software), based solely on the activities and their durations and dependencies. Second, assign resources to each activity. This will probably cause some problems, with some people being double-booked or worse. See "Resource Leveling" for ways to smooth out the schedule. Finally, you will need to align the schedule to the client's expectations and requirements (see "Aligning the Schedule"). All three steps are necessary to create a final schedule with which you can run the project.

Scheduling is an automatic function of project management software. Enter the activities, and the software will produce your schedule instantly. However, before you can understand it and begin to adjust it, there are some scheduling concepts that you will need. This section is concerned with those concepts.

The best presentation of a schedule is a Gantt chart, a chart that displays the activities, the critical path and slack times, and the project milestones.

Critical Path and Slack Time

Assume that there are two programs to be written. Program A requires four weeks and program B, three. Both can start at the same time, and integration will begin when both are finished.

Exhibit 4.18 shows a schedule for coding and integrating the two programs. Each character, dot, dash, or equal sign, represents one day.

From Exhibit 4.18 two things are apparent. First, the coding of program B can slide within the four-week period. It can start as early as September 1 or as late as September 8 without affecting the overall schedule. Since there are five days within which the coding of program B can slide, the activity is said to have five days slack time.

Second, if the project is to finish by October 13, program A must start on September 1. It cannot slip without affecting integration and therefore has zero slack time.

Activities with zero slack time are called critical because they cannot slip without affecting the overall project schedule. Critical activities that follow one another from the start to the end of the project form the project's critical path. Exhibit 4.19 shows the simple schedule with special symbols to indicate critical activities.

Every project has a critical path. Clearly, critical activities require the most attention, since the project schedule does not allow them to slip. Unfortunately, the critical path is fluid. As the project progresses, activities that were previously on the critical path may develop slack time, and other, noncritical activities can lose theirs. Exhibit 4.20 illustrates what can happen. Here, the coding of program B started on September 8, but slipped by a week. It therefore became critical, and the coding of program A, which started on time, acquired five days' slack. Situations such as this are commonplace, requiring the project manager to constantly review the critical path as activities are completed or rescheduled. In this example, the slippage in program B has caused the entire project to slip by one week.

Milestones

A milestone is a point in the project at which some clearly defined work will have been done. Many project plans have just two milestones, start and end, which means that the project manager will not know how the project is doing until it should have finished.

The purpose of milestones is to identify problems of two types: schedule slippages and functional deviations. A late milestone indicates a schedule slippage; a functional deviation occurs when the client says, "That's not what I wanted." Milestones provide a formal mechanism by which the project manager can become aware of both kinds of problems in time to fix them.

Milestones come in two flavors, external and internal. External milestones involve the client and some form of approval, whereas internal milestones are restricted to the project team. There is usually an external milestone for each deliverable or set of deliverables. Internal milestones mark such points as the completion of a program or the planning for a workshop, where the outputs will not be formally delivered to the client. To ensure that you can judge when milestones have been met, they must require the delivery, in final form, of some concrete project output. Note the stipulation, "in final form." A milestone that requires, for example, that a document be 50 percent complete is useless; nobody can judge percentage completion.

Milestones involve handovers: from the project to the client, from team members to other team members, or from one activity to the next. A milestone is met when whatever is being handed over is ready. No further time will be spent on it. A conditional handover "This is about 95 percent done, but you can start on it now"does not count. The milestone is met only when the item is 100 percent complete. If you are using a time recording system in which team members enter their time against specific activities, you can define "complete" as meaning that the activity will be closed and no more time can be booked against it. (It may be argued that program code delivered to an integration team is not complete, since integration and system test will identify changes that need to be made. But those changes are properly part of integration. When the WBS activity "Code and unit test" is finished, the activity is complete, even if other activities will modify the results.)

Milestones should be liberally distributed throughout the project. A good rule of thumb is to plan at least one external and one internal milestone per month. The more frequent they are, the earlier you will become aware of problems. Exhibit 4.21 shows the sample project schedule with milestones attached.

The Role of Project Management Software

It can be argued that the most important feature of project management software is its ability to produce a schedule. Simply enter the activity data and the Gantt chart automatically appears. In fact, many packages allow you to build the schedule graphically.

Software packages differ in their power, and also in their ease of use. For example, most packages will schedule noncritical activities to start as soon as they can, so that the slack time follows the activity. Many packages will allow you to specify that the activity should start as late as it can, so that the slack time precedes the  activity, but this involves extra work and limits the ability of the software to adjust the schedule as things change.

Some of the more powerful packages even allow you to define the profile of work within an activity. For example, assume that you have a five-day activity that will be done over ten days. You can specify that two days of the activity will be done on the first two days, nothing will be done on the next three; the next four will be half-days, followed by one full day. If you are a perfectionist, this type of facility is as dangerous as an addictive drug. Avoid this level of planning. You do not have the time, and whatever you plan will not be reflected in how the work is really carried out.

With feature-rich software tools, it is tempting to fine-tune the work products. This is defensible in such areas as sales presentations or user manuals, but project plans are never followed precisely; the best aim to hit the milestones. The more detailed your plan, the less likely it is that it will be followed. If you say to a team member, ''Here's a two-week activity. I expect it to be done in two weeks," your expectation is clear, and it is up to the person to plan and execute the task. But if you say, "Here's a two-week activity and a profile of the number of hours I expect you to work on it each day," not only have you usurped the person's professional right to plan the work, but you have guaranteed that your plan will not be followed.

When you plan, resist any urge to finely hone how the activities will be done. Use your meticulousness to make sure that you have the activities identified and properly defined.

What If?

Your Clients Insists on Having Fewer External Milestones.

You will be tempted to comply. After all, external milestones are at best nuisances and at worst disasters. However, their purpose is to reassure both the client and you that the project is on track. Without the discipline of having to meet them, you risk that the project will slip and that you will deviate functionally from the plan.

Actions

Determine why the client is opposed to milestones. Most clients welcome them as a chance to keep current on the state of the project.

The most common objection is the demands that milestones make on client staff.

Try to negotiate some form of review or checkpoint for each of your milestones. Even if the review is cursory, it is better than having no contact with the client.

Manage the project as if the milestones were in place and appoint yourself as the client representative.