Schedule Design
You wouldn't pour foundations without drawings. Schedule design is the blueprint stage — deciding structure, coding, calendars and conventions up front so the schedule you build can be sorted, filtered, rolled up, and reported the way the project actually needs. Built on AACE 61R-10.
What schedule design means
If development (last lesson) is building the schedule, design is drawing the plans for it. It answers questions like: how will this schedule be coded so we can roll it up by area and by contractor? Which calendars exist? How are activities named and numbered? What reports must it produce? Decide these once, deliberately, and every later step is cleaner.
What an undesigned schedule can't do
A schedule thrown together without design still draws bars — but it quietly fails the moment someone needs more than a printout:
| Someone asks… | Undesigned schedule |
|---|---|
| "Show me Area 2 only" | Can't filter — no area code |
| "Roll up by subcontractor" | Can't group — no responsibility code |
| "Give me a Level 1 view" | Can't summarize cleanly — no WBS hierarchy |
| "Why did this date move on a weekend?" | Wrong calendar assigned — silent errors |
What you actually design
- WBS & coding structure — The hierarchy (33R-15) plus activity codes — area, phase, discipline, responsibility — that let you filter, group, and roll up any way stakeholders need.
- Calendars — Which working/non-working patterns exist (5-day, 6-day, 7-day cure, shift) and which activities use each — so dates land correctly.
- Activity ID & naming conventions — A consistent, meaningful ID scheme and verb-noun-location naming, so the schedule is readable and sortable.
- Levels & layouts — How the schedule presents at each level (Lesson 5), and the standard views/reports it must produce.
- Conventions & settings — Default relationship type, lag rules, constraint policy, progress/retained-logic settings — the house rules that keep the schedule consistent.
Coding: one schedule, many views
The single most valuable design decision is activity coding. Beyond the WBS, you assign each activity a set of code values — its area, its responsible party, its phase, its discipline. Those codes are what let a single network be sliced into any view on demand, without rebuilding anything.
Ten things to remember
- Schedule design = the blueprint — structure and conventions decided before activities are entered.
- Design ≠ development — design plans the schedule; development builds it.
- The cheapest time to make a schedule reportable is before it's built — retrofitting is costly.
- Design the WBS + activity codes — area, phase, discipline, responsibility.
- Define the calendars and which activities use each — wrong calendars cause silent date errors.
- Set ID and naming conventions — consistent, meaningful, sortable.
- Coding is the power tool — one network slices into any view (area, trade, phase) on demand.
- Good coding makes the schedule levels (Lesson 5) roll up cleanly.
- Set the house rules — default relationship, lag/constraint policy, progress settings.
- Design with the end in mind — ask who reads it and how they'll slice it, first.
Glossary
- Activity coding
- Code values (area, phase, discipline, responsibility) attached to activities for filtering and grouping.
- Calendar
- A working/non-working pattern assigned to activities to compute dates correctly.
- Layout / view
- A saved arrangement (filters, grouping, columns) for a particular audience or report.
- Naming convention
- A consistent standard for activity IDs and descriptions.
- Retrofit tax
- The repeated cost of re-coding a schedule that wasn't designed up front.
- Roll-up
- Summarizing detailed activities upward via WBS/coding.
- Schedule design
- Up-front definition of a schedule's structure and conventions before it's built.
- Schedule settings
- The software conventions (default link, lag, constraint, progress rules) governing the schedule.