Workflow for Modeling a Schedule

http://www.alexsbrown.com/model-tough-sched.html

• Workflow for Modeling a Schedule

  By breaking schedule development into well-defined, discrete processes, the PMBOK suggests a workflow for building a schedule. In real life, building a schedule is often an iterative process, starting with a small, basic schedule, and building on it by adding phases or groups of tasks. Whether performed as a single pass or multiple iterations, experienced project managers perform these steps:

1. Build a Work Breakdown Structure (WBS)
2. Decompose the WBS into concrete activities
3. Define the sequence of activities (dependencies, predecessors, and successors)
4. Estimate task duration
5. Estimate task cost
6. Assign resources
7. Adjust cost and duration estimates based upon assigned resources
8. Perform initial resource leveling
9. Optimize the schedule

The final step, “optimize”, may include changes to all of the information entered earlier. Activities might be grouped together, activities might be decomposed, resource assignments may change, and estimates of cost or duration may grow or shrink.

During this “optimization” step, the manager probes the schedule, assessing the quality of the model of the schedule. Changing assignments and estimates should adjust the overall end-date with minimal effort. The better the model, the easier it is to optimize. The more fragile the schedule, the more unpredictable changes occur with each adjustment.

Often modern schedules are tightly constrained. They are designed to produce the maximum output, just-in-time, for a minimum budget. Optimizing tightly constrained schedules is difficult. Allow extra time for creating such schedules.

In the rush to produce a schedule, it is tempting to bypass critical steps. For instance, if a task “must” begin on a certain date, it is tempting to ignore activity sequencing for any predecessor to that task and to simply set a start date for it. If the manager shortcuts the process, the software cannot warn the manager of scheduling conflicts.

Some Tough Scheduling Problems

Resource Leveling

One of the enormous benefits of scheduling software is that it provides the manager with multiple, synchronized views of the project. Gantt charts are effective for communicating dates and network diagrams are effective for communicating dependencies. In the 1960s and 1970s, managers who used critical-path techniques had to manually draw and update these diagrams by hand. Any changes to the project scope meant updates to multiple diagrams, charts and lists. Today’s software automates this essential function. Users may edit data in one view, and the software will display up-to-date versions of all other views at the click of a button.

Theoretically, these advances should make it easy to keep a resource-leveled schedule. Indeed, modern software provides views that show the utilization of any resource in just about any unit, cumulative by date or for a particular period. With the entry of vacation calendars, holidays, resource availability over time, and other constraints, software can often show overallocation or underallocation of available resources automatically.

The key to accurate resource leveling is accurate, complete data. So many variables come together in this critical planning task:

• Resource start dates and availability
• Work estimates
• Duration estimates
• Activity sequence relationships
• Vacation schedules
• Holiday schedules
• Planning factors for unscheduled but known events like sick days
• Planning for schedule risk events

Resource leveling is the integration point for all these project elements.

Complexity increases with the use of scheduling software. It is possible to force a schedule to be resource-leveled strictly through the use of dependency relationships in most tools. Some tools offer automated systems to adjust resource allocations. Project managers should explore their tools thoroughly to understand the best techniques for their projects. Key questions for the project manager include:

• Is the method repeatable for future projects and for future reporting periods with this project?
• What if a key resource starts earlier or later than expected? How much data must be adjusted or re-entered?
• What if a single task takes more or less time than expected? How will the software respond?
• When there are two tasks that COULD start on the same date (but resource constraints will not allow them to), how does the software decide which one SHOULD start first? Does the software make decisions automatically? Can the project manager override any automated decisions easily?

Scheduling software is often designed for projects with serial dependencies. By adding “soft” dependencies to a schedule, it is possible to turn a project with many parallel opportunities into one with mostly serial dependencies. If a manager uses this technique,

• Where will the hard dependencies be documented?
• Will the software still accurately calculate key project measures, including critical path?
• When resources do work out-of-order, does the manager need to update the schedule? How will the software respond if the actuals do not match the planned activity sequence?

The better the manager understands his or her software tool, the less time is required for schedule maintenance.

Representing Task Dependencies — Hard and Soft

Task sequencing is often challenging with scheduling software. Some software will add sequencing rules to a schedule, making all tasks sequential automatically; many expert schedulers disable these features.

PMBOK distinguishes between dependencies that MUST be enforced (hard or mandatory) and dependencies that SHOULD ideally be enforced (soft or discretionary) (PMBOK 2000, 68-69). Many software packages do not make that distinction, enforcing all dependencies strictly. Some resource-leveling strategies require the use of many soft dependencies, compounding the problem.

Managers have a few options to work around these common problems:

• Use the software to enforce ONLY hard dependencies, and attempt to meet soft dependencies as part of resource-leveling steps
• Create an initial network diagram with only hard dependencies and maintain it outside the main schedule (especially useful when the project’s network diagram changes infrequently)
• Ignore the software’s network diagram and create one by hand
• Keep a spreadsheet or diagram of hard dependencies and soft dependencies – compare the schedule in the software to these lists regularly and update the software as needed
• Create custom views or use custom fields in the software to track hard and soft dependencies

Task numbering is often an obstacle in creating and synchronizing lists of tasks and dependencies. Most software numbers all tasks sequentially, and adjusts the number of every task as tasks are added or deleted. Often there is a hidden field that does not change that uniquely identifies each task. Use this number to effectively cross-reference between a spreadsheet or diagram and the data in the scheduling software. Alternatively, create task names that are unique within the project, and use these names as an effective cross-reference.

Managing and Maintaining Changing Schedules

“Everything flows on and on like this river, without pause, day and night.” -Confucius, standing by a river (Wilhelm 1987, lv)

The one unchanging principle that every project manager can count on is change itself. No matter how accurate the estimates, no matter how perfect the schedule, before the project is done, the schedule will change. Some tasks will start or end early, some will start or end late, and the project scope will expand and contract. Managing this change is the never-ending role of the project manager.

Managing schedule change is a requirement for many tough schedules. Fast-changing resource assignments, frequent changes to project scope, changes to budget, and changes to desired end-dates can make a project much more difficult to manage.

When creating a schedule for a brand new project, a manager should ask:

• What is likely to change?
• How much will it change?
• Will project changes come all at once, or a little with every reporting period?

The more the manager can anticipate change, the better he or she can plan for it. When creating the initial schedule, the manager can perform some “what-if” scenarios, seeing the effect of certain types of changes will be. Even if the exact changes cannot be predicted, the manager can develop scheduling techniques to address common sources of change:

• New tasks
• Old tasks no longer needed
• Resources are unavailable or new resources become available
• Resource start dates changing
• Changes to duration, work, and cost estimates

An expert scheduler can draw upon experience to address these situations. A novice needs to develop these techniques or learn from an expert. No matter what the experience level, though, any manager can benefit from identifying likely sources of changes and planning for them.

Modern software has opened new possible ways to model change, making uncertainty an explicit part of the project schedule. Software has been able to generate likely ranges of estimates based upon PERT estimates of likely, optimistic, and pessimistic outcomes for years. Monte Carlo simulation can be used to show the range of possible outcomes, and their relative probability. Many project managers do not need or use these tools, but for highly uncertain projects, they can be an essential feature of scheduling software.