Your Governance Expectations Are.

Why File-Based Scheduling Fails as a Contractual Control System on High-Value Projects—and How to Fix It
A forensic governance white paper for owners, contractors, and legal teams

Peter Tignini
Precision Scheduling Consultants (PSC)
Project Controls & Governance Architect • Author, When Controls Lie Series

Executive Summary

The Problem in Plain Language

On complex capital programs—data centers, energy, infrastructure—owners increasingly require time certainty, payment certainty, and defensible entitlement. Yet many programs rely on Microsoft Project (MSP) as their primary scheduling platform. MSP is a capable planning and communication tool. It is not, by design, an enterprise, contractual, forensic schedule control system.

This white paper demonstrates why that distinction matters. When MSP is used as a control system without compensating governance, the project loses baseline integrity—planning intent mutates over time; update discipline—status and logic drift without audit trail; entitlement traceability—change not anchored to the critical path; auditability—who changed what, when, and why is unrecoverable; and logic fidelity—out-of-sequence progress is not governed by the scheduling engine.

The result is not simply poor reporting—it is loss of governance over the critical path and entitlement. Once that happens, recovery becomes reactive and expensive, payment certification becomes weakly supported, and disputes devolve into narrative reconstruction.

We benchmark MSP against Primavera P6, not to advocate a product, but to illustrate the capabilities a project control system must provide to meet contractual and forensic standards. We then present a Minimum Viable Governance Spine that allows owners to use MSP safely when P6 is not available or not desired.

Section 1

The Category Error: Planning Tool vs. Control System

Projects fail in scheduling not because teams lack effort or skill, but because organizations commit a category error: they use a planning tool as if it were a contractual control system.

Planning tools (like MSP) excel at building a work plan, visualizing tasks and dependencies, and communicating intent to teams and stakeholders.

Control systems must also provide: baseline integrity and change control with protected original values; audit trail, role-based permissions, and chain of custody; update discipline with governed status cycles; entitlement mechanics tied to contemporaneous logic; portfolio standardization and oversight; and deterministic CPM calculation with retained logic for out-of-sequence progress.

MSP can draw a CPM-looking network. It does not, by default, enforce the rules that make that network contractually binding and evidentiary.

P6, in contrast, was designed as an enterprise CPM control environment—with role-based security, baseline lineage, portfolio governance structures, and a scheduling engine that handles out-of-sequence progress through explicit algorithmic options. It is not perfect and can be misused. But it is architected for control, not just communication.

Section 2

What Owners Actually Need from a Schedule

Owners fund projects to achieve outcomes on time and on budget. To do that, the schedule must function as a control instrument with six non-negotiable properties:

1. Integrity of Planning Intent. The original plan must be preserved and comparable to actual performance without mutation. Original Duration must exist as a protected, immutable value
2. Governed Updates. Status cycles must be consistent, auditable, and resistant to manipulation. The order in which fields are populated must not alter the output.
3. Entitlement Traceability. Changes must be analyzed against the contemporaneous critical path with documented logic, using Time Impact Analyses anchored to the schedule at the time of the event.
4. Payment Anchoring. Progress certification must be tied to verified schedule performance.
5. Auditability & Chain of Custody. Who changed what, when, and why must be retrievable and defensible.
6. Logic Fidelity Under Progress. When work proceeds out of planned sequence, the scheduling engine must provide explicit options for how remaining work is calculated—not silently override logic with actual dates.

Any platform used as the project schedule must enable these six properties. MSP, out of the box, does not.

Section 3

Structural Gaps in MS Project — and Why They Matter

This section documents observed, repeatable behaviors in MSP that create governance and evidentiary gaps. Each gap is mapped to its forensic consequence.

Visual Summary — Section 3

The 11 Structural Gaps

Each card maps a platform limitation to its forensic consequence

Section 3 — Detail

Gap-by-Gap Forensic Analysis

3.1 — No Protected Original Duration. MSP has no native “Original Duration” field. In P6, Baseline Duration is a protected, separate field that preserves the planned duration independent of progress. In MSP, duration and dates are subject to recalculation based on calendars, resource loading, and effort-driven logic. Even “Fixed Duration” tasks can change duration when resource profiles shift. Without a protected OD, the as-planned basis for any delay analysis is vulnerable to challenge.

3.2 — Non-Deterministic Duration Math. MSP durations depend on a matrix of interacting settings: project calendar settings (hours/day, days/week), task calendars, resource calendars with assignment contours, effort-driven toggles, task type (Fixed Work, Fixed Duration, Fixed Units), and the single “day” definition in Project Options which cannot vary by task. This produces situations where date spans appear correct while duration values are distorted, or where changes in calendars or resource units silently alter duration. When elapsed-day lags (e.g., “4ed” for concrete cure) land such that the cure concludes on a Friday evening, the weekend gap creates phantom float on upstream activities, breaking the continuous critical path. MSP also exhibits update sequencing sensitivity: modifying remaining duration causes both Duration and Percent Complete to change simultaneously, and entering fields in the wrong order triggers cascading, usually undesired changes.

3.3 — Resource-Driven Scheduling Mutates Logic. MSP’s work-driven calculations can cause durations to compress when resources are added, extend when resources are under-allocated, or change based on assignment contours. The three task types interact with resource assignments in six possible outcomes—the “DRED” phenomenon. In contractual CPM, logic drives time. Resources are applied to meet durations, not to redefine them. Duration changes driven by resource reallocation—rather than documented change orders—create unexplained variance that cannot be attributed to any party.

3.4 — No Retained Logic for Out-of-Sequence Progress. This is the single most consequential structural gap for forensic work. When work is executed out of planned sequence—research indicates approximately 40% of started activities progress out of sequence on construction projects—the scheduling engine must decide how to handle the conflict. P6 offers three explicit options: Retained Logic, Progress Override, and Actual Dates. MSP offers none of these as explicit options. It uses actual dates to override logic by default. Remaining durations can appear in the past. In MSP 2016 and later, Total Slack values of all tasks with out-of-sequence successors can be altered, causing tasks to display incorrectly as “Critical.” Without retained logic, the critical path after progress updates is unreliable. Any delay analysis depending on the contemporaneous critical path is built on suspect data.

3.5 — Single Relationship Between Activity Pairs. MSP permits only one relationship between any two activities. P6 allows up to four (FS, SS, FF, SF) between the same pair. In construction, it is routine to need both SS and FF between the same activities. MSP forces lag-based workarounds or artificial intermediate activities—both degrade logic transparency and are vulnerable under cross-examination.

3.6 — Data Integrity and Identifier Instability. MSP relies on row-number Activity IDs that change when tasks are inserted, deleted, or re-sequenced. While Unique IDs (MSP 2003+) are stable, the primary identifier is volatile. During export/import, IDs shift, predecessor chains can be mis-mapped, and relationship values can appear as concatenated values or scientific notation in downstream tools. The DCMA 14-Point Assessment addresses this: the gap between the highest Activity ID and highest Unique ID reveals deleted activities.

3.7 — Single-User File Model. The standalone .mpp file does not natively enforce role-based permissions, approval workflows, or a comprehensive audit trail. A single actor can edit logic, constraints, durations, and progress without transparent oversight—precisely what contracts attempt to prevent. Without an audit trail, the schedule becomes an assertion, not evidence.

3.8 — Constraints, Manual Scheduling, and Hidden Overrides. Unlike P6, where most constraints yield to logic if they cannot be enforced, MSP constraints override logic entirely—forcing activities to dates that violate predecessor relationships. Manual tasks, date constraints, and overrides can hide logic errors, create artificial float, and break CPM calculation without any warning to the user.

3.9 — No Native Entitlement Workflow. MSP provides no native structures for contemporaneous TIAs, fragnet governance, reflection projects, or linking change orders to critical path impacts. These can be simulated but are not embedded in the tool. Entitlement becomes retrospective narrative rather than contemporaneous record. Reconstructed TIAs carry significantly diminished evidentiary weight.

3.10 — Baseline Limitations. MSP limits baselines to 11 with limited data in each. P6 allows unlimited baselines with full data retention. For multi-year projects with monthly updates, 11 baselines are insufficient, forcing external baseline management and fragmenting chain of custody.

Section 4

Why Primavera P6 Is Used as the Benchmark

P6 was designed as an enterprise CPM control environment. Key capabilities include: unlimited baselines with lineage; role-based security; portfolio (EPS/WBS) structures; auditability of updates; reflection projects and fragnets for TIAs; Retained Logic, Progress Override, and Actual Dates scheduling options; up to four relationships between activity pairs; protected Original Duration; enterprise reporting; and Activity Steps for granular progress tracking.

These features create conditions for governance. They do not guarantee good governance—but they enable it.

Section 5

The Dispute Lens: Where MSP Fails Under Scrutiny

When schedules become evidence, six questions dominate: Was the baseline a reasonable representation of planning intent? Were updates contemporaneous and consistent? Did changes include TIAs tied to the critical path? Was float ownership defined? Can chain of custody be demonstrated? Was out-of-sequence progress governed?

File-based MSP environments struggle because planning intent may have mutated, updates lack audit trail, TIAs may be reconstructed, identifiers may not be stable, OOS progress produces unreliable critical paths, and multiple calendars produce inconsistent float along driving paths.

DCMA 14-Point Assessment Compatibility. Several DCMA checks expose MSP-specific vulnerabilities: MSP’s ease of creating manual tasks makes orphaned activities more common; MSP constraints override logic in ways P6 constraints do not; the critical path integrity test frequently fails with OOS progress or mixed calendars; and MSP generates negative float whenever a deadline or late constraint is violated.

This is why many disputes devolve into expert narrative rather than record-based proof.

Section 6

The Minimum Viable Governance Spine for MSP

If an organization chooses MSP, it must install a governance spine that compensates for the structural gaps. Each element maps to a specific gap.

6.1 Baseline Governance (Gaps 3.1, 3.10). Freeze the accepted baseline in a locked file with checksum/version control. Export a baseline register (activity ID, Unique ID, description, OD, logic, calendars). Create a traceability matrix from baseline to expanded/detail activities. Archive baseline files externally at each re-baseline event.

6.2 Update Discipline (Gaps 3.2, 3.4, 3.7). Establish a fixed data date cycle and enforce the Status Date field. Define mandatory field-entry sequence: actual dates first, then percent complete, then remaining duration. Lock actuals after submission; no retroactive edits without log entry. Require a change log for all logic/duration changes between updates. Enforce no manual tasks or hidden constraints unless documented and approved. Run OOS checks after every update and document resolution.

6.3 Out-of-Sequence Protocol (Gap 3.4). Specify contractual treatment of OOS progress; simulate retained logic manually. Require scheduler to identify, document, and resolve all OOS activities per update. Prohibit logic changes to “fix” OOS without written justification and owner approval. Maintain a cumulative OOS log as part of the schedule submittal package.

6.4 Entitlement (TIA) Protocol (Gap 3.9). Require a TIA for every change order prior to execution. Insert fragnets with documented logic ties to the contemporaneous CP. Maintain a TIA register; archive schedule file before and after each TIA.

6.5 Float Ownership & Logic Integrity (Gaps 3.5, 3.8). Define float ownership in the contract. Prohibit negative lags; document all positive lags with justification. Where SS+FF is required, document the workaround and maintain a simulated relationship register. Run DCMA 14-Point quality checks; adjust critical path threshold for elapsed-time lags.

6.6 Payment Anchoring. Condition pay applications on schedule compliance and verified progress. No compliant schedule, no payment certification.

6.7 Chain of Custody (Gaps 3.6, 3.7). Store all schedules in a controlled repository with versioning and timestamps. Maintain an external edit log; include file checksums in each submittal. Use Unique IDs in all exports and correspondence.

6.8 Portfolio Oversight. Standardize WBS dictionaries and coding structures. Produce monthly governance dashboards tied to DCMA 14-Point compliance.

This governance spine does not turn MSP into P6—but it restores the control properties required for contractual performance.

Visual Summary — Section 6

The Governance Spine

8 controls that compensate for MSP’s structural gaps

Section 7

Decision Matrix

When MSP is acceptable vs. when it becomes a forensic liability

MSP Acceptable Small to mid-scale (<$50M) Single scheduler manages updates Low LD exposure; low dispute risk Communication over forensic control No multi-calendar complexity Minimal out-of-sequence work Governance spine fully implemented

vs

MSP = Liability Exceeds $100M+ or tight milestones Multiple contractors, stacked trades Material LD exposure; claims likely Formal change control & TIAs required Multiple calendars, shift patterns 40%+ activities likely out of sequence No governance spine; MSP used as-is

At the liability threshold: either migrate to P6 or install the MSP Governance Spine. There is no third option.

Section 8

Owner Specification Language (Sample)

Baseline Requirements
The Contractor shall submit a CPM schedule with FS logic, zero negative lag, no open ends, and durations ≤ 20 working days unless approved. The accepted baseline shall be frozen with checksum verification. Original Duration shall be exported and maintained as an independent record.

Update Requirements
The Contractor shall update the schedule biweekly with a consistent data date. Actuals shall be entered in mandatory sequence: actual dates, then percent complete, then remaining duration. Actuals shall not be modified after submission without written justification. All OOS activities shall be identified and resolved in each update narrative.

TIA Requirements
All changes shall include a contemporaneous TIA demonstrating impact to the critical path. No EOT shall be granted without an approved TIA. The schedule file shall be archived before and after each TIA insertion.

Payment Linkage
Progress payments are contingent upon submission of a compliant schedule update demonstrating progress consistent with the pay application.

Auditability
The Contractor shall maintain a change log documenting all logic, duration, calendar, and constraint modifications. All files shall include MD5 checksum verification. Activity identification shall use Unique IDs in all exports.

Out-of-Sequence Governance
The Contractor shall identify all OOS activities in each update. For each, the Contractor shall document the cause, logic adjustment (if any), and impact on the critical path. Logic changes to resolve OOS require written Owner approval.

Section 9

Case Pattern: How Schedules Actually Fail

1. Baseline approved under pressure—aggressive dates, untested logic, no exported OD register.
2. Updates drift—constraints introduced, logic not maintained, no OOS checks.
3. Change processed without TIAs; fragnets not tied to contemporaneous CP.
4. Float consumed without defined ownership; lags mask missing relationships.
5. Payments continue without schedule verification.
6. Recovery attempts accelerate cost, not time.
7. Dispute reconstructs history—with an MSP file that has no audit trail, 11 baselines covering 36 months, and a critical path corrupted by OOS progress.

Appendix B

MSP-Specific Workaround Registry

Required compensating controls mapped to each structural gap

Appendix A

MSP Survival Governance Checklist

Appendix C

Key Terms

When planning intent is allowed to mutate,
you do not have a schedule.
You have a narrative.

Control systems, not tools, deliver certainty.

Precision Scheduling Consultants (PSC) • Peter Tignini • When Controls Lie Series