A DCMA pass is not a QSRA pass
The pattern is familiar. The schedule passes the DCMA 14-point assessment, or most of it. The planner is satisfied and the QRA lead accepts the schedule for risk-loading. The schedule and risk register go into the simulation tool, the run completes, and the output makes no sense. The spread is narrow, the tornado is shallow and the P80 sits close to the deterministic finish. Nothing in the inputs looked broken.
The usual cause is a mismatch between what the checks test and what a QSRA needs. The DCMA 14-point assessment is a schedule health check of US Department of Defense origin, widely used in UK practice. It asks whether the logic, constraints, float and dates are sound. A QSRA asks a different question: given the uncertainty in activity durations and the risks in the register, what range of completion dates is plausible? To answer it, the schedule and register have to be prepared for probabilistic analysis, and DCMA does not test for that. A DCMA pass is therefore not a QSRA pass.
This guide is the schedule-and-register detail behind Gate 1 (Data) and part of Gate 3 (Model) of the SOMA QRA Readiness Checklist v1.0, which is a free download. The checklist works across five gates: Data, Workshop, Model, Report and Independent challenge. The table below shows where each check in this guide sits in it.
What QSRA-ready means
A schedule is QSRA-ready when every assumption the simulation tool makes about it is true. The tool will iterate the network thousands of times, so any soft logic, mis-tagged activity or unresolved calendar is repeated in every iteration. The spread you see is then partly an artefact of the inputs and not a measure of programme risk. The checks fall into five groups.
Logic. An activity with no predecessor can carry a duration range, but its start is unanchored: it is driven by the data date or a constraint, not by upstream work, so upstream slippage never reaches it. An activity with no successor is worse. Whatever risk you apply to it cannot delay completion, so the output ignores it. Check for open ends before anything else. Also check that relationships are mostly finish-to-start and that lags are few and explained.
Merge points deserve a separate note. Where several paths join, the deterministic schedule takes the latest of them and treats each as if it finishes on time. A simulation correctly shows that the join finishes on time only if all the incoming paths do. If two independent paths each have a 50% chance of finishing on time, the join has a 25% chance (0.5 x 0.5). With three such paths it is 12.5%. This is merge bias. It is a real effect that the deterministic schedule ignores and Monte Carlo captures, so a P50 later than the deterministic finish is not an input defect. What you should check is that the merge logic is real. A relationship added to tidy the network, or to force activities to line up, creates a merge that the work does not have.
Durations. DCMA flags activities longer than 44 working days (test 8, 5% limit). For a QSRA the question is different. A long activity is acceptable if it is one real operation. It is a problem if it is several operations summarised under one bar, because a three-point range on the bucket hides which operation drives the risk. Split it, or record why it cannot be split. Zero-duration activities that are not milestones carry no duration risk, so find out why they exist.
Constraints and calendars. DCMA counts Must Start On, Must Finish On, Start No Later Than and Finish No Later Than as hard constraints (test 5, 5% limit). Start No Earlier Than and Finish No Earlier Than are soft, but they can still hold a date that logic would move. Whether the simulation honours a constraint depends on the tool and its settings. Find out which setting applies and record it. Calendars must also resolve: every calendar ID an activity uses has to exist in the export, and connected activities on different calendars need a reason. In a Primavera XER file, calendars sit in the CALENDAR table and resources in the RSRC table. The ERMHDR line at the top of the file is only the export header (version, date, user, currency). Unresolved calendar or resource references are the real failure to look for.
Float and critical path. Negative float means the schedule already misses its own dates, so the analysis starts from a position the planner has not resolved. Large volumes of high-float activity usually point to missing logic. The critical path should be driven by logic and not held in place by constraints, which is Data item 2 in the checklist.
Scope markers. Level-of-effort (LOE) activities, hammocks and milestones need correct tags so that the tool treats them properly. If the schedule carries time risk allowances (the NEC4 ECC clause 31.2 programme includes float and time risk allowances), decide whether they stay in or come out so the risk model does not count the same uncertainty twice.
How to treat failed DCMA metrics
A failed DCMA metric does not stop a QSRA. It needs a written justification, per metric, before the workshop. That is the rule in Data item 1 of the checklist. A hard constraint that reflects a contractual access date can be justified. A hard constraint added to make the bar chart look tidy cannot. The same test applies to high float, long durations and lags: record what the metric found, why it is acceptable for this analysis and what effect it has on the result.
Some failures are harder to justify than others. Missing logic, negative float and invalid dates change what the simulation can say about completion, and the planner should normally fix them. The written record is for the reviewer who asks, later, why the run went ahead.
Four failure modes in the schedule
Hard constraints in the middle of the schedule are the most common cause of a suppressed spread. If a major milestone is pinned by a constraint the tool honours, it cannot move later however much the activities feeding it slip. The P80 then sits close to the deterministic date because the constraint is doing the work.
A worked example shows the pattern. The figures are illustrative, constructed to show the effect, and are not a client result. A deterministic finish of 30 November 2027 gives a P50 of 3 December 2027 and a P80 of 17 December 2027, which is 17 days after the deterministic date. The planner removes a Finish No Later Than constraint that was added to tidy the bar chart, and tags three LOE activities correctly so they stop carrying variance. The rerun gives a P50 of 15 February 2028 (77 days after the deterministic date) and a P80 of 10 March 2028 (101 days after). Part of that shift is merge bias, which was always there. The rest is the schedule finally being allowed to slip. The first output was never a result. It was a constraint reported as confidence.
LOE activities are the second case. Project management and site facilities bars take their duration from the activities they span, so they have no work content to extend or compress. A three-point range on them produces meaningless variance. Most tools can exclude LOE from variance, but only if the activity type is set correctly. Check it, and do not assume it.
Procurement lags are the third. A lag between design approval and construction start has no activity, owner or risk mapping. Some tools, including Safran Risk and Primavera Risk Analysis, can apply uncertainty to a lag. Even so, the lag cannot be linked to a procurement risk or traced to an owner. Where lead time is material, model it as an activity with a planner-set duration and a risk mapping.
A stale data date is the fourth. If the data date is two months behind the actual progress, the schedule no longer describes the programme and the simulation models a position that has passed. Check that the status on every activity matches the data date before the run.
Why the register needs its own checks
A clean schedule does not help if the register behind it is flawed, and the two fail in different ways. Check these points before the run.
Mandatory fields. Each row needs a probability, three-point cost impact, three-point schedule impact, distribution type, mapped activity, owner and trigger condition. Depending on the tool, missing fields are dropped, filled with defaults or given a distribution the analyst did not choose. Whatever the source (RiskHive, a consolidated workbook or another system), the field list is the same.
Inherent and residual status. Record whether each impact is before or after mitigation, and the status of the response. If rows mix the two, the output mixes them too. Opportunities need to be flagged separately from threats and triaged in the same way, as Data item 4 of the checklist requires.
Three-point estimates that are not three-point. A register where every risk uses the same band (for example 80%, 100% and 130% of the most likely) runs without complaint and gives a plausible spread. The spread comes from the template, not from the risks. Each estimate should reflect that risk's actual variability, and uniform bands are the thing to look for.
Probability bounds. Probabilities must sit between 0 and 100%, in one format. Check for values above 100%, negatives, blanks and a mix of 0-1 and 0-100 formats. Different tools treat a blank differently.
Risk-to-activity mapping. Every risk must resolve to one or more activities in the XER, or to a coded scope marker the tool can resolve. Weak mappings fail in several ways: vague scope such as civils generally, mapping to summary activities in place of detail, and activities renumbered between revisions. An orphan risk, which points to an activity that no longer exists, is either dropped or given a default mapping, depending on the tool and its settings. Both give a model nobody sanctioned. Where a risk is split across several activities, the weights must be explicit. Otherwise the tool may apply the full impact to each activity, which inflates the tail.
One sequence, run before the model
Run the checks in this order. The record from each step feeds Data items 1 to 5 of the checklist.
First, run the DCMA 14-point assessment on the current export and write a justification for each failed metric. Second, run the QSRA-specific schedule checks above: open ends, merge logic, long and zero-duration activities, constraint handling, calendar resolution, LOE and milestone tags, lags and the data date. Third, check the register for fields, residual status, estimate variety and probability bounds. Fourth, check the mapping between register and schedule: every risk resolves, targets are detail activities in scope, and split weights are explicit. Fifth, record what was checked, what was found and what was done, and have the planner and the QRA lead both sign the record before the run.
The record answers the first question a sponsor, an assurer such as NISTA (formerly the IPA) or National Highways assurance, or a gate reviewer will ask about a surprising result: were the inputs checked? It does not make the analysis correct. It shows that the inputs were checked and by whom.
On a QSRA we run these checks in this order and keep the written record with the run files. We use an internal validator to speed up the schedule and register checks; it is not offered as a product. The thinking matters more than the tool, and the same checks can be run in a spreadsheet.
What this guide does not cover
A clean XER and register are only part of readiness. This guide does not cover schedule density (the checklist suggests 200 to 800 activities for a programme-level analysis), workshop calibration and bias, distribution and correlation choices, iteration count and run stability, seeds, reporting, or independent challenge. Gates 2 to 5 of the checklist cover those. Relevant AACE International Recommended Practices include 57R-09 Integrated Cost and Schedule Risk Analysis Using Risk Drivers and Monte Carlo Simulation of a CPM Model, 64R-11 CPM Schedule Risk Modeling and Analysis: Special Considerations, and 40R-08 Contingency Estimating - General Principles.
Next step: download the QRA Readiness Checklist v1.0 and mark each of its 66 checkpoints Y, P or N before the next QRA cycle. Items marked P or N become the work-list for the next workshop or model run.