Basis of Schedule for Construction: A Practical Blueprint for a Defensible CPM Baseline

A project executive opens a newly submitted Primavera P6 baseline schedule and sees more than 2,000 activities extending from notice to proceed through final completion. The schedule contains design packages, submittals, procurement, field construction, testing, commissioning, owner training, and closeout. Its dates appear orderly. The critical path reaches the contractual completion milestone without negative float, and the scheduling report shows few obvious technical deficiencies. On the surface, the project has a complete plan.

Then the review meeting begins.

The owner asks why the mechanical equipment is expected to arrive in February. The scheduler explains that the date came from a preliminary vendor quotation issued before the subcontract was awarded. A superintendent asks why interior work follows a five-day calendar when the proposed recovery plan depends on Saturdays. The project manager cannot say whether weekend premiums were included in the subcontractor’s price. The commissioning agent notices that functional testing begins immediately after permanent power is available, although the schedule contains no allowance for controls integration, prefunctional checklists, or failed-test corrections.

Within an hour, the team discovers that many of the dates are built on assumptions that were never recorded. The schedule calculates, but the reasoning behind it is scattered among meeting notes, estimate files, bid clarifications, emails, and the memories of people who may not remain on the project.

This is the problem a Basis of Schedule is intended to solve.

A Basis of Schedule is the written record of how the project schedule was developed. It explains the planning information, execution strategy, calendars, duration assumptions, production expectations, key dependencies, exclusions, risks, and decisions that support the calculated dates. AACE International describes the schedule basis as a document that defines the basis for developing the project schedule and helps stakeholders identify key assumptions, exclusions, risks, opportunities, and special considerations. AACE also notes that it can support change management, schedule reconciliation, personnel transitions, and later analysis. 

The CPM schedule and the Basis of Schedule should be read together. One is the time model. The other explains the thinking used to build that model. When the two are properly aligned, the project team can test whether the forecast is reasonable, identify assumptions that require confirmation, and understand why the completion date moves when conditions change.

The missing half of the CPM baseline

What a Basis of Schedule actually is

A construction schedule is a structured model of time. It divides the work into activities, connects those activities through relationships, applies calendars and durations, and calculates the dates produced by the network. Depending on project requirements, the schedule may also contain resources, costs, responsibility codes, work areas, procurement packages, constraints, and contractual milestones. Primavera P6 and similar scheduling platforms perform these calculations consistently, provided that the underlying information and settings are appropriate.

The software does not explain where that information came from. A 30-day duration may reflect a measured production rate, a subcontractor commitment, an estimator’s allowance, or a scheduler’s early assumption. Those four sources do not carry the same degree of confidence. Likewise, an equipment delivery date may be supported by an executed purchase order, an informal vendor discussion, or a date required to make the overall schedule finish on time. The activity bar looks the same in each case, although the commercial and operational risk is very different.

The Basis of Schedule records this supporting information in a form that can be reviewed and maintained. It should explain the project scope, the maturity of available design information, the planned construction sequence, the major calendars, the treatment of weather, the development of activity durations, and the source of important procurement dates. It should also identify owner responsibilities, government or utility interfaces, access restrictions, testing requirements, turnover logic, schedule reserve, major risks, and anything intentionally excluded from the schedule.

AACE’s current recommended practice identifies many of these subjects directly, including project description, scope of work, execution strategy, key dates, planning basis, critical path, path of execution, startup, assumptions, exclusions, baseline changes, and schedule reserve. It also recommends beginning the document while the schedule is being developed and maintaining it as the project progresses. 

The Basis of Schedule is sometimes confused with the baseline narrative. The two documents may overlap, but they have different purposes. A baseline narrative usually summarizes the submitted schedule and highlights its principal features for review. A Basis of Schedule reaches further into the planning foundation. It explains why the calendars, durations, logic, sequence, and milestone dates were selected. On smaller projects, the two documents may reasonably be combined. On a large or complex project, separating them often produces a clearer and more useful record.

It is also different from the scheduling specification. The specification states what the contractor must submit and how the schedule must be prepared. The Basis of Schedule explains how those requirements were applied to the actual project. One establishes the rules. The other documents the planning decisions made within those rules.

Why a calculating schedule may still be unreliable

Construction teams sometimes treat successful schedule calculation as evidence that a baseline is sound. Calculation is necessary, but it proves only that the software can process the network as entered. It does not establish that the work is complete, the sequence is practical, the resources are available, or the durations are achievable.

Consider a hospital renovation in an occupied facility. The baseline may show demolition advancing continuously from one department to the next. The schedule logic is technically valid, and every activity has a predecessor and successor. Yet the plan may quietly assume that the owner will release each department on the contractor’s preferred date. If the phasing agreement has not been approved, the sequence is conditional. That condition should be visible in the Basis of Schedule, along with the date by which the owner’s confirmation is required.

A similar issue appears in procurement. A schedule may show electrical switchgear delivered 40 weeks after submittal approval. That duration may have been reasonable when the project was estimated, but the actual manufacturer may require 60 weeks after approved drawings and release of deposit. Until the purchasing team obtains a current commitment, the schedule contains a planning assumption rather than a confirmed delivery forecast. The Basis of Schedule should say so plainly.

The same principle applies to labor and production. Suppose a concrete schedule assumes two complete floor cycles every three weeks. The duration may be possible with two formwork crews, dedicated placing equipment, timely inspections, and unrestricted overtime. If the project has budgeted only one crew and local restrictions limit working hours, the schedule is mathematically clean but operationally unsupported.

The U.S. Government Accountability Office describes a reliable schedule as a management tool that identifies when work will occur, measures performance against an approved plan, and helps determine whether major events and completion dates are realistic and achievable. Its schedule assessment guidance emphasizes that forecast credibility depends on the quality and reliability of the underlying schedule, rather than the appearance of the final dates alone. 

A strong Basis of Schedule exposes the difference between a firm commitment and an early planning assumption. That distinction helps reviewers focus their questions where uncertainty is greatest. It also reduces the temptation to preserve an optimistic completion date by using unsupported durations, unnecessary constraints, or incomplete logic.

Who uses the document and when

The Basis of Schedule should be useful to more than the scheduler who prepares it. A well-developed document gives every major participant a common explanation of the project’s time plan and the conditions required to achieve it.

For the contractor’s project manager, it provides a concise account of the execution strategy being presented to the owner. It identifies which dates depend on subcontract awards, design releases, procurement commitments, temporary works, access, and third-party decisions. This allows the manager to turn schedule assumptions into action items before they become field problems.

For the superintendent, the document explains the planned flow of work in practical terms. It should describe area sequencing, crew progression, work calendars, major handoffs, temporary access, shutdown periods, and the relationship between field production and inspections. If the network says one thing while the Basis of Schedule describes another, the discrepancy deserves immediate attention.

Owners and construction managers use the document to understand what they are being asked to approve. A baseline acceptance process is more meaningful when reviewers can see the assumptions supporting the completion date. They can determine whether owner decisions, design reviews, utility activities, furnished equipment, and occupancy requirements have been represented fairly. The review becomes a discussion about the actual plan rather than a narrow debate over schedule metrics.

The document becomes especially valuable when project personnel change. Construction projects often outlast individual assignments. Schedulers transfer, project managers are promoted, consultants complete their engagements, and replacement staff inherit schedules developed months earlier. Without a written basis, the incoming team must reconstruct the original planning logic from old files and conversations. AACE specifically recognizes personnel transition as one of the uses of schedule basis documentation. 

During construction, the Basis of Schedule also provides a reference point for evaluating change. If permanent power was originally assumed by a certain date, the team can compare that assumption with the later utility commitment. If weekend work was included in the baseline, the cost and subcontract implications should already be visible. If the project is resequenced, the team can identify which original planning decisions have been replaced and why.

The schedule file answers an important question. It tells the team when the current model predicts that the work will occur. The Basis of Schedule answers the questions that usually follow. It explains what information supports that prediction, which conditions must remain true, who controls the critical decisions, and where uncertainty remains.

A baseline becomes far more defensible when those answers are documented before the project depends on them.

The anatomy of a decision-grade Basis of Schedule

A useful Basis of Schedule does more than describe the activities already visible in a bar chart. It explains how the project team translated drawings, specifications, contract requirements, estimates, subcontractor input, and management decisions into a working plan. The document should be detailed enough for an experienced reviewer to understand the reasoning behind the schedule without requiring a separate interview with its original author.

AACE International recommends that the schedule basis address the project scope, execution strategy, key dates, planning basis, critical path, path of execution, assumptions, exclusions, risks, startup, and schedule reserve where applicable. These subjects should be developed alongside the schedule rather than assembled hurriedly after the network is complete. When the document is written too late, it often becomes a description of the finished bar chart instead of an honest record of the decisions that produced it.

Project scope, execution strategy, and schedule architecture

The opening portion of the Basis of Schedule should establish what the schedule covers. This sounds elementary, yet scope boundaries are one of the most frequent sources of misunderstanding during baseline review. The document should identify the contractual work, major owner-furnished items, separate contractors, utility responsibilities, permitting interfaces, testing obligations, occupancy requirements, and meaningful exclusions. It should also explain the level of design information available when the baseline was prepared.

That last point matters because the apparent precision of scheduling software can exceed the maturity of the underlying plan. A schedule prepared from 60 percent design documents may contain thousands of calculated dates, but many of its durations and sequences will remain subject to design development. The Basis of Schedule should state this directly and identify the portions of the plan that require later validation. Doing so does not weaken the baseline. It allows the project team to manage uncertainty openly.

The execution strategy should then describe how the work is expected to move through the project. A general statement such as “construction will proceed by area” provides little value. A stronger description explains which area begins first, why it was selected, how crews will progress, what separation will be maintained between trades, and which conditions permit the next area to start.

For example, a meaningful statement might explain that structural work will advance from the east building toward the central plant, while overhead mechanical and electrical rough-in follows two floors behind concrete placement. Interior framing will begin only after the enclosure reaches the required weather-tight condition. This wording allows a reviewer to compare the stated strategy with the relationships in the CPM network.

The document should also explain the schedule architecture. This includes the work breakdown structure, major activity codes, project phases, responsibility assignments, areas, systems, bid packages, and turnover zones. On a large project, these structures determine whether the schedule can produce useful reports for different audiences. A superintendent may need a location-based view, procurement staff may need equipment packages, and an owner may need contractual milestones and major systems.

Current scheduling platforms can store extensive coding, resource, relationship, calendar, and constraint data. Oracle’s Primavera P6 documentation confirms that activity dates are calculated from durations, calendars, relationships, constraints, and, in some configurations, resource availability. The Basis of Schedule should record how those features were used because two schedules with similar bar charts can calculate very differently when their settings or activity types differ.

Calendars, durations, resources, and production assumptions

Calendars are among the most influential and least discussed elements of a construction schedule. A five-day calendar, a six-day calendar, and a seven-day calendar can produce very different completion forecasts from the same activity durations. The Basis of Schedule should identify the calendars used, the working hours assigned to each, recognized holidays, planned shutdowns, seasonal restrictions, night-work periods, and any special access windows.

Calendar descriptions should reflect actual operating plans. If structural concrete is scheduled six days per week while most interior trades follow a five-day calendar, that distinction should be explained. If utility shutdowns can occur only on weekends, the affected activities should use a calendar that reflects those windows. If winter conditions are expected to reduce excavation or exterior production, the schedule should show how that impact was considered.

The treatment of weather deserves more than a sentence stating that normal weather is included. The document should explain whether weather allowances were included within activity durations, represented through nonworking calendar days, placed in explicit weather activities, or managed through another approved method. The chosen approach should be consistent with the contract and should avoid counting the same allowance twice.

Duration development requires similar transparency. A duration should be traceable to a reasonable basis, particularly when it affects the critical or near-critical path. That basis may include quantity takeoffs, crew composition, expected production, subcontractor input, historical performance, manufacturer information, regulatory review periods, or contractual requirements.

Consider a masonry activity containing 30 working days. The number has limited meaning by itself. A stronger basis would identify the approximate wall quantity, the planned crew size, the expected daily production, anticipated mobilization time, and any allowance for scaffolding or inspection. The schedule does not need to become a detailed estimate, but the major assumptions should be understandable.

It is useful to classify important schedule inputs according to their reliability. A contractual fact comes directly from an executed agreement or binding requirement. A confirmed commitment may come from a subcontractor, supplier, utility, or authority. A historical performance assumption relies on measured production from comparable work. A planning assumption fills a gap until better information becomes available. A conditional assumption depends on an event, approval, or decision that has not yet occurred.

This classification helps management distinguish a date supported by evidence from one that still requires confirmation. A 48-week generator delivery supported by a current manufacturer letter should receive different treatment from a 36-week allowance carried forward from the estimate. Both can appear as procurement activities, but their risk profiles are clearly different.

Logic, critical path, constraints, and milestone strategy

The Basis of Schedule should describe the principal path of execution in words that a project manager and superintendent can test against field reality. It should identify the expected critical path, important near-critical paths, major interfaces, and the sequence leading to substantial completion or other contractual milestones.

Logic descriptions should address more than the quantity of relationships. They should explain why major activities are connected and whether those connections reflect physical sequence, resource movement, safety, access, approval, or contractual requirements. Oracle defines relationships as the links that describe how the start or finish of one activity relates to another. Those relationships work with activity durations to determine calculated schedule dates.

Excessive use of start-to-start and finish-to-finish relationships can make a schedule appear more flexible than the actual work plan. These relationship types are valid when they model genuine overlap, but the Basis of Schedule should explain significant concurrent work and the production assumptions supporting it. Long lags deserve similar attention because they can conceal work, waiting periods, or approval processes that may be better represented as visible activities.

Constraints should be identified individually or by clearly defined category. Primavera P6 supports several constraint types that can affect early dates, late dates, or total float. A constraint may be appropriate when it reflects a contractual milestone, access restriction, regulatory date, or external commitment. It becomes risky when it is used merely to force the network to display a preferred result.

The milestone strategy should distinguish contractual dates from internal management targets. Contract milestones may include notice to proceed, phased turnover, substantial completion, beneficial occupancy, final completion, or liquidated-damages dates. Internal milestones may include dry-in, permanent power, equipment startup, first inspection, or release of a work area. Clear identification helps prevent an internal planning target from being mistaken for a binding obligation.

Before a baseline is submitted, its Basis of Schedule should allow the project team to answer ten practical questions.

1. What scope and project phases are included in the schedule?
2. Which design, procurement, construction, testing, and closeout assumptions support the completion date?
3. Which calendars and work hours are assigned to the major work packages?
4. How were critical and near-critical durations developed?
5. Which dates are confirmed commitments and which remain planning assumptions?
6. What owner, designer, utility, authority, or third-party actions control the work?
7. Which constraints are used, and what justifies each one?
8. What sequence leads to substantial completion and final completion?
9. Which exclusions or unresolved decisions could materially change the forecast?
10. What evidence would cause the team to revise the original planning basis?

The U.S. Government Accountability Office’s schedule assessment guidance emphasizes that a reliable schedule should capture all activities, sequence them logically, assign realistic durations, establish a valid critical path, account for resources, and support ongoing progress measurement. A well-written Basis of Schedule does not replace those technical practices. It makes the reasoning behind them visible and reviewable.

The assumption stress test

Every baseline schedule contains assumptions. Some are minor and disappear as design and procurement information improves. Others sit directly beneath the critical path and can move substantial completion by weeks or months if they prove wrong. The purpose of an assumption stress test is to identify the second group before the project becomes dependent on them.

This review is different from a standard schedule quality check. A quality check may identify missing logic, excessive constraints, long durations, open ends, or unusual float values. The assumption stress test asks whether the plan remains achievable when its most important supporting beliefs are challenged. It examines the dates and conditions that the scheduling software accepts without knowing whether they are commercially agreed, physically practical, or supported by current information.

The process should occur before baseline approval and continue during major design, procurement, and execution transitions. It is especially valuable on projects with incomplete design, long-lead equipment, phased occupancy, active-facility restrictions, extensive commissioning, or substantial owner and third-party involvement.

Which assumptions can move the completion date

The first step is to identify assumptions that influence the critical path, a near-critical path, or a major contractual milestone. The team should avoid filling the review with minor administrative details. Attention belongs on conditions that can change the project’s sequence, available work areas, production capacity, or readiness for turnover.

Design-release dates are a common starting point. A schedule may assume that issued-for-construction documents will be available several months after notice to proceed, even though the design team has not confirmed the package sequence. If foundations depend on civil approvals, underground coordination, or revised geotechnical recommendations, the planned field start may be less certain than the schedule suggests. The Basis of Schedule should identify the required release dates and the activities affected by each package.

Permits and agency reviews require the same treatment. A single activity titled “obtain permit” may conceal several submissions, comment cycles, public-agency reviews, utility coordination steps, or special inspections. The assumption stress test should ask whether the duration reflects the authority’s current process and whether approval depends on information that has not yet been completed.

Procurement assumptions can have an even greater effect. Equipment schedules are often built from estimate-stage lead times before vendors are selected and technical submittals are approved. The review should distinguish fabrication time from the full procurement cycle. The latter may include bid leveling, subcontract execution, submittal preparation, design review, resubmission, approved drawing release, material acquisition, factory testing, shipping, customs clearance, and site receipt.

A quoted 40-week lead time may begin after approved drawings rather than after purchase order issuance. That distinction can add several months to the forecast. The Basis of Schedule should explain the starting point of each significant lead time and record whether the date comes from a manufacturer, supplier, subcontractor, estimator, or project planner.

Site conditions and operating restrictions are another major source of risk. Renovation and infrastructure projects may depend on access to occupied spaces, track windows, lane closures, outages, environmental restrictions, or seasonal permits. The schedule may show continuous production, while the actual work can occur only during limited windows. These restrictions should be modeled and documented before the team relies on the resulting completion date.

The same questions apply to labor, inspections, and commissioning. A plan may assume that multiple crews will work concurrently, inspectors will be available on demand, and owner representatives will witness testing as soon as systems are ready. Each assumption may be reasonable, but the project team should know who controls it and what evidence supports it.

Turning assumptions into dated decisions

An assumption becomes more manageable when it is converted into a decision or confirmation with a required date. General statements such as “utility coordination may affect energization” provide little direction. The team needs to know what must happen, who must make it happen, and when the answer is required to protect the current plan.

A stronger statement might explain that final utility design acceptance is required by September 18 to preserve the release of switchgear, feeder installation, permanent-power energization, and integrated systems testing. This wording connects the assumption to a date and a clear sequence of downstream consequences.

The project should maintain an assumption and decision register for significant schedule inputs. The register does not need to become another burdensome reporting system. It can be a concise table linked to the Basis of Schedule and reviewed during schedule meetings. Each entry should identify the assumption, its source, the responsible party, the required confirmation date, the affected activity IDs, the related milestone, the current confidence level, and the planned response if the assumption proves false.

Confidence ratings are useful when they are based on evidence rather than personal optimism. A contractual fact or executed commitment may carry a high level of confidence. A current written vendor confirmation may also be reasonably strong, provided that the technical release conditions are understood. A preliminary estimate, verbal discussion, or historical allowance should be classified more cautiously.

The confirmation date should come before the assumption begins to affect field execution. Waiting until an activity becomes critical leaves little room to respond. If an owner selection controls shop drawing development, the decision date should reflect the entire downstream chain, including design coordination, review, procurement, fabrication, delivery, and installation.

This practice also improves schedule updates. When an assumption is confirmed, the team can replace the planning allowance with current information. When it is invalidated, the schedule should be revised promptly and the effect explained. The resulting forecast becomes a record of evolving project knowledge rather than a static reproduction of the original baseline.

A baseline that was on time for the wrong reasons

Consider a fictional courthouse modernization project involving occupied spaces, new electrical infrastructure, mechanical replacement, security upgrades, and phased turnover. The contractor’s baseline showed substantial completion within the contractual period and passed the owner’s initial schedule metrics. The network had few open ends, limited constraints, and a clear path through permanent power, systems testing, and final occupancy.

A deeper review found that the forecast depended on several undocumented assumptions. The schedule allowed one review cycle for major electrical submittals, although the design documents were still being coordinated. It assumed switchgear fabrication would begin immediately after subcontract award, even though the manufacturer required approved drawings and a deposit before release. It also used six-day calendars for interior work, while the subcontractors had priced five-day operations.

Access assumptions created further concern. The schedule showed renovation work moving continuously through occupied departments, but the owner had not approved the proposed relocation sequence. Security-system testing and owner training were scheduled at the same time, even though the owner’s staff would support both. Final authority inspections were treated as short finish milestones with no allowance for corrective work or reinspection.

None of these assumptions was necessarily unreasonable. The problem was that the completion date depended on all of them being true at the same time.

The project team converted each assumption into a dated decision. The owner established deadlines for approving relocation phases. Procurement staff obtained written lead-time information tied to actual release conditions. The contractor revised work calendars to match subcontract commitments and identified where paid overtime might be authorized later. Commissioning activities were expanded to include prefunctional checks, controls integration, failed-test correction, and retesting.

The revised schedule finished later than the original submission, but it gave the team a credible plan and an earlier opportunity to recover time. Management approved selected early-release packages, accelerated owner decisions, and adjusted the turnover sequence before field congestion developed.

This example illustrates the value of the stress test. An optimistic date can appear acceptable when each assumption is reviewed separately. The real risk emerges when the project depends on several uncertain conditions occurring together. A defensible Basis of Schedule makes those dependencies visible while the team still has time to act.

Keeping the schedule basis alive during construction

A Basis of Schedule should not disappear into the project files after the baseline is accepted. Its greatest value may emerge months later, when the original plan begins to encounter design revisions, procurement changes, access limitations, productivity differences, and new owner requirements. At that point, the project team needs more than a comparison between planned and actual dates. It needs a reliable explanation of what the original forecast assumed and how the basis of that forecast has changed.

The document should therefore be treated as a controlled project record. It does not need to be rewritten every month, but material changes should be recorded when they alter the execution strategy, critical path, work calendars, major durations, external dependencies, or milestone assumptions. This creates continuity between the accepted baseline, current update, recovery plan, and any later analysis of delay or change.

From baseline document to change-control record

A normal schedule update records progress. Actual starts and finishes are entered, remaining durations are reassessed, logic is refined where appropriate, and the data date moves forward. These routine status changes do not necessarily alter the Basis of Schedule. A concrete activity finishing later than planned may be a performance variance, while a decision to replace the original floor-by-floor sequence with a zone-based approach changes the planning basis itself.

The distinction matters because projects often revise their schedules without documenting why the underlying plan changed. A later reviewer may see new relationships, altered calendars, revised activity durations, or a different critical path, yet have no clear record of the management decision behind those changes. The update narrative may describe what moved during the month, but it may not preserve the broader reasoning that led the team to adopt a new execution strategy.

Material changes to the schedule basis may include a major resequencing of work, a shift from five-day to six-day operations, revised procurement commitments, altered turnover requirements, new phased occupancy dates, changes in access, or the introduction of a recovery program. The project team should record what changed, when the decision was made, who approved it, and which original assumptions were replaced.

The revised document should also distinguish between a correction and a change. A correction addresses an error in the original schedule, such as missing logic or an incorrectly assigned calendar. A change reflects new information or a new management decision. Keeping those categories separate improves transparency. It prevents later discussions from treating every revision as evidence that the original baseline was defective.

Version control is important. Each material revision should carry a date and a concise explanation of the change. The original basis should remain available rather than being overwritten. A project may eventually have an accepted baseline basis, one or more approved revisions, and supporting change records. That history allows the team to understand how the project plan evolved rather than seeing only its latest form.

Connecting the basis to monthly updates and narratives

The monthly schedule narrative should use the Basis of Schedule as a reference point. It should explain whether the project is performing in line with the original assumptions and identify where current conditions differ. This produces a more informative report than simply listing delayed activities or changes in total float.

Suppose the baseline assumed that an interior framing crew would complete one floor every 15 working days. After three floors, actual performance shows an average of 22 days because of incomplete overhead coordination and repeated inspection holds. The monthly update should explain the variance and state whether the remaining durations have been revised. The Basis of Schedule may also need an amendment if the original production assumption no longer supports the forecast.

Procurement reporting should follow the same approach. If the baseline relied on an estimate-stage equipment lead time, the team should replace it with current manufacturer information when the purchase order and approved submittal are available. A good narrative explains the source of the revised date and its effect on installation, energization, startup, and turnover. This gives management a clear basis for action rather than an unexplained movement in a procurement bar.

Modern scheduling environments make it easier to compare versions, review logic changes, monitor trends, and connect schedule information with dashboards, cost data, document controls, and field reporting systems. These tools improve visibility, but they do not determine whether a schedule change is reasonable. Human judgment is still required to understand why an assumption changed, whether the new forecast is supported, and what response is appropriate.

The monthly process should also identify assumptions that remain unresolved. A planning allowance may be acceptable during baseline development, but it should not remain unchallenged for months. The update narrative can track the required confirmation date, responsible party, and possible effect of continued uncertainty. This keeps the schedule connected to current management decisions.

Why the original basis matters during recovery and delay analysis

Recovery schedules often introduce significant changes to the original execution plan. The contractor may add crews, extend working hours, divide areas differently, overlap activities, revise procurement methods, or alter the turnover sequence. These measures should be documented against the accepted Basis of Schedule so the team can distinguish the original plan from the later recovery strategy.

Without that distinction, a recovery schedule can unintentionally rewrite project history. A reviewer may assume that six-day workweeks, expanded crews, or concurrent operations were always part of the plan, even when they were introduced later to address delay. Clear documentation protects the integrity of both the baseline and the recovery effort.

The Basis of Schedule is also valuable during time impact analysis and other forms of delay evaluation. It helps establish what the project team reasonably contemplated before the event occurred. If the original plan depended on unrestricted access, timely design release, or a particular utility date, the written basis provides context for assessing what changed. It can also show whether a condition was known, assumed, excluded, or specifically assigned to another party.

This record does not decide contractual responsibility by itself. Delay analysis requires a review of the contract, contemporaneous schedules, project correspondence, progress records, and the facts surrounding each event. The Basis of Schedule contributes by explaining the planning assumptions that existed at the relevant time.

A well-maintained basis also improves recovery decisions. Management can compare actual performance with original production expectations, identify which assumptions have failed, and determine whether the remaining plan still reflects field conditions. Recovery then becomes a practical revision of the execution strategy rather than a cosmetic attempt to force the completion date back into place.

The schedule changes throughout construction because the project changes. The Basis of Schedule preserves the reasoning behind those changes. When maintained with discipline, it creates a continuous record from the first baseline submission through final completion.

How Leopard Project Controls can help

Preparing a credible Basis of Schedule requires a combination of scheduling knowledge, construction experience, contract awareness, and disciplined documentation. The schedule developer must understand how the work will be performed while also knowing how calendars, activity types, relationships, constraints, and calculation settings affect the dates produced by Primavera P6 or Microsoft Project. When these responsibilities are separated among several people without a clear coordination process, the schedule file and its written basis can quickly drift apart.

Leopard Project Controls provides construction scheduling and project controls support for contractors, owners, developers, public agencies, and other participants in complex capital projects. Its work includes baseline schedule development, progress updates, schedule narratives, delay analysis, schedule reviews, owner-side scheduling support, 4D and BIM integration, Primavera P6 services, and Microsoft Project scheduling. The firm reports experience with federal, commercial, infrastructure, education, mission-critical, and data center projects across the United States.

Developing the schedule and its written basis together

The best time to prepare a Basis of Schedule is while the CPM network is being developed. This allows each important assumption to be recorded when the team makes it, rather than reconstructed several weeks later. Leopard Project Controls can review drawings, specifications, contractual milestones, bid schedules, procurement information, proposed staffing, phasing plans, and available subcontractor input before converting that information into a structured schedule.

During baseline development, the team can document the project scope, schedule architecture, work calendars, duration methods, procurement assumptions, planned construction sequence, milestone strategy, and external interfaces. Important owner decisions, design releases, utility activities, authority reviews, and commissioning requirements can be tied to specific activities and dates. The resulting Basis of Schedule then explains the same execution strategy that appears in the network.

This coordinated approach reduces a common weakness in baseline submissions. On many projects, the scheduler prepares the CPM file while a project engineer writes the narrative separately. The two documents may use different terminology, describe different sequences, or make conflicting statements about calendars and procurement. Developing them together produces a more consistent package and gives reviewers a clearer understanding of the proposed plan.

The firm can also prepare supporting reports such as milestone schedules, longest-path reports, procurement logs, schedule narratives, assumption registers, and short-term look-ahead schedules. These documents help translate the detailed CPM model into information that project executives, superintendents, owners, and agency reviewers can use during meetings and decision-making.

Reviewing an existing baseline package

A schedule review should examine the quality of the network and the credibility of its planning basis. Leopard Project Controls can review an existing Primavera P6 or Microsoft Project schedule together with its specifications, narrative, and supporting documentation to determine whether the package presents a coherent and achievable plan.

The review may examine whether the schedule includes the full contractual scope, whether major durations are supported, and whether the logic reflects the intended field sequence. It can also identify hidden dependencies on unconfirmed procurement dates, owner decisions, access conditions, inspection availability, utility work, or commissioning resources. Calendars and constraints can be assessed to determine whether they represent actual project conditions or merely preserve preferred dates.

A technically compliant schedule may still depend on optimistic assumptions. An independent review can identify where a completion date relies on several uncertain conditions occurring together. This is particularly important on federal and public projects, where schedule specifications may require detailed coding, narratives, cost loading, resource information, schedule quality metrics, and agency-specific reports. The company states that its work includes schedule compliance support for projects involving USACE, NAVFAC, DOT, and VA requirements.

Review comments should be practical and traceable. Rather than stating that a schedule is generally unrealistic, a useful review identifies the specific activity, assumption, relationship, duration, calendar, or constraint creating the concern. It should also explain the likely effect and recommend a reasonable correction. This makes the review more valuable to the project team and reduces unproductive arguments about personal scheduling preferences.

Supporting updates, recovery, and delay analysis

The Basis of Schedule becomes more useful when it remains connected to the monthly update process. Leopard Project Controls can support progress collection, schedule updates, variance analysis, narrative reporting, critical-path review, and forecast development. The process can compare actual performance with original assumptions and document when the planning basis changes.

If procurement dates move, the update can explain whether the change resulted from a late submittal, extended review, revised manufacturer lead time, or delayed commercial release. If production falls below the baseline assumption, remaining durations can be reassessed using current field information. If the project changes its sequence, calendars, or turnover strategy, the revised basis can preserve the reason for that decision.

The same record supports recovery planning. A credible recovery schedule should explain which measures are new, how they differ from the accepted plan, and what resources or approvals they require. Added crews, overtime, resequencing, prefabrication, alternate procurement, phased turnover, and overlapping testing may improve the forecast, but each measure should be supported by an executable plan.

Leopard Project Controls also provides Time Impact Analysis and delay-analysis support. The firm’s stated services include modeling delay events, reviewing schedule effects, preparing supporting narratives, and helping project teams connect schedule analysis with contract requirements and project records.

For a team developing or reviewing a baseline, the practical starting point is the project information already available. Drawings, specifications, milestone requirements, existing schedule files, procurement logs, phasing plans, and owner comments can be reviewed together. The goal is to produce a schedule package whose dates can be understood, tested, and defended throughout the life of the project.

Concluding remarks

Dates are calculated and confidence is documented

A CPM schedule can contain thousands of activities and still leave the most important management questions unanswered. It can calculate a completion date without explaining the production rates, procurement commitments, access conditions, staffing assumptions, or owner decisions needed to achieve it. The schedule may look precise while its supporting information remains uncertain.

The Basis of Schedule closes that gap. It records how the project team developed the plan, what information was available, which assumptions were made, and where further confirmation is required. It explains the intended execution strategy in language that can be compared with the network and understood by people who do not work inside scheduling software every day.

A good document should begin during baseline development and continue to support the project after approval. It should help the team test assumptions, manage decisions, explain monthly changes, prepare recovery plans, and understand the effect of delay events. AACE International specifically recognizes the schedule basis as a record that can support baseline development, change management, schedule reconciliation, personnel transitions, and later analysis.

The schedule itself must still follow sound technical practices. Activities must be complete, logically connected, assigned realistic durations, and supported by valid calendars and constraints. The critical path must reflect the actual sequence controlling completion. GAO’s schedule guidance emphasizes that a reliable schedule should be comprehensive, well constructed, credible, and controlled throughout the project.

The strongest baseline is one that a new project manager can open months later and understand. Its assumptions are visible. Its major dates have identifiable sources. Its risks are connected to decisions. Its field sequence agrees with its CPM logic. When conditions change, the team can explain what changed and why.

Construction dates are calculated by software. Confidence in those dates comes from the quality of the plan and the discipline used to document it.

Questions and Answers