Schedule Cue
Task-specific guidance for ordinary duration, logic, and calendar issues.
Project 05
Build and gain approval for one resource-informed baseline residential construction schedule tied to the work breakdown structure, sequence logic, procurement, inspections, milestones, and contractual conditions, using approved project documents as the controlling information.
These cues appear at the point of work. They identify scheduling, resource, milestone, and authority issues before they become missed dates, hidden delay, or an unusable baseline.
Task-specific guidance for ordinary duration, logic, and calendar issues.
A missed contractual milestone, hidden delay, or false baseline is possible.
Practical resource, crew, and trade coordination affecting the schedule.
Permit, inspection, or authority review timing varies. Verify before assuming.
Follow the executed agreement's specific terms for milestones and notice.
Recordkeeping, version-control, and traceability guidance for the schedule.
This project qualifies you to build and gain approval for a baseline residential construction schedule — the controlling time document that converts the approved work breakdown structure and sequence logic into estimated durations, calendar dates, milestones, resource checks, and a defensible critical path. The finished work product is one approved, version-controlled baseline schedule supported by a schedule narrative, a risk review, and a defined update procedure.
You will confirm the schedule purpose and calendars, import the approved WBS activities and sequence logic, estimate durations from production data rather than guesswork, enter fixed contractual dates and milestones, calculate the initial schedule, identify the critical path and float, check the schedule against inspections, procurement, and owner decisions, check resource demand for trade stacking and impossible crew loads, run a schedule-risk review, and obtain authorized approval of the frozen baseline.
This project depends directly on the work already completed in Project 01 through Project 04. The approved scope statement, the job file, the work breakdown structure, and the sequence logic chart are the controlling inputs here — this project does not redefine scope, invent a new WBS, or re-derive sequence logic. It converts approved logic into approved dates. Every later project in this book depends on the baseline produced here: the two-week lookahead in Project 06, the procurement plan in Project 07, trade coordination in Project 08, and every schedule status reviewed in coordination meetings, RFIs, changes, and closeout through the Chapter 20 capstone.
The baseline schedule produced here is the time backbone of every remaining project-management document in this book. The two-week lookahead in Project 06 exists to convert this baseline into executable field commitments; it cannot function without an approved baseline behind it. The procurement plan in Project 07 calculates release dates backward from the installation dates fixed in this schedule. Trade coordination in Project 08 links handoff readiness to schedule activities created here. Job-cost reporting in Project 15 compares progress against this same baseline. The punch process in Project 14 and the final walkthrough in Project 19 both trace back to the milestone conditions defined here.
The discipline of separating the frozen original baseline from forecast dates — taught in this chapter — is the same discipline used later to preserve schedule history through delay, recovery, and approved changes without ever concealing or resetting a missed commitment.
This project covers:
This project does not authorize the learner to:
Any conflict between the sequence logic, the estimate's duration assumptions, subcontractor proposals, and contractual milestones must be identified and resolved in writing before the baseline is approved.
Establish these references before duration estimating begins, and do not change them mid-document without a recorded revision.
| Term | Definition |
|---|---|
| Baseline schedule | The one current, approved version of the schedule all progress and forecast reporting is measured against |
| Calendar duration | The number of workdays an activity spans on the project calendar, including non-labor time such as curing or drying |
| Effort hours | The labor time required to perform an activity, independent of how many calendar days it spans |
| Critical path | The longest connected chain of activities in the schedule; a delay on this path delays the project finish date |
| Total float | The amount an activity can be delayed without delaying the project finish date |
| Free float | The amount an activity can be delayed without delaying the early start of its successor |
| Forecast date | The current expected date for an activity, which may differ from the baseline date and must state why |
Before distributing the approved baseline schedule, record the baseline identification directly on the schedule-approval record:
Project name: ______ Project address: ______ Baseline number: ______ Revision: ______
Date approved: ____________ Approved by (name and role): ____________ Project manager: ____________
Every schedule in this book, from this chapter's residential baseline to the Chapter 20 capstone project schedule, follows the same sequence: confirm purpose, import logic, estimate durations, fix milestones, calculate, check, level, assess risk, approve, freeze. Learning that sequence here, on one residential project, means every later schedule update and lookahead starts from a method you already trust.
Every schedule activity must trace to an approved WBS work package and preserve the predecessor, successor, and lag relationships approved in the Project 04 sequence-logic chart. Do not create a new logic relationship while building the schedule; if the logic appears wrong or incomplete, return to Project 04 and revise the logic chart through its own approval process before continuing. A schedule that quietly changes logic to fit a desired finish date is not a baseline — it is an unrecorded redesign of the project sequence.
Once the baseline is approved and frozen, do not overwrite it with updated dates. Record actual starts, actual finishes, remaining duration, and forecast dates as a separate layer, and record the reason for every forecast-date change. A schedule with no preserved baseline cannot demonstrate whether the project is ahead, on time, or behind.
Do not reset or replace the approved baseline merely because the project has fallen behind or a milestone was missed. A rebaseline requires an authorized approval process of its own, with a documented reason. Resetting a baseline without that approval conceals delay from the owner, the estimator, and the cost-control system, and it removes the record needed to evaluate a future change or claim.
Before the baseline is approved, check resource demand by trade, crew, and equipment against the calculated schedule. A logically correct schedule that assumes three trades can simultaneously use one lift, one crane, or one limited work area is not executable. Identify trade stacking and impossible crew loads and resolve them before approval, not after mobilization.
Enter a fixed external date only when its contractual, regulatory, or lender authority is confirmed. Do not use an arbitrary date constraint merely to make the schedule appear compliant with an assumed deadline. An unconfirmed fixed date can hide float, distort the critical path, and mislead every party who relies on the schedule.
PM-025 – PM-030
Schedule Development / Planning Qualification
Deliverable: one approved residential baseline construction schedule, containing complete WBS-linked activities and logic, working calendars, estimated durations with recorded sources, fixed dates with confirmed authority, required milestones, a calculated critical path with identified float, a checked resource demand, a documented schedule-risk review, a written narrative, and written approval with an assigned baseline number and date.
| Section | Content | Source | Purpose |
|---|---|---|---|
| Purpose and detail level | Reporting cycle, calendar, and contractual milestones the schedule must support | Agreement, project management plan | Establishes what the schedule must be able to answer |
| Calendars | Standard workdays, holidays, shutdowns, seasonal restrictions, authorized overtime, weather allowances | Company policy, agreement, local conditions | Defines the working time base for every duration |
| Activities and logic | WBS-linked activities with predecessor, successor, and lag relationships | Project 03 WBS, Project 04 sequence-logic chart | Converts approved logic into a schedulable activity list |
| Durations | Estimated duration, source, and basis for every activity, including submittal, procurement, permit, and inspection time | Estimate, subcontractor proposals, field history | Establishes realistic time requirements rather than assumed ones |
| Fixed dates and milestones | Confirmed external dates and required project milestones | Agreement, permits, lender, owner selections | Anchors the schedule to contractual and regulatory commitments |
| Critical path and float | Calculated critical path, near-critical paths, total float, free float | Calculated from logic and durations | Identifies which activities control the finish date and which have flexibility |
| Resource check | Resource demand by trade, crew, and equipment; identified stacking and conflicts | WBS, subcontractor commitments, equipment plan | Confirms the schedule is executable, not only logically correct |
| Risk review | Schedule risks for long-lead items, weather, inspections, utilities, owner decisions, hidden conditions, with mitigation | Procurement plan, permit plan, field experience | Identifies where the baseline is most likely to slip and what will be done about it |
| Narrative | Explanation of calendars, milestones, critical path, major constraints, and risks | Prepared by the scheduler | Gives reviewers the reasoning behind the calculated dates |
| Approval and update rules | Written approval, baseline number and date, rules for actual dates, forecast, and rebaseline | Authorized approver | Freezes the baseline and defines how it will be maintained |
| Check | Standard |
|---|---|
| Activities and logic | Every activity traces to an approved WBS package; logic matches the approved sequence-logic chart without unrecorded changes |
| Durations | Every duration has a recorded source; effort hours, crew-days, and calendar duration are distinguished |
| Fixed dates | Every fixed date has confirmed contractual, regulatory, or lender authority; no arbitrary constraints |
| Milestones | Every required milestone entered with a measurable completion condition |
| Critical path and float | Critical path calculated and reviewed; total and free float identified without being assigned exclusively to one trade |
| Resource demand | Trade stacking, impossible crew loads, and shared-equipment conflicts identified and resolved |
| Risk review | Highest schedule risks identified with documented mitigation |
| Approval | Written approval obtained from the authorized party; baseline number and date assigned before distribution; original baseline preserved without overwriting |
Inspect every baseline schedule using the same checks regardless of project size or complexity.
Complete the Baseline Schedule Inspection Checklist in the Inspection Checklist section below before beginning Project 06.
Probable cause: a duration was estimated without a recorded source, or a fixed date was entered without confirmed authority, producing a schedule that was never realistic.
Confirmation: review the duration source for the affected activities and check whether the fixed date's authority was confirmed in Step 10.
Correction: re-estimate the duration from a confirmed production rate or commitment, remove any unconfirmed fixed date, and route the correction through the schedule-update process.
Reinspection: repeat the duration and fixed-date check across the full schedule, not only the affected activity.
Probable cause: the resource-demand check in Steps 23–24 was skipped or was performed only for labor crews and not for shared equipment or access.
Confirmation: pull the resource-demand record for the affected period and confirm whether the equipment or access conflict was identified.
Correction: level the conflicting activities within their available float, or negotiate additional equipment or access; do not resolve the conflict by informally telling one trade to "work around" the other.
Reinspection: repeat the full resource-demand check for the revised schedule.
Probable cause: the inspection-logic check in Step 19 was not completed, or the inspection activity was entered without a predecessor link to the work it inspects.
Confirmation: trace the inspection activity's predecessor in the schedule and confirm it matches the actual work the inspection covers.
Correction: add or correct the predecessor relationship and recalculate the schedule.
Reinspection: repeat the inspection-logic check for every inspection activity in the schedule.
Probable cause: the original baseline was overwritten with updated dates instead of being preserved as a separate layer, or a rebaseline occurred without the required approval and documented reason.
Confirmation: check the schedule archive for a preserved original baseline and confirm whether any rebaseline has a recorded approval and reason.
Correction: restore or reconstruct the original baseline from the archived approval record, and require future updates to preserve it as a separate layer.
Reinspection: confirm the baseline-preservation rule from Step 34 has been reissued to the scheduling team and acknowledged.
Probable cause: the float check in Step 18 recorded float only in relation to a single trade's activities rather than as a project resource shared by all activities on that path.
Confirmation: review the float value for the disputed activities and confirm whether it was communicated as exclusive to one trade.
Correction: clarify in writing that float belongs to the project, not to any single trade, and document how float will be allocated when more than one activity could use it.
Reinspection: repeat the float check across the full schedule and confirm the clarification has been distributed.
Probable cause: the schedule-risk review in Step 26 did not identify the item as high-risk, or the review was performed without confirmed procurement lead times.
Confirmation: check the schedule-risk register for the item and compare the recorded lead time against the actual supplier commitment.
Correction: add or correct the risk entry, develop mitigation, and coordinate the correction with the Project 07 procurement plan.
Reinspection: repeat the schedule-risk review for all long-lead, custom, and engineered items.
Probable cause: the authorized approver was not confirmed before calculation began, or more than one party believes they hold approval authority for the baseline.
Confirmation: check the executed agreement and project directory for the named decision authority, and confirm this matches the person the draft was routed to for approval.
Correction: resolve the authority question in writing with the owner and project management before requesting approval again.
Reinspection: repeat the approval check once a single confirmed approver has signed the baseline.
This project ends with the approved baseline schedule filed and distributed, not left as an open draft.
| Competency | Independent Pass Standard | Not Demonstrated | With Assistance | Independently |
|---|---|---|---|---|
| PM-025 | Estimates every activity duration from a recorded quantity, production rate, crew size, subcontractor commitment, or field history, with the source documented | |||
| PM-026 | Assigns start and finish dates by calculating the schedule from approved logic and confirmed durations, without arbitrary date constraints | |||
| PM-027 | Builds required milestone dates for permit, dry-in, rough inspections, utilities, substantial completion, and handoff with measurable completion conditions | |||
| PM-028 | Schedules inspections with correct predecessor and successor logic linking them to the work they inspect and release | |||
| PM-029 | Identifies total float and free float for schedule activities and communicates float as a project resource rather than as belonging to one trade | |||
| PM-030 | Produces an approved, version-controlled baseline schedule with a checked resource demand, documented risk review, narrative, and preserved baseline record |
Mark one column per competency. Only Demonstrated Independently awards the competency; Demonstrated with Assistance authorizes additional supervised practice but does not complete the requirement.
| Item | Standard | Meets Standard (Y/N) | Correction (if any) |
|---|---|---|---|
| Activities and logic | Every activity traces to an approved WBS package; sequence logic preserved without unrecorded changes | ||
| Calendars | Workdays, holidays, shutdowns, seasonal restrictions, and weather allowances defined | ||
| Durations | Every duration has a recorded source; effort hours, crew-days, and calendar duration distinguished | ||
| Fixed dates | Every fixed date has confirmed authority; no arbitrary constraints remain | ||
| Milestones | Every required milestone entered with a measurable completion condition | ||
| Critical path and float | Critical path calculated and reviewed; float identified and not assigned exclusively to one trade | ||
| Inspection and concealment logic | Every inspection and concealment activity correctly linked to predecessor and successor work | ||
| Resource demand | Trade stacking and impossible crew loads identified and resolved through leveling | ||
| Risk review | Highest schedule risks identified with documented mitigation | ||
| Approval | Written approval by authorized party; baseline number and date assigned; original baseline preserved |
Schedule-risk register status: ____________ Open risks carried forward: ____________
Baseline schedule declared approved: ______ (Pass/Fail) Date: ____________ Project manager name: ____________
With the baseline schedule calculated and reviewed, review it against the Acceptance Standards table and confirm every activity traces to the approved WBS and preserves approved sequence logic, every duration has a recorded source, every fixed date has confirmed authority, every required milestone is entered with a measurable condition, the critical path and float have been calculated and reviewed, inspection and concealment logic is correctly linked, resource demand has been checked and leveled without eroding milestones, the highest schedule risks have documented mitigation, and written approval has been obtained from the authorized party with a baseline number and date assigned. Complete the Baseline Schedule Inspection Checklist and correct any failed item before beginning Project 06. If an item fails, identify whether the error occurred in logic import, duration estimating, fixed-date confirmation, milestone definition, critical-path calculation, resource checking, risk review, or approval before revising.
You have completed the fifth project in the construction project management sequence: building and approving a residential construction schedule. This project required you to estimate task durations (PM-025), assign start and finish dates (PM-026), build milestone dates (PM-027), schedule inspections (PM-028), identify float (PM-029), and create a baseline project schedule (PM-030).
You now have an approved, version-controlled baseline schedule, a checked resource demand, a documented schedule-risk review, and defined update and rebaseline rules. That baseline carries directly into the next project: converting the master schedule into an executable two-week lookahead that confirms labor, material, and inspection readiness for the immediate work ahead.
File your approved baseline schedule, resource-demand check, and risk register where Project 06 can incorporate them into the initial two-week lookahead. Every later schedule update, lookahead, and status report in this book is measured against this exact baseline.