How to Analyse Construction Schedule Quality: A Practical Workflow

You have received a construction programme. The contractor says it is fine. The client wants reassurance. Somewhere between those two positions lies the question every project manager faces: is this schedule actually good enough to trust?

Schedule quality is not subjective. There are accepted standards, measurable thresholds and repeatable checks that tell you whether a programme can support reliable progress tracking, delay analysis and commercial decisions. The challenge is knowing which checks to run, in what order, and how to present the findings so they drive action rather than gather dust.

This guide lays out a practical workflow for analysing construction schedule quality. It covers the quality dimensions that matter, a step-by-step process for running the checks, and a reporting template that turns findings into client-ready deliverables. For the broader discipline behind these checks, see our guide to construction schedule analysis.

What we found: The DCMA 14-Point Assessment puts published thresholds on a small set of failures for a reason: missing logic links, hard constraints that override the network, and excessive float recur often enough to need one. The standard caps each of those at 5% of tasks, and sets leads and negative float at zero, because they are the defects that quietly break a critical path.

What it means: A repeatable quality analysis workflow catches these early, when correction is cheap, rather than during a dispute when the same defects become contested evidence.

Schedule Quality: What It Means in Construction

A quality schedule is one that can do the job it was created for. In construction, that job is twofold: managing the work day to day, and providing a reliable basis for measuring delay when things go wrong.

The Society of Construction Law (SCL) Delay and Disruption Protocol emphasises this dual purpose. For a programme to be suitable for monitoring progress and assessing delay, it ought to be “properly prepared so that, when a delay or disruption event occurs, it can accurately predict the effects” (SCL Protocol, 2nd edition, paragraph 1.43). That standard applies whether you are reviewing a baseline before acceptance or auditing an update midway through the works.

Quality breaks down into four dimensions:

Table 1: The four quality dimensions and what each one determines about the programme.

The stakes are not abstract. Across Flyvbjerg’s database of 16,000 projects, 91.5% finish over budget, over programme, or both (Flyvbjerg and Gardner, How Big Things Get Done). An unreliable programme is how those overruns stay invisible until they are unarguable. Scotland’s Holyrood Parliament Building ran from an initial estimate of around £40 million at the start of construction to a final outturn of approximately £431 million, opening roughly three years later than originally programmed (Auditor General for Scotland, 2004); the contemporaneous programmes were criticised as unreliable long before the overrun was conceded.

Poor quality in any of these dimensions does not just create administrative inconvenience. It can prevent you from running a time impact analysis, undermine an extension of time claim, or produce critical path results that no one can rely on.

Core Quality Dimensions to Check

Five structural checks do most of the work in a quality screen. Each maps to a DCMA 14-Point metric with a published threshold, so the pass or fail is measurable rather than a matter of opinion:

Table 2: The five structural quality checks and their DCMA 14-Point thresholds.

Logical structure and network logic

The most fundamental quality check is whether the schedule is logic-driven. Every activity (except the start and finish milestones) should have at least one predecessor and one successor. The DCMA 14-Point Schedule Assessment treats missing logic as the first check in its framework. In the assessment, “any incomplete task that is missing a predecessor and/or a successor is included in this metric” and “the number of tasks without predecessors and/or successors should not exceed 5%” (DCMA-EA PAM 200.1, section 4.1).

When activities lack logic, the schedule cannot calculate a true critical path. Instead, it relies on constraints or manual date entry to hold activities in place, which means float calculations and delay assessments built on that path are unreliable.

Relationship types

The DCMA assessment requires that Finish-to-Start (FS) relationships “should account for at least 90% of the relationship types being used” (section 4.4). Start-to-Start, Finish-to-Finish and Start-to-Finish relationships are permitted, but each one introduces complexity that makes the schedule harder to validate and easier to manipulate.

Excessive use of SS and FF relationships often indicates that the scheduler is using logic to model resource constraints rather than physical sequencing. That is not necessarily wrong, but it needs to be explained in the programme narrative.

Constraints and hard dates

Hard constraints (Must-Finish-On, Must-Start-On, Start-No-Later-Than, Finish-No-Later-Than) override network logic. The DCMA assessment specifies that “the number of tasks with hard constraints should not exceed 5%” (section 4.5). When more than 5% of tasks carry hard constraints, the schedule is not logic-driven; it is date-driven, and the critical path is artificial.

The SCL Protocol advises that “manually applied constraints such as ‘must start’ or ‘must finish’ fixed dates, ‘zero float’ and other programming techniques that can have the effect of inhibiting a programme from reacting dynamically to change should be avoided (or, if unavoidable, properly explained in the programme narrative)” (paragraph 1.47).

Leads and lags

Leads (negative lag) distort float and can create resource conflicts. The DCMA assessment sets a target of zero leads: “Leads should not be used; therefore, the goal for this metric is 0” (section 4.2). Lags are tolerated but limited: “the number relationships with lags should not exceed 5%” (section 4.3).

The SCL Protocol takes a similar position, recommending that “excessive leads and lags should be avoided” and that where they are used the contractor “should provide an explanation in the programme narrative as to why particular leads and lags have been applied” (paragraph 1.47).

Float distribution

Activities with excessive float (greater than 44 working days under the DCMA threshold) often indicate missing logic. The DCMA assessment notes that “if the percentage of tasks with excessive total float exceeds 5%, the network may be unstable and may not be logic-driven” (section 4.6). At the other extreme, negative float signals that the schedule cannot meet its contractual dates. For a deeper look at what float tells you, see our guide to total float vs free float.

Step-by-Step Quality Check Workflow

The workflow runs in five steps, from establishing the criteria to delivering a report the client can act on:

Figure 1: The five-step schedule quality workflow, from establishing criteria to the client-ready report.

Step 1: Gather contract clauses and standards

Before opening the schedule, establish the quality criteria. These typically come from three sources:

1. The contract: specification clauses that set programme requirements (level of detail, update frequency, software format, activity duration limits)
2. Accepted standards: the DCMA 14-Point Assessment, the AACE International Recommended Practice 29R-03 (Forensic Schedule Analysis), and the SCL Protocol
3. The accepted programme: if reviewing an update, the baseline programme that was originally accepted provides the reference point

The SCL Protocol notes that most standard forms of contract contain inadequate programme requirements and “recommends that the parties reach a clear and documented agreement on the requirements of the Contractor’s proposed programme in order for it to be accepted by the CA” (paragraph 1.41). If that agreement exists, start there. If it does not, the DCMA thresholds and AACE baseline validation protocols provide default benchmarks.

Step 2: Prepare the datasets

You need two files at minimum:

• The current schedule in its native format (XER for Primavera P6, MPP for Microsoft Project)
• The baseline schedule (for comparison)

Do not work from PDF exports or printed Gantt charts. Quality analysis requires access to the underlying logic, dates, durations and resources, which static formats strip out. For guidance on extracting data from native P6 files, see our article on XER file analysis.

Check the data date. The AACE Recommended Practice 29R-03 requires that the baseline schedule have its data date set at notice-to-proceed with no progress data occurring after that date (SVP 2.1, item 3). If you are reviewing an update, confirm the data date matches the reporting period.

Step 3: Run the health checks

Run the DCMA 14-Point Assessment as your first screening tool. The five structural checks in Table 2 do the heavy lifting; the remaining metrics cover resources, invalid dates, missed tasks, the critical path test, and the two schedule-efficiency indices (CPLI and BEI, each flagged below 0.95). Our DCMA 14-Point Assessment guide walks through all fourteen metrics, their formulas, and how to score a programme against each one. For a quality screen, treat the assessment as the baseline to clear before looking deeper.

The DCMA assessment is only a screen. A schedule that passes all 14 checks can still have problems: activities in the wrong calendar, resource overloads on the critical path, or scope gaps where contractually required work is simply absent.

Beyond the 14 points, check for:

• Duplicate activities (same description, same dates, linked to the same predecessors and successors)
• Open ends on non-start/finish milestones
• Calendar assignments that do not match contract working hours
• Summary tasks with assigned resources or costs

Step 4: Document non-compliances

Every finding needs four elements. A finding missing any one of them is incomplete:

Table 3: The four elements of a complete non-compliance finding.

A finding without a consequence is just a number. A finding without a recommended action is just a complaint. The value of a quality review lies in connecting the defect to its impact and the fix.

Step 5: Produce the client-ready report

Structure the report so that a non-specialist can understand it. A practical template:

Table 4: A reporting template that turns quality findings into client-ready sections.

For guidance on structuring technical findings for the client and project team, see our article on the delay analysis report.

Common Quality Issues and How to Verify Them

Five issues account for most of what a quality screen turns up beyond the DCMA metrics. Each has a quick verification and a known fix:

Table 5: Common quality issues, their verification, and the corrective action.

Duplicate activities

Duplicates inflate activity counts, distort DCMA percentages and create parallel paths that confuse the critical path. To verify: sort activities by description and look for identical or near-identical entries. Cross-check the activity IDs against the project WBS. A duplicate will typically have the same predecessors and successors but a different activity ID.

The fix is straightforward: delete the duplicate and ensure the remaining activity carries the correct logic links. Document the deletion in the programme narrative.

Invalid link types and logic loops

A Start-to-Finish relationship is rare and usually wrong. Logic loops (where A depends on B and B depends on A) prevent the schedule from calculating altogether. Scheduling software will flag logic errors on import, but these warnings are often dismissed. Review the relationship types report and investigate any SF relationships or circular references.

Schedule data gaps and unresolved activities

Activities without durations, without calendars or with zero-duration non-milestone tasks indicate incomplete scheduling. These create gaps in the network where float cannot be calculated. Check for activities where the duration is zero but the activity type is not a milestone, and for activities with no calendar assignment (which defaults to a 24-hour calendar in P6, distorting duration calculations).

Date and float anomalies

Activities that should be on the critical path but show large float values are suspicious. Activities with finish dates beyond the contract completion date may indicate negative float, or they may simply be disconnected from the project finish milestone. Run a critical path trace from the project finish milestone and verify that the activities you expect to be critical actually appear on the path.

Report vs reality mismatches

Compare the programme to progress records, meeting minutes and site reports. If the schedule shows an activity as 80% complete but the weekly report says it has not started, something is wrong. These mismatches often appear when updates are prepared cursorily or when status is carried forward unchanged from the previous period.

The SCL Protocol states that “progress is ideally recorded and coded to the Accepted Programme/Updated Programme activities” (paragraph 1.21). When progress data does not reconcile to the programme, the update is unreliable.

Tools to Support Quality Analysis

Quality analysis can be done manually in spreadsheets, but the process is slow and error-prone. Purpose-built tools fall into three categories:

Table 6: Three categories of schedule quality tooling and what each one does.

When selecting a tool for quality analysis, consider these evaluation criteria:

• DCMA 14-Point coverage: does the tool run all 14 metrics automatically, or do you have to calculate some manually?
• Baseline comparison: can the tool compare the current schedule to the accepted baseline and highlight changes to logic, durations and dates?
• Change drill-down: when the schedule changes between updates, can you identify which activities were added, deleted or modified?
• Update tracking: does the tool store historical results so you can see whether quality is improving or degrading over time?
• Reporting output: can the tool produce client-ready reports, or do you have to transfer results to a separate document?

For a broader comparison of schedule analysis software, see our guide to schedule analysis software.

Client-Ready Findings Report: A Sample Outline

Below is a practical outline for a schedule quality review report. Adapt the sections to suit your contract and audience.

1. Executive overview

• Overall quality rating (e.g. pass, conditional pass, fail)
• Number of critical findings vs minor findings
• Key risk areas that need immediate attention
• Whether the schedule is suitable for its intended use (progress monitoring, EOT assessment, baseline acceptance)

2. Methodology and source schedule

• Schedule file name, software version and data date
• Which standards were applied (DCMA 14-Point, contract specification, AACE 29R-03)
• Scope of the review (baseline acceptance, monthly update audit, forensic review)

3. Scope of quality review

• Activities included/excluded (e.g. LOE tasks, completed tasks, summary tasks removed per DCMA guidance)
• Calendar and resource checks performed
• Baseline comparison scope

4. Findings

For each finding:

• Metric or clause breached
• Count and percentage vs threshold
• Consequence of the defect
• Recommended corrective action
• Severity rating (critical, major, minor)

5. Recommendations and next steps

• Prioritised list of corrective actions
• Suggested deadlines for re-submission or correction
• Whether the schedule should be accepted, conditionally accepted or rejected

6. Appendix of evidence and raw metrics

• Full DCMA 14-Point calculation table
• Activity extracts showing defective entries
• Screenshots or data exports supporting each finding

Key Takeaways

1. Schedule quality is measurable. The DCMA 14-Point Assessment, AACE 29R-03 and the SCL Protocol provide accepted thresholds. You do not need to rely on subjective judgement.

2. Start with logic. Missing logic links and excessive hard constraints are the most common defects and the most damaging. If the network is not logic-driven, no other metric matters.

3. Use the right data format. Work from native schedule files, not PDFs. Quality analysis depends on access to the full data structure.

4. Connect findings to consequences. A percentage is not a finding. A finding needs a breach, a count, a consequence and a recommended action.

5. Quality is ongoing, not one-off. Running a quality check once does not guarantee the schedule stays clean. Build the checks into your regular update cycle. For tracking quality trends across updates, see our guide to baseline vs current schedule comparison.

6. Tools make it repeatable. Manual checks are slow and inconsistent. A dedicated tool standardises what “good” looks like and catches regressions between updates. Try the ScheduleLens schedule analysis tool to run DCMA 14-Point checks, baseline comparisons and quality trend tracking in minutes rather than hours.