A baseline schedule sets the reference point every future schedule update, every delay analysis, and every claim will be measured against. Accepting a flawed baseline doesn’t just create a bad plan. It creates a bad measuring stick that stays bad for the rest of the project, and it’s far cheaper to catch these problems during baseline review than to discover them eighteen months later during a dispute over whose fault a delay was.

Here are twelve specific things worth rejecting, or at minimum requiring correction, before a baseline gets accepted.

1. Open Ends in the Logic Network

Every activity should have at least one predecessor and one successor, with the exception of the schedule’s true start and finish milestones. An activity with no predecessor, sometimes called a dangling start, or no successor, a dangling finish, isn’t properly integrated into the network logic, which means changes elsewhere in the schedule won’t correctly propagate to it, and its actual effect on the critical path is unreliable.

2. Excessive Use of Constraints Instead of Logic

Date constraints, like a hard “must finish by” or “start no earlier than,” override what the network logic would otherwise calculate. A small number of legitimately externally driven dates is normal. A schedule where a large share of activities carry hard constraints is a schedule where the actual driving logic is hidden behind imposed dates, making it difficult to tell what’s really driving the finish date versus what’s simply been forced to an assumed date.

3. Negative Lag Used to Compress Duration

Negative lag, showing a successor activity starting before its predecessor is complete, is sometimes legitimate for genuine overlap between activities. Used extensively or without clear justification, it’s frequently a way to make a schedule appear shorter than the underlying logic actually supports, artificially compressing a critical path that would otherwise show a later, less favorable finish date.

4. Zero or Near-Zero Float on a Large Share of Activities

A healthy schedule typically shows a range of float values across different paths, with only the genuine critical path at zero. A baseline where a large percentage of activities show zero or near-zero float suggests either a schedule with almost no real contingency anywhere, a legitimate but serious risk worth flagging, or a schedule that’s been artificially manipulated to show many paths as equally critical, which can be used later to argue that almost any delay affected the critical path.

5. Missing Long-Lead Procurement as Distinct Activities

Major equipment procurement, the kind discussed in our related pieces on data center and water infrastructure lead times, should appear as its own detailed activity sequence, submittal, approval, fabrication, delivery, not folded into a generic “procurement” bar with a duration that doesn’t reflect actual current market lead times for the specific equipment involved.

6. Activity Durations Not Tied to Resource Loading

A duration should reflect a specific crew size and productivity rate, at least implicitly. A schedule with no resource loading at all, where durations appear to be pulled from a generic template rather than derived from an actual planned crew and productivity assumption, is a schedule that can’t be meaningfully stress-tested against a resourcing change, because the underlying assumption was never made explicit in the first place.

7. No Resource Leveling Across Concurrent Activities

Even with individually reasonable durations, a schedule that shows multiple activities running concurrently, each assuming full access to the same limited pool of skilled labor or equipment, without leveling that demand against actual available resources, is assuming a resourcing capacity the contractor may not actually have. This is the same shared-resource blind spot that shows up at the portfolio level across a whole program, just occurring within a single project’s own schedule.

8. A Critical Path That Avoids the Genuinely High-Risk Scope

If the mathematically critical path runs through low-risk, well-precedented activities while genuinely uncertain scope, a novel commissioning sequence, an unresolved design element, a long-lead item with real lead time risk, shows comfortable float, that’s worth real scrutiny. It can indicate the schedule’s logic has been structured, intentionally or not, to keep the highest-risk scope looking safely non-critical.

9. Missing Cost Loading Where the Contract Requires It

If the contract calls for a cost-loaded schedule, verify the cost loading is actually complete and reasonably distributed across the schedule’s duration, not front-loaded or back-loaded in a way that doesn’t reflect when costs will genuinely be incurred, since a cost curve that doesn’t match true cash flow undermines the schedule’s usefulness for progress payment evaluation.

10. A Level of Detail Too Coarse to Actually Manage

A baseline that’s essentially a milestone list, a handful of large summary activities each spanning months, isn’t detailed enough to support meaningful progress tracking or early problem identification. If individual activities span durations longer than the planned reporting interval, there’s no way to catch a problem within that activity before the whole activity is already late.

11. No Basis of Schedule Narrative

A baseline submitted without an accompanying narrative explaining key assumptions, planned crew sizes, assumed productivity rates, weather assumptions, key sequencing decisions and why they were made, leaves the owner unable to evaluate whether the schedule’s assumptions are actually reasonable, only whether the resulting dates look acceptable on their face.

12. Calendar Assumptions That Don’t Match Realistic Working Conditions

Verify the schedule’s calendars reflect realistic working days, holidays, and any known constraints, like blackout periods for specific activities near sensitive operations, discussed in more detail in our sector-specific pieces on shutdown windows and outage constraints. A schedule built on an idealized five-day, no-holiday calendar when the actual project will operate under real constraints is calculating dates against a calendar that doesn’t match reality.

What to Do With This List

None of these twelve items, found in isolation, is necessarily disqualifying on its own. Found in combination, or found without a reasonable explanation when questioned, they’re a strong signal that the baseline hasn’t been built with the rigor an owner should require before accepting it as the reference point for the rest of the project. The right response to finding several of these isn’t necessarily outright rejection. It’s requiring correction and resubmission before the baseline is formally accepted, because the cost of catching these issues now is a fraction of the cost of relying on a flawed baseline for the next eighteen months.