The DCMA hard constraints check measures the percentage of incomplete activities restricted by Must Start On, Must Finish On, Start No Later Than, or Finish No Later Than dates. The commonly applied goal is to keep these constraints below 5 percent of the incomplete activity population.
A result above the threshold does not automatically prove that the schedule is invalid. Instead, it flags a network that may rely too heavily on imposed dates rather than durations, logic, calendars, and resource assumptions. Each flagged constraint requires review because it can distort float, conceal a forecast problem, or prevent the schedule from responding correctly to progress.
What the DCMA hard constraints check measures
The hard constraints metric is one of the checks associated with the DCMA 14-Point Schedule Assessment. It examines incomplete activities and milestones for constraint types that restrict movement toward a later date.
The standard calculation is:
Hard Constraint Percentage = Incomplete discrete activities with hard constraints ÷ Total incomplete discrete activities × 100
For example, assume an Integrated Master Schedule (IMS) contains 240 incomplete discrete activities. Nine have hard constraints:
9 ÷ 240 × 100 = 3.75 percent
That result falls below the commonly used 5 percent threshold. However, the scheduler should still examine the nine constraints. A low percentage does not make an inappropriate constraint acceptable, especially if it sits on a key delivery path.
The denominator can vary between assessment tools or customer instructions. Some implementations exclude completed work, summary rows, level-of-effort activities, planning packages, or other non-discrete records. Therefore, confirm the activity population and metric configuration before comparing results from Microsoft Project, Deltek Acumen, or another analysis tool. Deltek’s DCMA metric documentation, for example, describes its calculation and applicable activity population.
Which constraint types count as hard constraints?
The DCMA-style metric generally classifies the following four constraint types as hard constraints:
- Must Start On (MSO): The activity must start on one specified date.
- Must Finish On (MFO): The activity must finish on one specified date.
- Start No Later Than (SNLT): The activity cannot start after the constraint date.
- Finish No Later Than (FNLT): The activity cannot finish after the constraint date.
The Defense Acquisition University Project and Program Management Fundamentals Handbook identifies these four types in its explanation of the metric. It classifies As Soon As Possible, As Late As Possible, Start No Earlier Than, and Finish No Earlier Than as soft constraints for this assessment.
Why Microsoft Project terminology can cause confusion
Microsoft Project groups its eight constraint types as flexible, semi-flexible, or inflexible. Microsoft calls MSO and MFO inflexible, while it calls SNLT and FNLT semi-flexible.
That terminology does not change the DCMA calculation. A DCMA-style hard constraints check normally counts SNLT and FNLT because they restrict the backward pass and prevent an activity from moving later than the imposed date. Therefore, do not configure a filter to find only Microsoft’s two inflexible constraint types.
Likewise, Start No Earlier Than and Finish No Earlier Than constraints do not normally count in this specific metric. However, they can still affect the forward pass, float, and schedule realism. They require separate review even when the DCMA hard constraint percentage remains green.
For a broader comparison, see hard constraints versus soft constraints in scheduling.
Why hard constraints weaken a logic-driven schedule
A Critical Path Method schedule should calculate dates from network logic, activity durations, calendars, and status. Hard constraints interfere with that calculation by imposing an external date boundary.
Must Start On and Must Finish On constraints create the greatest concern. They anchor an activity to one date even when predecessor performance suggests that the date is no longer achievable. As a result, the schedule may display a date rather than calculate a credible forecast.
SNLT and FNLT constraints act differently. They allow earlier movement but restrict later movement. Therefore, they can generate negative float or produce misleading late dates when the network forecasts work beyond the imposed boundary.
The GAO Schedule Assessment Guide explains that constraints override network logic and restrict how planned dates respond to completed work or resource availability. GAO also warns that schedules with excessive constraints can look more like fixed calendars than dynamic management models.
Hard constraints can affect several areas of schedule analysis:
- Critical path identification: A constrained milestone can create an artificial endpoint or interrupt a continuous driving path.
- Total float: The constraint may force float to calculate against an imposed date instead of the unconstrained network finish.
- Forecast credibility: A fixed date can conceal the date that predecessor logic would otherwise calculate.
- Schedule risk analysis: A constrained activity may not move when simulated predecessor durations change, which can understate finish-date exposure.
- Management decisions: Summary reports may continue to show a required date without clearly displaying the recovery needed to achieve it.
Constraints can also contribute to negative float. However, removing a constraint merely to eliminate negative float can hide a genuine schedule problem. The scheduler must preserve the required date as a visible target while allowing the network to show the current forecast.
The 5 percent threshold is not a universal contract requirement
The hard constraints threshold is a schedule-health benchmark, not a stand-alone clause that automatically applies to every federal contract. FAR Subpart 34.2 addresses Earned Value Management System and Integrated Baseline Review policy, but it does not establish a universal 5 percent hard-constraint limit for every contractor schedule.
The Federal Acquisition Regulation provisions for EVMS and IBRs focus on effective integrated technical, schedule, cost, resource, and baseline control. The specific schedule submission and assessment criteria can come from the solicitation, contract, Contract Data Requirements List, data item description, agency guidance, or program-tailored surveillance plan.
Therefore, determine what your governing documents require. A customer may use the DCMA metric as an evaluation factor, a monthly health indicator, a proposal instruction, or a surveillance trigger. Another program may tailor the threshold or require written justification for every constraint regardless of the percentage.
This distinction matters during proposal development. If a solicitation directs offerors to explain hard constraints, an unexplained constraint can become an evaluation weakness even when the overall percentage appears acceptable. Proposal teams should treat the solicitation instructions and evaluation criteria as controlling.
A practical hard-constraint review process
1. Confirm the metric population
First, identify which records the assessment includes. Confirm the treatment of milestones, summary tasks, completed activities, planning packages, level-of-effort work, and external schedules. Otherwise, two analysts can calculate different percentages from the same file.
2. Filter by constraint type and date
In Microsoft Project, add the Constraint Type and Constraint Date fields to a task view. Then filter incomplete tasks for MSO, MFO, SNLT, and FNLT. Microsoft notes that editing task start or finish dates can create constraints, so also look for constraints introduced through routine date entry rather than deliberate schedule design.
3. Trace predecessor and successor logic
Next, determine what drives each constrained activity. Review the complete upstream and downstream path rather than examining the activity in isolation. If necessary, use the process described in tracing a critical path in Microsoft Project.
Ask what date the network would calculate without the constraint. That date often reveals hidden delay, missing logic, an incorrect calendar, or an unrealistic duration.
4. Identify the real-world condition
A constraint should represent an actual scheduling condition, not management preference. Examples may include a test facility opening, a regulated access window, a customer-furnished item availability date, or an externally controlled launch opportunity.
Even then, a constraint may not provide the best model. The team may need an external interface activity, an availability calendar, a procurement activity, or explicit logic tied to an external milestone.
5. Correct the model without deleting the commitment
Replace unnecessary hard constraints with valid logic. For a required completion date, consider retaining the target as a contractual milestone, baseline date, or software deadline while allowing the current forecast to move.
In Microsoft Project, a Deadline field can display a target and calculate negative slack when the forecast passes that date without directly forcing the task’s scheduled finish. However, test the result in the program’s scheduling tool and document the chosen method. Tool behavior and customer reporting rules can differ.
6. Recalculate and validate the result
Finally, recalculate the schedule and inspect the critical path, near-critical paths, total float, negative float, and completion forecast. Removing a constraint can expose a major logic problem. That is useful information, not a reason to restore the artificial date.
Fictional example: a constrained qualification milestone
The Falcon Ridge avionics program has an MFO constraint of September 18 on its Qualification Complete milestone. The team entered the constraint because the contract identifies September 18 as the required completion date.
During the August status cycle, environmental testing slips by ten working days. However, the milestone remains fixed on September 18 because of the MFO constraint. The schedule no longer provides a transparent forecast from the test sequence to qualification completion.
The scheduler removes the MFO constraint in a controlled working copy and recalculates the network. Qualification Complete moves to October 2. The team then verifies that the predecessor logic and remaining durations are valid.
Instead of forcing the milestone back to September 18, the scheduler records that date as the contractual target and allows the logic-driven forecast to remain October 2. The resulting negative float quantifies the recovery required. Consequently, the Control Account Manager and program manager can evaluate additional test shifts, parallel review work, or other executable recovery options.
The required date did not disappear. Instead, the schedule now distinguishes the commitment from the current forecast.
Common hard-constraint failure modes
- Typing dates to make the bars look right: Direct date entry can add constraints without correcting the underlying logic.
- Constraining every contractual milestone: A contract date should remain visible, but the forecast should still respond to actual performance.
- Reviewing only the percentage: One constraint on the primary delivery milestone may create more risk than dozens on non-driving records.
- Removing constraints solely to pass: Metric improvement is not useful if the revised logic no longer represents the execution plan.
- Ignoring soft constraints: SNET and FNET may not count in the hard-constraint metric, yet they can still distort dates and float.
- Using constraints instead of external logic: Supplier deliveries and customer-furnished items often need visible activities or interface milestones.
- Failing to document justified exceptions: Reviewers need to understand the condition, authority, owner, and continued need for each retained constraint.
What a strong corrective action looks like
A useful corrective action does more than reduce the metric below 5 percent. It identifies why each constraint exists, determines whether the schedule can model the condition through logic or calendars, and verifies the effect of any change on float and the critical path.
For retained hard constraints, document at least the activity identifier, constraint type and date, business or technical basis, source of the date, responsible owner, effect on float, and planned review frequency. Also confirm whether the constraint remains active after each status cycle.
Ultimately, the DCMA hard constraints check should prompt better analysis rather than cosmetic cleanup. A healthy IMS preserves required dates while allowing logic to calculate an honest forecast. That distinction supports credible customer reporting, schedule risk analysis, earned value management, and timely program decisions.
Frequently asked questions
Does every hard constraint need to be removed?
No. Some constraints represent legitimate external conditions. However, each one should have a documented basis, and the scheduler should confirm that logic, an activity, or a calendar cannot model the condition more accurately.
Does a result below 5 percent mean the schedule passes?
It means the metric falls within the commonly used threshold. It does not prove that the constraints are appropriate or that the schedule is executable. Review the location and effect of every flagged constraint.
Are SNET and FNET constraints harmless?
No. They usually fall outside the hard constraints numerator, but they still restrict activity movement and can affect float. Remove inactive constraints and justify active ones.
Should a contractual delivery milestone use Must Finish On?
Not automatically. A fixed constraint can prevent the milestone from displaying the current logic-driven forecast. A target milestone, baseline date, deadline, or other documented commitment field may preserve the required date while allowing variance and float analysis. Follow the contract and program scheduling instructions.