Constraints in P6: When They Help and When They Lie

A schedule is a model. Logic is what makes it a model: change something at the front and the consequences arrive at the back on their own. A constraint is an instruction to ignore that — to hold a date whatever the logic says.

Sometimes that instruction is legitimate. Most of the time, in the schedules I audit, it is a planner solving today’s problem by silencing tomorrow’s warning.

The constraint types, in two groups

P6 offers several constraint types, and the useful way to sort them is not alphabetical — it is by how much damage they can do.

Soft constraints shift dates in one direction and leave the network able to react:

• Start On or After / Finish On or After — earliest dates. The activity cannot start before a date, but can still be pushed later by logic.
• Start On or Before / Finish On or Before — latest dates. They do not move early dates at all; they create negative float when the forecast slips past them. That is a feature, not a fault.
• As Late As Possible — pulls an activity to consume its free float.

Hard constraints override the network:

• Start On / Finish On — pin a date in both directions.
• Mandatory Start / Mandatory Finish — the strongest form. These override relationship logic outright. A predecessor can finish late and the mandatory-constrained activity will still sit exactly where it was told, as if nothing happened upstream.

That last sentence is the entire problem.

The two cases where a constraint is right

I am not a constraint absolutist. There are two situations where reaching for one is the correct engineering decision.

1. A genuine external gate you do not control. Site access on a fixed date, a permit that cannot be issued before a known date, a vessel that arrives when it arrives. Start On or After models this honestly: the work cannot begin earlier, but if the project slips, the activity still moves later like everything else.

Even here, ask one question first: can I model this with an activity instead? A “Permit issued” milestone with real predecessors tells a richer story than a date pinned to the activity that follows it — because next month, when the permit is late, the schedule shows why.

2. A contractual deadline you want to measure against. A Finish On or Before on a sectional completion milestone does not move anything. It sits there quietly and, the moment your forecast pushes past the contract date, it produces negative float. That is precisely the alarm you want, and it is the one constraint type I actively recommend adding.

Notice both are soft. Neither overrides logic; both leave the model able to tell you the truth.

The anti-patterns

Constraint instead of missing logic. The activity should start in March, but the network says May because a predecessor is missing. Adding Start On fixes the bar chart in ten seconds; adding the missing relationship takes ten minutes and fixes the schedule. Only one of those survives the next update.

Constraints to defend a date in a meeting. The programme has to show completion in Q3, so completion gets pinned. Every subsequent update reports on time, right up until the month it obviously cannot be. Schedules that never show bad news stop being read — which is a worse outcome for the planner than the bad news would have been.

Mandatory constraints inherited from someone else. Very common in schedules received from subcontractors or lifted from a template. Nobody chose them; they came with the file, and they quietly disconnect parts of the network from the rest.

As Late As Possible everywhere. It zeroes out free float, so every activity looks urgent, so nothing looks urgent. Use it for genuine just-in-time work — deliveries you do not want to store on site — and nowhere else.

Finding what you have

Two habits, both cheap:

1. Add a Constraint Type column and a Primary Constraint Date column to a layout, then sort by them. Ten seconds, and you see every pinned date in the project. In most schedules I audit, the planner is surprised by at least a third of the list.
2. Read the schedule log after every F9. P6 tells you how many activities carry constraints, how many have negative float and which ones scheduled out of sequence. It is the cheapest quality report in the product and almost nobody opens it.

For a formal threshold, the DCMA 14-point assessment expects zero hard constraints and no more than 5% soft ones. P6 Professional can run those checks for you — which is the subject of the next post.

The test I apply in audits

For every constraint in the schedule, one question: if the work upstream slips by a month, does this date still make sense?

If the answer is yes — an immovable external gate, a contract date you are measuring against — the constraint is doing its job. If the answer is “well, no, but that date is what we promised”, you are not looking at a constraint. You are looking at a wish, written into the model in a way that prevents the model from arguing back.

Sorting that out across a whole programme is a large part of what a system and schedule audit actually delivers: not a list of violations, but a schedule that reacts to reality again.