Update the working schedule every week. Never overwrite the baseline. The baseline is the plan as it stood when the contract was signed, and it is the only fixed point a delay can be measured against. Re-baselining every time dates move makes the Gantt chart look tidy and destroys the evidence. When a dispute arrives months later, nothing shows what the plan was on the day the owner's late selection or the failed inspection pushed the job. A new baseline should be rare, tied to a signed change, with the old one kept.

The baseline and the working schedule do different jobs

Most of what goes wrong in baseline schedule construction is not the first draft. It is what happens to that draft in month three, when dates have slipped and somebody decides the cleanest fix is to save over it. There are three schedule documents on a running job, and they answer different questions.

  • Baseline — the plan at contract or notice to proceed. Changes only with an approved change or a contract-required resubmittal. Answers: what was promised and when. Read by the owner, the lender and anyone reviewing a claim.
  • Working schedule — the current forecast. Changes every week with actual starts, actual finishes and remaining durations. Answers: when does this job finish now. Read by the PM, the superintendent and the subs.
  • Three-week lookahead — the near-term slice of the working schedule. Changes weekly, often in the field. Answers: who is on site Monday and what they need. Read by crews and trades. A three-week lookahead template should be pulled from the working schedule, never from the baseline.

The baseline does not get more accurate over time. It is not supposed to. Its value is that it stays wrong in exactly the way the job went wrong.

What re-baselining actually erases

Delay analysis is a comparison. Someone lays the as-built dates over the as-planned dates, finds the activities on the critical path that finished late and asks what caused each slip. Take away the as-planned dates and there is nothing to compare against.

A sequence. The baseline has cabinets installed in week 14. In week 9 the owner switches cabinet lines, and the new line ships four weeks later than the old one would have. If the working schedule is updated and the baseline is left alone, week 14 against week 18 sits in the file next to the daily log entry and the owner's email. If the baseline is saved over to show week 18, the file now says the job was always going to install cabinets in week 18. The four weeks are gone — and so is the argument for four weeks of extended general conditions.

Hiding the builder's own slips this way does not help either. A reviewer who finds four baselines in six months, none tied to a change, reads every one of them as moving the goalposts. The legitimate owner-caused delays get discounted along with the rest. Which party pays for each type of construction delay is decided by the record, and a baseline that moves with the job is not a record.

The weekly update: what moves and what stays

The working schedule should change every week. The baseline file gets opened for comparison and closed without saving. A clean update takes the same steps each time.

  1. Enter actual start and finish dates for anything that started or finished since the last update. Actuals, not what the plan hoped for.
  2. Update remaining duration on activities in progress. A superintendent's estimate of days left beats a guessed percent complete.
  3. Change logic only where the sequence actually changed on site, and write one line saying why.
  4. Compare the working schedule to the baseline. Note every critical activity now finishing later than planned and its cause: owner, design, weather, sub or the builder's own crew.
  5. Save the update as a dated copy — Update 07, data date in the file name. Never save over the previous update.
  6. Pull the lookahead from the updated working schedule and send it to the trades.

The dated updates matter as much as the baseline. A string of weekly copies shows when each slip first appeared, which is the contemporaneous record delay arguments turn on. A forecast reconstructed after the fact is easy to attack.

Re-baselining before the change order is signed. Once the new dates are in the baseline, the time impact of the change has been folded into the plan. If the owner then signs the change order for cost but not time — or rejects it — nothing in the file shows that the change moved the finish date. Price the days in the change order first. Re-baseline after it is signed, never before.

When a new baseline is legitimate

A new baseline is justified when the plan both parties agreed to has itself changed. It is not justified because the job has drifted from that plan.

  • Approved change order with a time extension that changes the critical path — added scope, a redesign, an owner-added phase.
  • Owner-directed resequencing in writing — phasing an occupied building differently or holding one wing while another proceeds.
  • A contract that requires a revised baseline submittal after a time extension. Some do, with a deadline. Read the scheduling section before assuming either way.
  • A recovery schedule both parties signed as part of settling a dispute.

Not legitimate: the job is behind. A sub missed a date. The owner meeting is Thursday and the chart looks bad. The schedule has drifted so far the bars are hard to read. The last one is the most tempting. The fix for a messy update is a cleaner working schedule, not a new baseline.

Make a re-baseline a signed event

The habit that separates a defensible schedule from a decorative one is treating a new baseline like a change order — an event with a reason, a date and a signature. Record these every time.

  1. Number baselines in sequence — BL0 at contract, then BL1, BL2. Never reuse a number. Never delete an old one.
  2. Tie each new baseline to the document that justified it: change order number, owner directive or settlement agreement.
  3. Record the variance at the moment of re-baselining — how many days the working schedule was behind the previous baseline and on which activities. That figure is exactly what the new baseline would otherwise erase.
  4. Get written acknowledgment from the owner. A baseline only the builder agreed to is a forecast, not a plan.
  5. File the native schedule file and a PDF together with the contract documents.

Done this way, re-baselining happens a handful of times on a job, or never, and each one has a paper trail explaining why. That is what makes the earlier baselines worth something when the closeout conversation turns to days.

Where BuilderSolve fits, and where it does not

In BuilderSolve the schedule is built from the estimate, so activities line up with the line items that were priced. Change orders carry an audit trail — who drafted, who approved, when. Daily logs give a dated record of what happened on the day a slip started. The AI assistant can draft a schedule shift from a log entry or a change order, but it does not move dates by itself. A person approves or rejects every draft. That matters here: a date that changes without anyone deciding to change it is how baselines get quietly corrupted.

The discipline in this article is a practice, not a button. Whatever software holds the schedule, test it once: move a date, then check whether the original plan is still recoverable and dated. If it is not, export a PDF of the approved baseline the day it is approved and file it with the contract. If the weekly update is the step that never happens, that is work the BuilderSolve operations team takes on — updates, lookaheads and RFIs — alongside the PM rather than instead of them.

What to do this week

  1. Find the baseline on every active job. If it only exists as a file that has been saved over, rebuild BL0 from the schedule exhibit in the contract or the earliest dated PDF sent to the owner.
  2. Rename it BL0 and move it to a read-only folder.
  3. Start saving dated weekly updates from this week forward, even if earlier ones are missing.
  4. On any pending change order with a time impact, hold the re-baseline until it is signed.
  5. Add two lines to the change order form: days added to completion, and whether a new baseline follows.

Common questions

what is a baseline schedule in construction

A baseline schedule is the approved plan at contract or notice to proceed, frozen so progress and delays can be measured against it. It is not the schedule crews work from day to day. That is the working schedule, updated weekly. The baseline stays fixed unless an approved change or a contract-required resubmittal justifies a new numbered version, with the old one kept on file.

how often should a construction schedule be updated

The working schedule should be updated weekly on most residential and light commercial jobs. Each update records actual starts and finishes, remaining durations and any logic changes, and is saved as a dated copy rather than over the previous one. The baseline is not updated weekly. It is opened for comparison and closed without saving, so the original plan survives every update.

when should you re-baseline a construction schedule

Re-baseline only when the agreed plan has changed: an approved change order with a time extension, a written owner directive to resequence, a contract requirement to resubmit or a signed recovery schedule. Do it after the change is signed, not before. Number the new baseline, tie it to the justifying document, record the variance at that moment and keep every earlier version.

can I change the baseline schedule if the project is behind

No. Being behind is exactly what the baseline exists to show. Overwriting it hides the variance, including any owner-caused delay that would support a time extension or extended general conditions. Update the working schedule to show the current forecast and note the cause of each critical slip. If the updates have become hard to read, clean up the working schedule instead.

what happens to a delay claim without a baseline schedule

Without a baseline there is no as-planned schedule to compare as-built dates against, so the delay has to be argued from reconstruction, which is easier to dispute. Daily logs, dated weekly updates and correspondence still help. If the baseline was saved over, rebuild it from the contract schedule exhibit or the earliest dated copy sent to the owner, and file it as BL0.