Understanding the Primavera P6 – USACE Mandatory Requirements

good stuff thank you for summarizing 

Thanks for sharing, these are very useful information.

Memorandum: Use of Brand Name Specifications

Brand Name Specifications is frequently done by corrupt officials who take advantage of monopolistic practice, perhaps by taking some bribery.

It looks like USACE is bypassing the rules; in any case justification for Brand Name Specifications must be done on a case by case, for each individual contract.

Really useful breakdown, Colin — especially the point about “Longest Path” vs zero total float for critical activities. I’ve seen a lot of confusion around that one specifically, since multiple critical paths can quietly creep in without anyone noticing until much later in the project.

One thing I’d add: these 10 settings are usually the easy part to get right once you know them. The harder part in practice is verifying a schedule stays compliant with all of them throughout the project — especially once schedule updates start coming in from subs and things like activity codes or calendars accidentally get elevated to global level.

Curious if others here do this verification manually each submission cycle, or have built in some kind of repeatable check?

From personal experience: manual verification doesn't survive the first update cycle. What starts as a clean, compliant schedule drifts within two or three sub updates — typically in exactly the areas you flagged: calendars promoted to global, activity codes repurposed, constraints creeping back onto in-progress work.

For our submissions I moved to a repeatable checklist that runs against the schedule export every cycle, before formal submittal — the same checks USACE/IMPREST spell out, but executed as data checks rather than eyeballing layouts:

- Calendars: every activity references a valid project-standard calendar; no orphaned/global calendars in play (this is the #1 silent one).

- Logic: no open ends on in-progress or remaining activities; finish-to-start ratio; missing-relationship count.

- Constraints: count and list by type — soft constraints on completed work are fine, late-start/late-finish needs a justification.

- Float: negative-float activities and longest-path consistency.

- Data health: activity codes at project vs global level, % complete consistent with actuals and remaining duration.

The key insight is that these checks run on the exported schedule and can be versioned (data snapshot + stored rule set), so the same evaluation happens every cycle and you can diff one cycle against the last. That's what catches "compliant on day one, drifted by week 12."

Curious what drift you've seen most from subs — for us it's calendars every single time.

Calendars being the #1 silent one matches what I’ve seen too — it’s the one that looks completely fine in the activity view and only shows up when you actually check calendar assignment field by field.

The versioned diff approach you’re describing is exactly right, and honestly the main reason I ended up building a small tool around this rather than keeping a manual checklist — running the same rule set against every export and diffing cycle-to-cycle catches drift you’d otherwise only notice after three or four updates. If you want to compare notes or take a look: https://structuraline.com

Curious which checks you’ve found actually move the needle vs. which ones are more “nice to know” — always looking to refine the rule set against real-world cases like yours.

Cause vs symptom is the line I've settled on. A check earns its place if the finding tells me what to change. If it only tells me the schedule is unwell, that's reporting, not diagnosis.

The ones that change what I do:

- Statusing consistency — actual dates against % complete against remaining duration. Nearly every "bad" schedule I've opened is a statusing failure wearing a planning costume. It's also the one you cannot see in a single file; it only shows up comparing this cycle to the last.

- Constraints on in-progress work. A constraint here doesn't just sit there — it absorbs float and hides the real driver. Each one needs a name and a reason, or it comes off.

- Open ends on activities that aren't complete. If that count drifts up cycle to cycle, someone is statusing without maintaining logic, and the forward dates stop meaning anything.

- Calendar assignment — your point, and I'd put it at the top for exactly the reason you gave: nothing on screen looks wrong, and every downstream date moves.

The ones I report but don't chase:

- Negative float and float distribution. Reliable alarm, useless instruction — it's always downstream of one of the four above.

- FS/SS ratio, constraint counts, duration outliers. Worth watching as a trend across updates; a single number on a single file tells you very little.

- Activity codes at global vs project level. Governance, not schedule integrity. It has never moved a date for me.

The short version: the things worth fixing first are mostly statusing discipline, not network design — which is exactly why the cycle-to-cycle diff you described earns its keep. One clean snapshot proves very little.

Genuinely curious about your side of it. Your gate and this checklist are answering different questions — a file can be clean on logic and still be refused, and a file can upload fine and be nonsense underneath. In what you've seen, do the two tend to fail together, or are they independent?

That’s a sharp way to frame it, and it’s forcing me to be honest about something: in what I’ve seen, they’re mostly independent, and that’s actually the uncomfortable part.

A schedule can fail the RMS gate — wrong activity code level, calendar mismatch, RQS formatting — while the underlying logic and statusing are completely sound. That’s pure governance friction, exactly like you said about global/project codes: it never moved a date, it just blocks submission.

But a schedule can also pass the gate clean — every field formatted right, every code at the right level — and still be the “wearing a planning costume” case you described, where statusing discipline has quietly broken down underneath. The gate has no opinion on that at all; it’s checking structure, not truth.

So the failure modes don’t correlate the way you’d hope. A team good at governance isn’t necessarily good at statusing discipline, and vice versa — which is probably why so many schedules get treated as “fixed” once they clear submission, when the real problem you’re describing (open ends drifting, constraints creeping onto in-progress work) is still sitting there, just no longer visible to whoever only checks the gate.

That's exactly the uncomfortable part — the gate certifies the paperwork, not the plan, and paperwork and planning are different crafts. It's also why a clean submission is where the work starts rather than ends for the people downstream of it. The cycle-to-cycle diff is the only thing that sees underneath — statusing drift shows up as logic holes and constraint creep over two or three updates, never in one export. Appreciate you saying so plainly; it matches the USACE side of the market being quieter than it should be.