6.7 Drafting the First Master Schedule

< Day Day Up >

After these negotiating sessions are complete, it is time for you to go back to your cubicle and put together the first real schedule. You still should be working with a pencil or little pieces of paper with "events" written on them that you can shuffle around your desk or white board. What we are about to do is draft the master schedule, which could also be called "mapping the critical path." When all is said and done, critical path is:

What you need to understand
What you have to schedule
What you want to manage

There may be thousands of tasks, but until you fashion the basic roadmap, your schedule will be twisted and gnarled, like a vine gone crazy on your Gantt chart. I maintain that using such programs add to, instead of reduce, the confusion that is normal at this point in the schedule's evolution.

Our first cut at a critical path for the vendor management project is given in Exhibit 7. Once again, we restricted the view to the main call center and data center to keep this as simple as possible.

Exhibit 7: Vendor Management Critical Path

March-April	May-June	July-Sept.	Oct.-Nov.	December
Complete SOW	Complete both facilities	Hire and train staff	Operational training and walk through	Open for business
Complete SOW	Data center infrastructures	Install and test applications	Operational training and walk through	Open for business

To borrow a concept from the data-networking lexicon, critical path is "logical," not "physical." This is the biggest cognitive challenge in scheduling - being able to recognize and handle the flow of a schedule as opposed to the literal, serial nature of tasks defined in a Gantt chart. This is another illustration of why you need to do all this preparatory work manually as opposed to using an automated planning tool. These automated planning tools are fine for documenting tasks and performing some calculations, but they do not lend themselves well to the process in which we are currently immersed.

Each block in Exhibit 7 is a project milestone. The critical path of a project is the journey from the first milestone to the last. Tasks that contribute to each milestone may have dates that are all over the place. For instance, the milestones for starting the call center and data center infrastructure actually begin at the same time the SOW milestone does. From a critical path perspective, however, the SOW must be completed before any other milestones are reached because the final details of the SOW will impact final headcount, for instance, or some data requirements for the applications.

Now that the critical path is identified, it is time to create the detailed project schedule. The first step is to reassemble the team leads and assign the "must start on" and "must complete by" dates. These "must" dates are driven by the milestones. Depending on the nature of each milestone, either or both of the "must" dates should be stipulated. In some cases, for example, either the "start by" or "complete by" date is compelling, while in other cases, both the beginning and ending dates are dictated by the critical path.

These sessions may turn into a negotiation. It definitely requires that everyone's cards get on the table, and timed deliverables are clearly defined and agreed upon. Until now, it is likely that team leads have been thinking along the lines of our first schedule that was driven by functional components as opposed to target state. Once we derived the critical path, however, it is now much more clear what has to be done, and when. It is now up to you to persuade each team lead to absorb these constraints and adjust their schedules accordingly.

You might be surprised by the position I am taking (i.e., suggesting that announcing critical path dates is a potentially controversial or contentious move). Remember, as project manager, it is your critical path, not theirs. Team leads may be working with constrained dates within their "sub-projects" that are milestones for them but not for you. The resulting discourse can be explained by as simple a fact as that they see the whole 9-month project time span as theirs within which they are free to do work as they see fit. That explains why it is up to you to do the analysis on the overall critical path, and then persuade them to dovetail their plans into your schedule. For instance, your analysis made it clear that the physical facilities and information technology (IT) infrastructure for the call center and data center must be complete by the end of Month Four, so that both staff hiring and training, and application installation and testing, can start at the beginning of Month Five.

This latter constraint has another implication as well. If the milestone is "Install and test applications," then the applications have to be ready for installation on Month Five, Day One, whether they are off the shelf, or developed in-house. That means that any procurement, custom coding, data migration, and test planning activities must be successfully completed by Day One, Month Five.

Therefore, the noise level may rise if the application team lead thought he or she had another few months, when user testing and training is set to begin, to get his or her house in order. Never for a moment assume that team leads do not think like that. They do, because they are:

Busy with many projects
Understaffed
Not the best time managers

In any event, they will be quite content to take the extra time if you do not make your scheduling requirements well known and insist on them.

< Day Day Up >