3.3 Schedule Levels of Detail and Schedule Basis Documentation

3.3 Schedule Levels of Detail and Schedule Basis Documentation

AACE RP 37R-06 addresses schedule levels of detail as applied in engineering, procurement, and construction. A common convention ranges from executive milestones and phase summaries to integrated project controls and detailed execution schedules. The labels are useful communication shorthand, but the project specification or organization must define what each level means.

Common level purposes

• Executive or milestone view: major authorization, phase, delivery, turnover, and completion commitments.
• Phase or summary view: engineering, procurement, construction, commissioning, and major package interfaces.
• Integrated control schedule: the cross-functional network used to status, analyze paths, forecast milestones, and coordinate control accounts or packages.
• Detailed execution schedule: discipline, area, contractor, or system detail used for near-term coordination and measurable progress.
• Short-interval plan: daily or weekly commitments, crew assignments, and work-face coordination.

Numbering varies, and not every project needs five levels. A small project may operate effectively with a milestone view, one integrated schedule, and a look-ahead. A complex program may need several intermediate models. Define purpose, owner, update frequency, coding, and reconciliation rules before calling a file “Level 3” or “Level 4.”

Traceability across levels

Higher-level dates should be explainable from lower-level work. A summary bar is not independent logic. Control milestones can tie packages together, while coding and reporting rules roll detail into management views. If a field schedule forecasts a later system turnover than the control schedule, reconcile status, scope, calendars, and logic rather than maintaining two incompatible truths.

More detail is useful only when it supports a decision and can be maintained. Excessive granularity creates update burden and false precision. Too little detail can hide interfaces, make progress subjective, and prevent path analysis. Select detail based on risk, phase, work complexity, reporting cycle, responsibility, and evidence availability.

Documenting the basis

AACE RP 38R-06 concerns documenting the schedule basis. A basis document commonly addresses:

1. project scope, boundaries, WBS, and exclusions;
2. execution, packaging, phasing, and contracting strategy;
3. milestone sources and stakeholder interfaces;
4. activity and coding conventions;
5. logic strategy and material preferential relationships;
6. duration, quantity, productivity, crew, and procurement sources;
7. calendars, shifts, holidays, restrictions, and weather treatment;
8. constraints and lags with their justifications;
9. resource or cost loading and reconciliation methods;
10. risk, contingency, and sensitivity assumptions;
11. current critical and near-critical paths; and
12. known limitations, unresolved items, and approval status.

These are useful content categories, not a claim that every project must use an identical seven- or twelve-section template. Follow the required submittal format where one exists.

Evidence and governance

The native schedule calculates dates; the basis explains why the model was constructed as it was. Reviewers should be able to trace a duration to its source, a calendar to its working-time assumption, a milestone to its requirement, and a constraint to its authority. When assumptions change, update the current forecast and record the change. If an authorized baseline revision occurs, preserve the prior basis and issue a bridge to the new one.

A basis document can be important contemporaneous evidence, but its legal effect depends on the contract, approval history, facts, and applicable law. It does not automatically convert a planning hypothesis into a binding promise or prove delay entitlement.

Review test

Select a management milestone and trace it down to detailed driving work. Then select a detailed activity and trace it up to its scope, responsible organization, cost account, and reporting milestone. Confirm that calendars, logic, and status reconcile across the views. This bidirectional trace is more meaningful than judging schedule quality by activity count alone.

Applied review: choose detail by control need

Define a test for each schedule view. An executive view should expose decisions and commitment dates. A control schedule should support objective status, path analysis, variance, and forecast. A field view should assign near-term work to crews and work faces. If a view cannot support its intended decision, change its content or frequency rather than merely adding activities.

At each reporting cycle, reconcile milestone dates and status between views. Document intentional cutoffs, filters, and aggregation. The basis should also identify which view is the controlled source and how subordinate schedules feed it. That governance prevents a favorable summary chart from drifting away from the current detailed forecast.