Schedule Development
Module 3A gave you the parts — activities, logic, durations, calendars, the WBS. Schedule development is the assembly line that brings them together in the right order, runs the CPM, and turns out a schedule sound enough to commit to. Built on AACE 91R-16.
What schedule development is
It's tempting to think a schedule is "done" the moment the software draws bars. It isn't. Development is iterative: build, calculate, review against reality, fix, recalculate — until the schedule is something the team can actually commit to and be measured against.
The inputs you assemble
Schedule development pulls together everything Module 3A produced, plus a few more ingredients:
- Scope & WBS — The deliverable structure (33R-15) that the activities roll up to.
- Activities & logic — The work elements (23R-02) and their relationships (24R-03) — the network skeleton.
- Durations & calendars — Realistic time estimates (32R-04) placed on the right working calendars.
- Resources & constraints — Crews, equipment, and any genuine external dates (permits, owner-supplied items).
- The execution strategy — How the project intends to be built — phasing, sequencing approach, contracting plan — the story the schedule must tell.
The development cycle
A sound schedule is developed in a repeatable cycle, not one pass:
Build the network from activities + logic. Calculate with the CPM (forward/backward pass — next lesson) to get dates, float, and the critical path. Review the result against reality: are the dates achievable? Is the critical path sensible? Are resources level? Refine — adjust logic, durations, or strategy — and recalculate. Loop until the schedule holds up.
What a developed schedule should pass
Before a schedule earns the word "baseline," it should pass a set of sanity and integrity checks — the same things later reviews (and DCMA-style metrics) look for:
| Check | Healthy schedule… |
|---|---|
| Logic completeness | Few/no open ends; everything connected |
| Constraints | Minimal hard constraints; logic-driven dates |
| Lags / leads | Few, and each justified |
| Durations | Reasonable; very few extremely long activities |
| Critical path | Continuous, sensible, runs to completion |
| Resources | Levelled — no impossible peaks |
Ten things to remember
- Schedule development assembles the parts (activities, logic, durations, resources) into a calculated CPM.
- It's iterative — build, calculate, review, refine — not a single pass.
- Develop for the schedule's purpose — class, level, and end use set the rigor.
- The execution strategy is an input — the schedule must tell the story of how you'll build.
- Calculating isn't finishing — never accept the software's first dates unchallenged.
- Review against reality — achievable dates, a sensible critical path, levelled resources.
- Run the integrity checks — logic completeness, constraints, lags, durations, CP, resources.
- A schedule earns "baseline" only after it passes those checks and the team can commit to it.
- Document the basis as you go (next lesson) — assumptions captured now save disputes later.
- Development continues after baseline — through updates, change, and recovery.
Glossary
- Baseline
- The approved, frozen schedule that performance is later measured against.
- CPM calculation
- The forward/backward pass that produces dates, float, and the critical path.
- Execution strategy
- The intended approach to building the project, which the schedule must reflect.
- Integrity check
- A test of logic/constraint/duration health before baselining.
- Iteration
- The build–calculate–review–refine loop that produces a sound schedule.
- Resource levelling
- Adjusting the schedule so resource demand stays within realistic limits.
- Schedule basis
- The documented assumptions and methods behind the schedule (next lesson).
- Schedule development
- Assembling and refining inputs into a calculated, baseline-ready CPM schedule.