Scheduling constraints and negative float: which dates belong in the plan and how to recover the days

When the US Government Accountability Office (GAO) analysed the schedule of the Army's Global Combat Support System, 1,360 activities, 60 percent of the plan, carried a “start no earlier than” constraint. Of those, 87 percent were actively holding the start date: without the constraint, the activity might have started sooner^[1]. In everyday plans such constraints arrive one at a time, from a bar dragged to where someone expects the work to start or a date copied out of a spreadsheet.

This guide separates the few scheduling constraints a plan needs from the many that stand in for a missing dependency. Then it reads negative float as a count of working days to recover, on a museum exhibition whose schedule lands two days after the press opening.

What scheduling constraints and negative float are#

A scheduling constraint is a date limit on a task's start or finish that can override the task's dependencies. Constraints exist because a few dates are fixed outside the plan, such as the day a lender's courier delivers. Anywhere else they keep tasks still while the work around them moves: the GAO's Schedule Assessment Guide warns that they “can cause false dates in a schedule” and can imply a false level of criticality^[1]. In the worked example below, one typed start date gives a lighting task 3 days of float when it really has 1.

Negative float is the number of working days by which the linked work misses a constrained date or a deadline. GAO-16-89G defines negative total float as the time that must be recovered so as not to delay the finish beyond the constrained date, and counts any activity with zero or negative total float as critical^[2]. Microsoft Project calls float “slack”, and a task scheduled to finish after its deadline shows negative slack there^[3]. On any task, then, −2 days means two working days to take out of the chain leading to it. Or a later date.

How float itself is calculated, with the forward and backward pass, is covered in the critical path method guide.

Who needs to check constraints, and when#

Check constraints before the baseline is saved and after every import from another tool, on any dependency-linked plan of 30 tasks or more. In a team of 4 to 15 people the project manager runs the check; on programmes with a dedicated planner, the planner does. Team leads read the result to learn whether the date on their task is real. Sponsors and clients need one number from it, the negative float on the final milestone, because that is how many working days the plan is short of the date they were promised.

Imports need the check because typed dates become constraints. Project assigns “start no earlier than” to any date entered in the Start field^[4]. Planitude does the same when a bar is dragged in a plan scheduled from its start date; in a plan scheduled backwards from its finish date, the drag sets “start no later than”. So a plan built by typing a date into every row arrives with a constraint on every row, whichever tool it came from.

Run the check again the first time a status update shows negative float, before anyone promises a recovery.

Skip it for small plans. Under about 15 tasks, kept by one person who re-plans every week, whoever typed each date still remembers why.

The eight constraint types and what they do to float#

Microsoft Project has eight constraint types^[4] and Planitude uses the same eight; two of them, “as soon as possible” and “as late as possible”, carry no date. The GAO splits the six dated ones into soft and hard^[1]. Soft constraints stop a task moving earlier and let it slip with its predecessors. A hard constraint holds its date when the work before it runs late, so the link is overridden and the shortfall shows up as negative float on the tasks before it.

The split assumes a plan scheduled forward. Under backward scheduling, the GAO counts “finish no earlier than” as hard^[1].

The “must” pair is the most rigid. By setting a task's early and late dates equal, a mandatory constraint removes all of its float at once^[1], so the task can neither gain time from early predecessors nor slip with late ones. With any of the four hard types, Planitude keeps the task on its date when a predecessor finishes later and reports that the constraint overrides one of its links. Manually scheduled tasks freeze dates in a similar way: they keep the start and finish they were given, whatever their predecessors do.

A deadline sits outside the table: it doesn't affect how tasks are scheduled^[4], yet a task forecast to finish after it shows negative slack^[3]. The milestones guide explains why a promised date belongs in a deadline.

When a constraint is legitimate and when it hides missing logic#

A constraint is legitimate when its date is set by someone outside the project team and no predecessor in the plan would produce that date; anything else is a dependency typed by hand. That is also the GAO's test: a “start no earlier than” constraint is valuable “when an activity cannot start any earlier than a fixed date and has no other logical dependencies”, for example a production line that stays unavailable until an outside entity has finished with it^[1].

Most constraints in real plans fail that test, for understandable reasons. A contract date is the date everyone remembers, so it gets typed onto the last task. And when the only technician is busy until the 15th and the plan has no resources, dragging the next bar to the 15th is the quickest way to say “wait”.

Both habits are rejected in the same guide. A customer-mandated date, contractual obligations included, “does not constitute a legitimate reason to constrain an activity”^[1], so it goes on a milestone as a deadline. A constraint used to wait for a person forces tasks into a sequence that remains after more people are added^[1]. In the exhibition below, holding object installation until the technician is free would keep that order even after a second installation team is hired. In the GCSS-Army case, programme officials said the constraints had been used to allocate resources by hand^[1].

Closures are calendar entries. Suspensions of work for weather belong in the working calendar as non-working periods^[1], and a week when the galleries are shut for maintenance goes in the project calendar the same way.

Four signs give a hidden link away:

1. The constraint date is the working day after another task's finish. Someone did by hand the arithmetic a finish-to-start dependency does automatically, and the two dates drift apart at the first slip.
2. A constrained task has no predecessor, although the work that physically comes before it is in the plan, as with the lighting and the walls in the example.
3. The date came from a dragged bar or an imported file, and nobody can name the person outside the team who set it.
4. Several tasks share the same constraint date.

Even a real outside date can deserve more than a constraint. For a supplier delivery, the guide suggests modelling the whole procurement process, from the order to the receipt, as one or more activities, so that progress can be tracked and risk applied to it^[1].

Our recommendation: write the source of every constraint date in the task notes, with a name and a day to recheck it, and replace any constraint whose source cannot be named with a link. The exception is the small plan described above, under about 15 tasks with one owner, where the notes take longer to write than the dates take to recheck. As a rule of thumb, when more than 1 task in 20 carries a constraint other than “as soon as possible”, review all of them before the next baseline.

A worked example: a museum exhibition that opens two days late#

The schedule below forecasts the press opening on day 25, two working days after the day-23 deadline, and its worst float, −2 days, runs through the lender's delivery.

A city museum is preparing a temporary exhibition with objects on loan from another museum. The team works Monday to Friday, with no holidays in the period. Day 1 is Monday 1 February 2027. The press opening is booked for Wednesday 3 March 2027, day 23, and entered as a deadline on the opening milestone.

Two tasks carry a “start no earlier than” constraint. The receipt of the loans (task D) waits for the lender's courier, who travels with the crates and arrives on day 16 (Monday 22 February); each object is then checked against its condition report in the courier's presence. The lender fixed that date. Lighting (task F) has the other constraint, typed in for day 14 in an earlier draft, when the walls were still due to finish on day 13.

Forward pass. Only two tasks wait on more than one predecessor. E needs the walls (finished on day 15) and the objects (on site on day 16), so it starts on day 17 and ends on day 22. G waits for E, the last of its three predecessors to finish, and runs on days 23–25. The opening lands on Friday 5 March.

Backward pass. Count back from the deadline. The opening must finish by day 23, so G must start by day 21 and E must finish by day 20. E's latest start is then day 15, which means D and B both have to finish by day 14, and A by day 4. Total float is late finish minus early finish.

Two chains carry negative float, and they meet at E. The courier date puts D, E and G at −2. Walls finishing on day 15 put A and B at −1: even with the objects on site in time, the chain A, B, E, G adds up to 5 + 10 + 6 + 3 = 24 days, one more than the deadline allows.

Lighting should follow the walls, because electricians cannot fix lighting tracks to walls that are still being built. With a finish-to-start link from B, F runs on days 16–19 and has 1 day of float; on its typed date it overlaps wall building on days 14 and 15 and shows 3. The plan reports no conflict, since there is no link for the typed date to break. Replacing the constraint with the link leaves the opening on day 25. The courier constraint stays.

With F linked, three recovery options were calculated:

An earlier courier recovers one day of the two. Once D lands on day 14, the walls finishing on day 15 decide when E can start, and the A–B chain at −1 becomes the binding one.

Option 2 works on E, after the point where the two chains merge, so a single change shortens both. In this constructed example the second team is two technicians from a fine-art handling firm, booked for the 4 days of installation, and the loan agreement allows outside handlers once the courier has approved them. Installation then costs 8 team-days against 6, because two teams sharing the same rooms and cases lose time waiting for each other. Shortening the walls alone would recover nothing while the courier holds E until day 17.

How to recover negative float, step by step#

Recover negative float from the most negative value upwards, and only once the value is known to be real.

1. Sort the tasks by total float, most negative first. GAO-16-89G asks for the remaining activities to be sorted by total float and for every activity with negative float to be questioned^[2]; what you get is a list of chains, each with its value.
2. Test every constraint on those chains against the four signs above. Typed dates become links. Contract dates move from “must finish on” to a deadline.
3. Recalculate. In the example this leaves the courier chain D, E, G at −2 and the wall chain A, B at −1, merging into E.
4. Shorten the work after the merge point first, since one change there shortens every chain that passes through it. The guide to recovering a delayed project compares fast-tracking and crashing.
5. Recalculate after each change, because another chain may now set the finish, as the walls did once the courier moved to day 14.
6. If the days cannot be found, move the forecast: when negative float cannot be mitigated, the milestone should forecast a slip that removes it^[2]. Give the sponsor the number of working days and the chain responsible.

Common mistakes#

The most damaging mistake in the exhibition plan is a constraint left behind by an edit, and it overstates the float on lighting by 2 days. Lighting was typed in for day 14 as a reasonable guess. The walls then grew by two days and nobody touched the typed date, so lighting now overlaps wall building on days 14 and 15 and its float reads 3 days where the real figure is 1.

Recovering on one branch of a merge comes next. Faster wall building gains nothing here.

Soft constraints that no longer bite are easy to miss. A “start no earlier than” whose date is already earlier than the links allow does nothing today, and it starts holding the task back on the day its predecessors speed up. Such constraints should be removed from the schedule^[1].

Reading negative float as one owner's problem is the last trap. The value belongs to the chain: task A shows −1, yet finishing it a day early changes nothing while the courier holds E until day 17.

When negative float is the wrong number to chase#

Chase negative float only when the date behind it is legitimate and the logic leading to it is complete.

Activities performed in a different order from the network logic also produce negative float^[2]. Correct the links so they describe what actually happened. Then read the float again.

A hard constraint can also be a deliberate test. During schedule development, the GAO suggests hard constraints as a temporary working tool to calculate the float available up to key milestones and to check whether the available resources can meet the planned date^[1]. Our recommendation: before the baseline is saved, turn each of those temporary constraints into a deadline on the same milestone. The target stays visible as negative float, and no link is overridden.

After option 2 the opening has 0 days of float, and every duration in the plan is a single estimate, so a one-day slip on D, E or G moves the opening to day 24. A Monte Carlo schedule risk analysis shows how likely day 23 really is. Option 3 keeps 1 day of float if the lender agrees to the earlier courier.

How to do it in Planitude#

Open the task panel: the Constraints section offers the eight types above and a Deadline field, which caps the task's latest finish without moving the bar, so a forecast past it shows as negative float. Dragging a bar sets “start no earlier than”, or “start no later than” in a plan scheduled backwards; “As soon as possible” gives the date back to the links. With the critical path on in the Gantt chart, tasks with zero or negative float are highlighted and the task panel shows each one's total float.

The conflict panel of a forward plan lists every task with negative float and every missed deadline. A hard constraint that overrides a link gets its own entry. Manually scheduled tasks imported from a Microsoft Project file keep their dates and are flagged if they start too early. During tracking, a link turns red when a delay exceeds the float that could absorb it.

The grid has no constraint or float column, so step 1 runs through these two panels. Nothing crashes durations or levels resources automatically.

Frequently asked questions#