The Project Manager’s Corner: Scheduling TMT II
Gary Sanders, TMT Project Manager

March 2007

Building the project's schedule really is building your plan. There are generally many ways to carry out a complex project. Building the schedule is a selection of one way to accomplish the project's goals. And it is your way. Build it well, build it simply, and build it with resilience, and it will serve you well.

Last month I described the basic starting points and requirements for a good project schedule. A schedule must be designed by experienced experts who will be responsible for delivering the results of their parts of the schedule. This is schedule ownership. A schedule must include every element of the work in the project organized around the project deliverables into a Work Breakdown Structure (WBS). Finally, a project schedule starts with a definition of external milestones to be heeded (when funding is available, when the project must be completed, etc.) and an architecture for the working plan and schedule. This architecture flows down to the designers from the Project Manager.

Each lead engineer or scientist, responsible for a deliverable section of the WBS, designs a strategy to accomplish that delivery. This may consist of steps such as requirements definition, specification development, conceptual design, research and development, preliminary design, prototyping, final design, procurement, fabrication, assembly, integration and verification. This is just one example of the steps that might lead to a completed delivery. The designer then estimates the detailed materials requirements for each step. The labor is also estimated. This may include "non-touch" labor such as engineering, design, inspection and administration. It may include "touch labor" in the fabrication and assembly. For each of these steps, the duration of the task is estimated and the preceding tasks and the succeeding tasks are defined. What has to be completed before a task can start? What can start and proceed in parallel? And so on.

All of these judgments are entered into a scheduling database associated with a schedule software package. The designer has to be careful not to include unnecessary information such as fixing dates that may be based on unwarranted assumptions. If done right, the wizardry in the schedule software can be exploited. Enter the right information, the right logic and only what is needed to define the envisioned way to get the job done, and the wizardry will yield things like the shortest time to accomplish the tasks, the free slack in the schedule, or what parts of the schedule have no slack and are critical, or worse, what tasks cannot be accomplished in the desired timeframe.

I have called this software a wizard. But it is just a robot, a program. The wizardry is that in a schedule with 10,000 tasks, all of these calculations can be performed quickly and the results can be displayed. Logical links between tasks can be altered and the new scenario pops out. "What ifs" in complex logical schedule networks can be tried out.

The separate parts of the larger project schedule can be integrated into one schedule file and the logic can be run again. In this step, the Project Manager gets to play out the "what if" exercises. Most attention is on the critical schedule paths where one day of slippage results in the end of the project slipping irrevocably by a day. The project team designs ways to shorten the critical paths or devises a different logic, if possible.

Once the Project Manager and lead designers are satisfied that they have optimized the schedule, it can be established as the basis for the project's plan. It can be combined with the cost estimate to define a baseline of time-phased accomplishments and expenditures leading to the project result. And the project can measure progress against this plan through the course of the project. When you are off your plan, the information stares right back at you and you know it. This is how modern projects prepare themselves for successful outcomes.