DCMA-14 Metric 5 — Hard Constraints: What They Hide in Your Schedule

Hard constraints in Primavera P6 are Mandatory Start and Mandatory Finish, which force an activity to a fixed date regardless of predecessor logic. They hide real logic gaps and can generate negative float, which is why the DCMA 14-point assessment limits constraints to 5% of incomplete tasks. DCMA's own list of hard constraints is broader than P6's, so be explicit about which definition you use.

What counts as a hard constraint?

Two lists exist, and they overlap only partly.

The DCMA pamphlet treats these as hard because they "may prevent tasks from being moved by their dependencies":

• Must-Finish-On
• Must-Start-On
• Start-No-Later-Than
• Finish-No-Later-Than

It treats As Soon As Possible, Start-No-Earlier-Than and Finish-No-Earlier-Than as soft.

Oracle's P6 data dictionary draws the line differently. It says "hard constraints available are Mandatory Start and Mandatory Finish." The soft ones are Start On, Start On or Before, Start On or After, Finish On, Finish On or Before, and Finish On or After. Oracle says hard constraints prevent activities from being moved, and soft ones can distort float.

Analysis tools also differ. Reports exist of the P6 schedule check treating different sets of constraints as hard, so confirm what your tool counts before quoting a percentage. Mosaic Projects' white paper lists yet another variant, which is a reminder to cite the definition.

What is the DCMA threshold, and how is it calculated?

The formula is:

Hard Constraint % = incomplete tasks with hard constraints ÷ incomplete tasks

The pamphlet's limit is 5%. Its population excludes completed tasks, level-of-effort tasks, summary tasks and milestones. Illustrative example: with 250 incomplete detail tasks, 5% allows 12 hard-constrained tasks (12 ÷ 250 = 4.8%). A project with 15 would be at 6.0% and flagged.

Milestones matter here. A scheduler who puts Finish-No-Later-Than constraints on contractual milestones may have no constrained detail tasks at all under the pamphlet's population, yet those constraints still drive the dates. The 5% figure is a screen. It does not substitute for looking at where the constraints sit.

What do mandatory constraints actually do to the network?

A mandatory date overrides the forward and backward pass. P6 will schedule the activity on the constraint date even if its predecessors finish later, or earlier. Three effects follow.

Logic stops driving dates. If a predecessor slips past the constraint date, the successor does not move. The schedule shows the activity starting before its predecessor ends, and the delay disappears from the critical path.

Negative float appears. When logic wants a later date than the constraint allows, the late dates are pinned to the constraint and float drops below zero. Oracle's help says negative float arises when a constraint or actual date makes the schedule shorter than the critical path requires. Oracle also notes that a Mandatory Finish on non-work time leaves early and late dates unequal, which can cause negative float on its own. The negative float article covers diagnosis.

Missing logic is masked. A constrained activity looks scheduled whether or not it is tied into the network. That is why constraints and the logic metric belong in the same review.

Example: a mandatory finish hides a delay

Illustrative example with assumed dates and durations.

If C100 slips by 6 days, C110's logic finish moves to day 31, but the mandatory date holds it at day 28. The activity ends before the logic says its work is done, and the network understates the delay. The schedule doesn't flag that C110 will be late, and the critical path may not even pass through it.

Why do schedulers use hard constraints?

Constraints usually enter a schedule for one of five reasons:

• A contract date for completion or a milestone.
• An external event, such as a utility outage window or an owner move date.
• Weather or seasonal windows.
• Pressure to show a date that logic cannot reach.
• Use as a shortcut instead of building logic for work with an unknown predecessor.

The first three can be real. The last two are the problem, and they are what reviewers hunt for. GAO's Schedule Assessment Guide advises minimizing and justifying date constraints, with hard constraints used only when the documentation supports them.

How do I find hard constraints in P6?

Filter activities by constraint type, and also look at the project-level settings. A project can carry a Must Finish By date, which is an optional constraint on the project end, separate from activity constraints. Use a layout that shows constraint type and constraint date columns, then filter to incomplete activities and group by constraint type.

Record each one with its WBS location and the reason. The count of mandatory constraints versus other date constraints often tells you how the schedule was built: a few mandatory dates near the end usually reflect contract milestones, while scattered ones in the middle usually reflect patching.

Which constraint types are safe to keep?

Soft constraints still deserve scrutiny, but they behave more predictably because logic can move the activity later than the constraint date.

A Start On or After constraint can still push float around, which is Oracle's point about soft constraints distorting float, but it can't force a date earlier than logic allows. That is the practical difference between the two groups.

What will a reviewer ask about constraints?

Expect a short list of questions. How many constrained tasks are there, and which definition of hard did you use? For each mandatory date, what is the contractual or physical basis? Do any constrained activities show negative float? And what happens to the finish date if the constraints are removed?

The last question is the telling one. If removing every mandatory constraint moves the finish date, those constraints are carrying schedule. Run the test on a copy and keep the result with the submittal.

Constraints and the other DCMA metrics

Constraints interact with several checks. They distort lags when lags are added to line up with a fixed date. They can suppress float, so a schedule with many constraints may look clean on the high float check while its dates are not logic-driven. And they produce the negative float the pamphlet wants explained, with a corrective action plan, for each affected task.

How do I replace hard constraints with logic?

Ask what the constraint represents, then model that.

1. A real predecessor is missing. Add the link. Often this is an owner decision, a permit, or a delivery, and a milestone representing it is the clean fix.
2. A date cannot start earlier. Use a soft Start On or After constraint (the SNET type in DCMA's list) so logic can still push the activity later.
3. A contractual completion date. Put it on the project as a Must Finish By, or on a finish milestone, and let float show the result. A constraint on the milestone gives negative float when logic cannot meet it, which is the right signal.
4. A date that was simply forced. Remove it and reschedule. If dates move, report the change to the project team.

After removing a batch of constraints, reschedule and compare the finish date and the critical path. Document each one that remains, with the basis, so the narrative can answer the 5% question and the reason behind each constraint in one place.