Why Your Baseline Got Rejected: 7 Things Reviewers Check First

Most baselines are rejected in the first hour, before anyone forms an opinion about the sequence. The reviewer opens the file, runs the scheduling report, sorts three or four columns, and has enough mechanical defects to send it back with comments. On a project with liquidated damages, that is a four-week loop you pay for with your own float.

The first pass is predictable, though. Consultants, PMCs and employer representatives check the same seven things in roughly the same order, because those seven decide whether the schedule can carry monthly progress measurement and, later, an extension of time claim. Clear them before you submit and most of the comment sheet disappears.

1. Open ends and dangling logic

This is checked first because it takes ten seconds. In Primavera P6, schedule the project (F9) and read the log — it reports activities without predecessors and without successors. In Microsoft Project there is no equivalent log: add the Predecessors and Successors columns and filter or sort for blanks.

Only two activities should be open: project start and project completion. Everything else needs both ends tied. Reviewers also look for dangling logic that a raw count misses — an activity tied on the front by a start-to-start link with nothing driven off its finish, so its duration can stretch without pushing anything downstream. A 90-day activity with a dangling finish is not a plan, it is a placeholder.

2. Constraints, leads and lags

Hard constraints override logic, and reviewers know it. In P6 that means Mandatory Start and Mandatory Finish; in MS Project, Must Start On and Must Finish On. These should be zero in a baseline. If a contractual date has to bite, use Finish On or Before in P6 or a Deadline in MS Project — both generate negative float when you slip instead of silently freezing the network.

Then leads and lags. Negative lag is an automatic comment: it lets a successor start ahead of its own logic and it corrupts retained-logic delay analysis later. Long positive lags hide work — a 28-day lag for concrete curing is an activity, not a link property. Check which calendar your lags run on: in P6 that is set in Schedule Options (default is the predecessor activity calendar), and a lag calculated on a 7-day basis inside a 6-day chain will drift by days across a long sequence.

3. Durations that cannot be defended

The common threshold is 44 working days, with no more than about 5% of activities above it and none at all inside the detailed near-term window. The real test is different: the reviewer picks five or six durations at random and asks how you got them. If the answer is not quantity ÷ (crew output × number of crews × hours), it comes back. Record the basis in a notebook topic (P6) or a task note (MS Project) — ten minutes there saves a revision cycle.

Watch the other tail too. One-day activities are fine, but a baseline built from 400 of them is unupdatable and signals a schedule drawn to produce a bar-chart shape rather than to be progressed.

4. Calendars

Calendar errors are the quietest cause of rejection, because everything looks correct on screen. The usual findings: activities left on the default 5-day calendar when the site works six days; public holidays and reduced-hours periods not loaded; curing, testing and shutdown activities not on a 24-hour or 7-day calendar; and, in P6, a global calendar someone else on the same database has edited. In MS Project, confirm the project calendar, any task calendars, and whether the schedule is set to ignore resource calendars.

Mixed calendars also distort total float, which sets up the sixth check.

5. Resource and cost loading gaps

Where the contract requires a loaded baseline, the reviewer reconciles two numbers before anything else: total budgeted cost against the contract value, and the manpower histogram against what you can physically mobilise. The recurring rejections are unloaded activities (procurement and testing, usually), front-loading that pushes 40% of value into the first 20% of the programme, and a labour peak the accommodation, induction and permit process cannot support. Export the S-curve and look at it yourself first.

6. A critical path that does not make engineering sense

Run the longest path — in P6 use the Longest Path setting rather than total float ≤ 0, especially where calendars and constraints are mixed; in MS Project, check driving logic through Task Path. Then read the path out loud. If it runs through a minor procurement item or through boundary fencing while the main structure sits on 30 days of float, either the logic or the durations are wrong. And a baseline showing negative float on day one is rejected on sight: a baseline cannot start late.

7. WBS and coding structure

The WBS should mirror the contract — BOQ sections, the payment breakdown, the sectional completion dates. If the reviewer cannot roll your schedule up to the same headings they use to certify payment, they will ask you to restructure it, and that is the most expensive comment on the sheet. Add activity codes (P6) or custom fields (MS Project) for area, discipline, subcontractor and phase, so the same file serves a site meeting today and a variation claim next year.

Where to run each check

The reviewer is not asking whether you can build the job. They are asking whether this file can measure progress every month and still stand up as evidence eighteen months from now. All seven checks are versions of that one question.

Pre-submission checklist

1. Schedule the file and clear the log — no activities without predecessors or successors except project start and finish.
2. Scan for dangling starts and finishes, not just missing links.
3. Zero Mandatory / Must-type constraints; contractual dates expressed as Finish On or Before, or as a Deadline.
4. Zero negative lags; every lag beyond a few days justified or converted into an activity.
5. Lag calendar and default activity calendar confirmed in Schedule Options.
6. Under ~5% of activities over 44 days; basis of duration recorded for the twenty longest.
7. Weekend pattern, holidays and shift hours loaded in every calendar actually in use.
8. Total budgeted cost reconciles to contract value; no unloaded activities where loading is required.
9. S-curve and manpower histogram printed and sanity-checked against mobilisation.
10. Longest path exported and read end to end — it should describe how you genuinely intend to build.
11. No negative float anywhere in the baseline.
12. WBS rolls up to the payment breakdown and the sectional completion milestones.
13. Basis of schedule narrative attached: assumptions, calendars, productivity rates, exclusions, access dates relied on.

The narrative is the item most contractors skip and the one that most often converts a rejection into a comment. A reviewer who can read why you built it this way will argue with your assumptions instead of your file — and assumptions can be answered in a letter, not a resubmission.