Why the DCMA 14-point check is not sufficient for baseline assurance

The DCMA 14-point Assessment measures important characteristics of schedule quality. It helps identify conditions that require investigation and supports professional scrutiny of the programme.

A construction schedule intended to form part of a defensible baseline must satisfy a wider set of requirements. Alongside its internal integrity, it must provide information that can be aligned, referenced and reconciled against the cost, scope, risk and project context evidence accompanying it into the Baseline Book.

These are different dimensions of quality. A programme can perform extremely well against conventional schedule-health metrics while remaining poorly prepared for baseline submission or assurance.

Understanding that distinction begins with recognising the schedule’s two responsibilities.

A favourable schedule-health assessment supports conclusions about the characteristics examined. It does not automatically extend to relationships with documents outside that assessment.

A programme may contain well-connected activities while using a delivery breakdown that cannot be related reliably to the commercial packages. It may contain credible dates while referencing scope from a superseded design position. It may represent several similar work elements without enough context to distinguish their respective cost or risk associations.

Those conditions can remain unresolved even where conventional schedule-health findings have been addressed.

Equally, the presence of cost or resource information within a schedule does not, by itself, establish reconciliation with the accompanying cost evidence. The relationship still needs to be examined.

Baseline readiness therefore requires additional properties that a DCMA result alone does not establish: alignability, referenceability and deconflictability.

An alignable schedule contains sufficient information to relate its activities and delivery structures meaningfully to the other baseline documents.

Scope elements can be associated with the work intended to deliver them. Cost elements can be related to the activities or packages they support. Risks can be connected to affected work, and contextual conditions can be associated with the commitments that depend on them.

This does not require every document to adopt the same structure. A Cost Breakdown Structure supports commercial control, while a Work Breakdown Structure supports delivery control. One commercial package may fund several scheduled work packages. One delivery activity may draw on several cost elements.

The requirement is that these relationships can be explained and tested.

For example, a programme may divide construction by location while the cost plan divides it by trade. Both structures may be appropriate. Baseline readiness depends on whether the submission provides enough information to connect those views and identify any gaps or overlaps.

Conventional schedule-health assessment can examine the programme’s network without establishing that connection. Alignability determines whether the schedule can participate in the wider assurance process.

A referenceable schedule allows reviewers to locate the records supporting a baseline commitment and follow their relationship across the submission.

Activity identifiers provide a starting point. Package references, scope identifiers, document revisions and controlled mappings can establish the further connections needed to understand what those activities represent.

Consider a commissioning milestone supported by a scope document defining the systems to be commissioned and a project requirement defining the acceptance conditions. A reviewer should be able to locate those sources and establish which revisions underpin the scheduled commitment.

Without that reference chain, the milestone may be clear within the network while its meaning remains difficult to verify against the wider baseline.

Referenceability also allows findings to be challenged precisely. A reviewer can identify the affected activity, the supporting source and the particular relationship in question. The project team can respond against the same evidence.

A strong DCMA result does not establish this traceability. Schedule-health findings concern the characteristics assessed within the programme; referenceability supports interrogation of its commitments across the baseline evidence.

A deconflictable schedule contains enough information to distinguish individual scope or cost elements from other, similar elements.

That distinction is necessary before a reviewer can determine whether the schedule and another document agree. They must first establish whether both records refer to the same element of the project.

Consider three activities, each called “Install drainage”. Each may have a unique activity ID, appropriate logic and a reasonable duration. Yet the cost plan distinguishes drainage by commercial package, while the scope documents distinguish it by location and system.

If the programme provides no corresponding context, the reviewer may be unable to establish which scope and cost elements belong to each activity. Location, system and package information—or a controlled mapping providing those distinctions—would make reconciliation possible.

The network could remain unchanged while the schedule became materially more useful for baseline assurance.

Deconflictable does not mean deconflicted. The schedule must expose enough information for conflicts to be identified and investigated; the project team remains responsible for resolving them.

Where that information is ambiguous, baseline robustness becomes increasingly dependent on the reviewer’s ability to parse the submission and search for relevant evidence. Conventional schedule-health metrics do not establish how reliably that task can be performed.

The Baseline Book brings the programme into a shared evidence position with cost, scope, risk and project context.

Schedule-quality findings help explain whether the programme provides a credible planning model. Baseline-readiness findings help explain whether that model can be connected to the commitments and assumptions recorded elsewhere.

Both forms of finding matter. A programme with strong references and clear mappings may still contain serious logic weaknesses. A programme with excellent schedule-health results may still be difficult to reconcile with the scope or cost submission.

The Baseline Book needs to make these conditions visible. A favourable result in one dimension should not conceal an unresolved limitation in the other.

This also changes how improvement is understood. Correcting schedule logic improves the planning model. Adding a supported scope reference, establishing a cost mapping or distinguishing similar work elements improves its readiness for integrated assurance. Each action addresses a different weakness in the evidence supporting the baseline.

Tools designed principally to analyse an XER file or schedule network have a defined object of analysis: the programme as a planning and control model. Their capabilities support investigation of its structure, logic and other schedule characteristics.

Integrated-baseline-assurance tools have a different object of analysis: the combined body of evidence supporting the project’s delivery commitments.

That object extends across document boundaries. It requires examination of individual sources and their relationships, including explicit references, supported mappings, ambiguous associations, unmatched elements and conflicting commitments.

The distinction is determined by analytical purpose. Importing several document types does not establish integrated assurance capability, just as producing a schedule-health score does not establish baseline readiness.

BaselineBuilder’s operating model centres on this broader evidence position. Its purpose is to support the preparation and assurance of the baseline as an integrated submission, with the strength and limitations of the supporting relationships available for professional review.

In practice, this creates a distinction when selecting tools and defining assurance scope. Schedule-analysis capability supports scrutiny of the delivery model. Integrated-baseline-assurance capability supports scrutiny of the project position assembled around it. The required capability follows from the object being assured.