The GAO ten best practices, and the three things the DCMA 14 cannot see

Most schedule reviews in this industry begin and end with the DCMA 14-point check. It is an excellent test of one thing — whether the network was built by someone who knew what they were doing. It is not a test of whether the schedule is reliable. For that there is a longer, more demanding framework, and three of its ten best practices describe conditions that no structural check on a file can detect at all.

Two guides, two different questions

The DCMA 14-point assessment grew out of the Defense Contract Management Agency's need, from around 2005, to review contractor Integrated Master Schedules at scale on major defence contracts. It is a set of metrics computed on a file: percentages of activities with missing logic, with leads, with lags, with hard constraints, with excessive float or duration, plus the two ratio tests, CPLI and BEI. It is fast, repeatable, and it does not need to know anything about the project. That is precisely its strength and precisely its boundary.

The GAO Schedule Assessment Guide (GAO-16-89G, December 2015) was written for a different purpose. It is the schedule companion to GAO's long-standing Cost Estimating and Assessment Guide, developed with a community of practice drawn from federal agencies and private industry, and it exists so that GAO auditors — the people who report to Congress on whether a programme's dates can be believed — have a defensible basis for saying yes or no. It is an assurance framework rather than a hygiene test.

The distinction matters more than it sounds. The DCMA check asks: is this network well formed? The GAO guide asks: can the completion date this schedule produces be relied upon? A schedule can pass the first comprehensively and fail the second in every respect that counts.

The four characteristics, and the ten practices under them

GAO organises its ten best practices under four characteristics of a reliable schedule: comprehensive, well-constructed, credible and controlled. The grouping is not decoration — it is the argument. A schedule that is well-constructed but not comprehensive is a beautifully engineered model of the wrong project. A schedule that is comprehensive and well-constructed but not credible has never been tested against risk. And one that is all three but not controlled was true once, at baseline, and has been drifting ever since.

The ten practices themselves are unsurprising to any experienced planner. What is useful is asking, of each one, a question the guide does not ask directly: can this be verified from the schedule file alone?

Four of the ten cannot be answered by any tool, ours included, from a single file. That is not a limitation to be apologised for; it is the shape of the problem. Knowing which four they are is what separates a schedule review from a schedule report.

Where the DCMA 14 actually lands

Map the fourteen checks onto the ten practices and the coverage is strikingly uneven. Logic, leads, lags, relationship types, hard constraints, high float, negative float, high duration and invalid dates are all — every one of them — evidence for practices 2, 6 and 7. CPLI and BEI reach into practice 9. The resources check touches practice 3 in the thinnest possible sense: it asks whether a cost or units value is populated, not whether the resource exists.

Blind spot one — whether the work is all there

Practice 1 is the one that ends careers. A schedule can pass all fourteen checks with a 98% quality score and be missing thirty per cent of the scope. Every structural metric is computed on the network you were given; none of them can miss what was never entered. The activities that go missing are depressingly consistent across sectors: statutory approvals and permits, long-lead procurement and the vendor data loop behind it, temporary works, utility diversions and third-party interfaces, testing and commissioning at anything below system level, and the whole handover, O&M and closeout tail.

GAO's remedy is unglamorous and correct: the schedule should reflect the work breakdown structure, and the WBS should reflect the contract. So the review runs the other way round — from the scope document into the file, not from the file outwards. Take the contract milestones, the permit register, the procurement schedule and the commissioning strategy, and confirm that each one appears as activities with logic, not as a note in the narrative.

Blind spot two — whether anyone can actually do it

Practice 3 requires that resources be assigned to activities, and GAO is explicit that the point is feasibility: a schedule that assumes more labour, plant or specialist supervision than will exist is not a plan, it is a wish. The DCMA check has a resources test, but it asks only whether a resource or cost value is present. It cannot see that the same crew is committed to four concurrent activities in week 34, and it has no view at all on whether the peak demand curve is deliverable.

This is the single largest category of schedule failure that structural checking will never surface, and it is why resource loading and levelling deserve their own treatment — including the awkward fact that once you level a schedule, total float stops describing the thing everyone thinks it describes.

Blind spot three — whether the answer is traceable and tested

Practices 5 and 8 are the two that make a schedule credible in GAO's sense, and neither is a file property.

Horizontal traceability is the requirement that the logic genuinely links products and outcomes across the network, so that a slip in one place propagates to the places it should. You can approximate a test for it — drive a delay into a representative activity and see whether the completion date moves — but the judgement of whether the resulting path is sensible is human. Vertical traceability is the requirement that data are consistent between levels of the schedule: that the date on the Level 1 board report, the Level 2 integrated programme and the Level 3 working schedule are the same date, derived from the same logic, and not three independently maintained numbers that happen to have agreed at baseline. In our experience vertical traceability is the most commonly and most quietly broken of the ten, because nothing in a single file exposes it.

Schedule risk analysis, practice 8, is where the guide is most direct. A deterministic completion date carries no statement of confidence, and GAO's position is that a schedule without an SRA cannot support a claim about contingency at all: the analysis exists to establish the level of confidence in the completion date, to size the time contingency needed for a chosen confidence level, and to identify which risks are actually driving the distribution. That last output matters more than the percentile — a P80 with no ranked driver list tells a board a number but gives them nothing to manage. If you have not run one, the mechanics are less intimidating than the reputation, and the quality of the three-point inputs matters far more than the sophistication of the simulation.

Reasonable total float — a genuine difference of philosophy

Both frameworks care about float, and they treat it differently in a way worth understanding.

The DCMA approach is threshold-based: activities with total float above 44 working days are "high float" and should be under 5% of the incomplete population; activities with negative float should be zero. It is a screening test, and like all screening tests it can be gamed — dropping a late constraint on a few tail activities will improve the high-float percentage without improving anything real.

GAO treats float as an output to be interrogated. The question is not whether the percentage clears a bar but whether the float values on each path are explicable: large float almost always means missing successor logic, a dangling chain or a constraint doing work that logic should be doing, and the correct response is to find out which, not to tune the number. Negative float is treated as what it is — a statement that the plan as written cannot be delivered, which requires either a recovery plan or an honest change to the date.

Both are right within their purpose. If you only report the percentage, you have reported the symptom. Float is a derived quantity, and its value as a diagnostic comes from asking what produced it.

"Controlled" — the characteristic that decays first

Practices 9 and 10 are about what happens after baseline, and they are the ones most programmes fail without noticing.

Practice 9 is "updating the schedule using actual progress and logic". The three words at the end carry the weight. Recording actual dates is easy and most teams do it; maintaining the logic through those actuals is where the discipline breaks. When work happens out of the planned order — as it always does — the network has to be repaired to reflect what really constrained what. Leaving it alone, or worse, switching the scheduling option so the software steps around the problem silently, produces a forecast that is arithmetically valid and physically meaningless. That single setting deserves its own article, and has one.

Practice 10, maintaining a baseline, is the evidential backbone of everything else. Without a preserved baseline and a documented change log, none of the other nine practices can be demonstrated after the fact, and no delay analysis worth the name is available to you later. This is the same argument that makes baseline discipline the thing that decides whether you can prove anything.

Running a GAO-style assessment on a file you were sent this morning

A practical division of labour. Roughly two-thirds of the framework is machine-checkable on the file in front of you, and the remaining third requires four documents you have to ask for. Do the first part before the meeting; use it to make the request for the second part specific.

So which framework do you cite?

Both, for different sentences. Use the DCMA 14 as the structural gate — it is fast, widely understood, and a schedule that fails it is not worth analysing further until it is fixed. Use the GAO characteristics as the frame for the conclusion, because "this schedule is well-constructed but not credible, and control has lapsed since revision 4" is a finding an executive can act on, where "7.2% high float" is a number they will nod at and forget.

And be honest in the report about which of the ten you actually tested. A review that says "we assessed practices 2, 3, 4, 6, 7 and 9 from the schedule file; practices 1, 5, 8 and 10 could not be assessed without the WBS, the risk register and the baseline change log" is far stronger than one that implies whole-framework coverage from a single XER. The limits, stated plainly, are what make the rest of it believable.

On your own schedule: run the structural two-thirds in seconds — 18 checks, scope-completeness flags and float diagnostics, parsed in your browser with nothing uploaded.