3.7 Activities, Milestones, Schedule Quality, and Basis Documentation

3.7 Activities, Milestones, Schedule Quality, and Basis Documentation

An activity is a discrete element of work used to model time and sequence. It should be specific enough to status objectively and broad enough to manage. A milestone is a zero-duration event marking a significant start, finish, decision, handoff, or commitment.

Define activities well

Each activity should have:

• unique identifier and action-oriented description;
• authorized scope and WBS mapping;
• responsible organization;
• measurable start and finish criteria;
• suitable duration and calendar;
• resources or quantity basis where relevant;
• predecessor and successor logic; and
• coding needed for control and reporting.

“Mechanical work” is too vague. “Install and inspect chilled-water piping in Area B” has clearer boundaries. Avoid creating activities solely to make a report look detailed; detail should improve planning, status, or decisions.

Use milestones intentionally

Milestone types can include notice to proceed, design release, equipment delivery, beneficial occupancy, system turnover, substantial completion, and final acceptance. Because a milestone has no duration, any work needed to achieve it must appear as predecessor activities.

Distinguish contractual milestones from internal targets and interface milestones through codes and descriptions. A hard constraint is not required on every milestone; logic should calculate dates unless an external commitment must be represented.

Quality dimensions

Schedule quality is multi-dimensional:

Metrics can locate suspect features such as open ends, negative lags, high float, long durations, or constraints. They are screening tools, not automatic verdicts. Review the underlying activity before deciding whether it is defective.

Schedule basis documentation

The schedule basis explains how the model was built. Include:

• scope and execution strategy;
• source documents and status date;
• WBS, coding, and levels of detail;
• calendars, shifts, holidays, and weather treatment;
• duration, quantity, productivity, and resource assumptions;
• procurement and stakeholder interfaces;
• constraints and lag justification;
• major paths and milestone logic;
• risk, contingency, and exclusions;
• software settings and calculation conventions; and
• known limitations and exceptions.

The basis should match the native file. A narrative saying there are no hard constraints is not useful if the file contains several unexplained mandatory dates.

Example review

A delivery milestone has no predecessor and is constrained to 15 August. The reviewer asks whether it represents owner-furnished equipment. If so, add an interface from the responsible procurement or owner milestone, document the source date, and decide whether an external constraint is still required. The fix restores causal visibility.

Baseline and update use

At baseline, the quality review tests whether the model can support commitment. During updates, it also checks progress validity, logic changes, remaining durations, new constraints, and forecast reasonableness. Update the basis or narrative when material assumptions change, while preserving the original baseline documentation.

A high-quality schedule is understandable, calculable, executable, and auditable. Activities and milestones provide the model; the basis tells reviewers what the model means.

Applied review: make the schedule explainable

An activity should describe measurable work with a clear start and finish, a responsible party, an appropriate calendar, and enough detail to assign credible duration and status. Milestones are zero-duration events representing decisions, deliveries, approvals, starts, finishes, or contractual commitments. They do not perform work. The activities and relationships that cause a milestone must be present if the model is to forecast it.

Quality review combines completeness, logic, dates, calendars, constraints, resources, coding, and status integrity. Diagnostics such as open ends, excessive lags, long durations, unusual float, hard constraints, or invalid actual dates are screening tools. Investigate each result in context; a justified exception should be documented, while an unexplained exception should be corrected. Passing a numerical threshold alone does not establish quality.

The basis document makes the model reproducible. Record scope, data date, calendars, coding, duration and productivity sources, logic strategy, constraints, milestones, resource and cost-loading methods, exclusions, risk treatment, update rules, and known limitations. During review, select sample activities and trace each date to its logic, calendar, status, and assumption. A high-quality exam response preserves this evidence and distinguishes a schedule calculation from the management assumptions that gave the calculation meaning.