SL-DEMO

The project finish date has moved by fifteen working days, driven primarily by duration increases in substructure activities and a delay in the building control submission. This movement is significant as the schedule reports eighty activities with negative float, indicating that the programme is currently unable to deliver key milestones, including Practical Completion, on their planned dates. The reliability of these figures is further compromised by a critical divergence between the traced critical path and the stored flags on eighty-three activities, as noted in the DCMA 14-Point assessment. The reader should review the critical path divergence disclosure and the milestone deliverability findings to verify the integrity of the schedule logic.

The programme finish movement of fifteen working days stands as the authoritative delay figure for this comparison period. The table below details the activity-level drivers—duration changes, progress shortfalls, and added scope—as a structural signal of where pressure built up, rather than a summed project delay total. Because each activity is measured independently, parallel paths and float-absorbed slip are included in these categories without inflating the final movement figure. The topology section identifies where the schedule was rewired between baseline and update, serving as a direction-of-travel signal rather than an isolated working-day impact, which would require a calendar-aware CPM pass per event. Readers should focus their investigation on the Superstructure package, where logic edits were recorded.

The contractual and progress milestones detected on the two schedules, with the calendar-day variance between their forecast finish dates.

Only milestones present on both sides of the comparison are shown — one-sided entries are scope moves that would make the variance column unreadable if included.

2 milestones appeared on only one side of the comparison and are omitted here — see the Scope Changes section for added/removed activities and the Key Milestones sheet in the Excel appendix for the full per-schedule list.

Variance is shown in calendar days (consistent with how EOT claims are commonly stated) so the figure matches the way the contract will evaluate it.

What this section answers: where else forward risk is concentrated besides the controlling chain. Each row is an alternative chain to the project endpoint that's within 20 working days of the critical path; any of them could become controlling with a small slip.

Eight float paths are identified within twenty working days of the critical path, with the cluster dominated by near-critical chains rather than zero-float sequences. The presence of multiple sub-critical paths indicates that the schedule has limited resilience, as any of these chains could become controlling with a small slip in duration or logic. The following table details the top three paths ranked by float to illustrate the immediate forward risk to the project completion date.

Top 3 of 9 paths shown (the primary driving path plus 8 near-critical) — the full 5-path table and the float-path overlay chart are in the Narrative layer.

What this section answers: which near-critical chains are burning float across updates — an early warning that fires before a path goes critical and shows up in the delay register. Float lost is the typical (median) like-for-like drop in total float across the chain's eroding activities, excluding any whose constraint or calendar changed (a holiday edit to the same calendar is netted out instead). It is deliberately not their sum: every activity on a float path shares that path's float, so adding their individual drops would multiply one loss by the number of activities.

142 activities eroded float since the baseline, a median of 15 working days each (2140 working days in aggregate). The median is the typical per-activity erosion; the aggregate runs far larger on a broad schedule and shouldn't be read as the delay to completion. The most-eroded near-critical path is rank 2 (driving activity PRE-250 — Site security and CCTV), down 15 wd and now at 0 working days of float.

Measured against your approved baseline (SL-DEMO, finishing 2028-06-08), the work done by the data date (2026-03-06) was planned to be done by 2026-03-01: 5 days behind the baseline. That is a schedule performance index (SPIt) of 0.91. At that pace the baseline's planned duration (885 days from 2026-01-05) runs to 2028-09-04. Earned Schedule measures the rate of work (PMI Standard for EVM, 2019, §4.4); it is not a reschedule. The programme's own finish is 2028-06-29. Work is weighted by the baseline's original durations.

To finish by the programme's own date (2028-06-29), the remaining 830 days of baseline work must be done in 846 days: a required pace (TSPIed) of 0.98 days of baseline work per day, against 0.91 achieved so far (SPIt). The required pace is within 0.10 of the pace achieved, which NDIA reads as in line with performance to date (NDIA Predictive Measures Guide, 2025, §2.6.2).

DCMA 14-Point Assessment: 7 pass, 4 fail, 3 not assessed.

The full 14-item scorecard (every measured value, passing items included) is in the Narrative layer; per-check offender lists are in the appendix and the Excel workbook's DCMA detail sheet.

The full set of near-critical chains behind the Brief-layer float-path callout, with the overlay chart showing when each chain lands on the calendar. The Excel appendix carries the complete per-activity list per path.

Reading this chart. Three cumulative curves over time: the baseline's planned value (dashed grey), the current plan's planned value (solid blue), and the actual earned value on the update (solid red). Gap between the dashed grey and solid blue lines shows re-planning (work pushed into future periods, independent of actual progress). Gap between solid blue and solid red at the data date shows the current execution gap.

Acronyms. PV = Planned Value (share of total scheduled work due by a date). EV = Earned Value (share actually achieved). SV = Schedule Variance = EV − PV, in working-day equivalents. SPI = Schedule Performance Index = EV ÷ PV; < 1.00 ⇒ behind plan. Printed in the chart title at the data date.

Why duration-weighted. Cost-based EVM (AC / CV / CPI) is not computed because P6 exports routinely strip resource and cost tables. Duration-weighting — each activity contributes in proportion to its original working-day duration — is the industry standard fallback per AACE RP 27R-03. Full formula in METHODOLOGY §5d.

DCMA 14-Point Assessment: 7 pass, 4 fail, 3 not assessed.

SCL Appendix B compliance: 6 present, 0 partial, 1 not assessed.

App B §1 — Milestone scheduled / forecast / actual dates. 8 milestone(s) tracked with planned, forecast, and actual dates.

App B §2 — Critical activity identification. Critical activities are the schedule's own stored critical flags; driving paths to contractual milestones are traced through the driving relationships in the programme's own dates; near-critical paths use the schedule's own float.

App B §3 — Progress against baseline. 148 activities matched between the two schedules.

App B §4 — Narrative of changes in the period. Changes are summarised by WBS package and accompanied by recommended next actions.

App B §5 — Period delay enumeration with cause. 6 delay event(s) itemised; 4 (67%) carry both quantified impact and assigned entitlement classification. The remainder are topology events (direction-of-travel signals not sized without TIA) or events the rule-based classifier could not determine origin for from the description alone.

App B §6 — Acceleration measures. No duration reductions detected; activities were not shortened between the two schedules. The App B §6 answer for this period is 'no acceleration measures.'

App B §7 — Risk events. Not assessed by this engine. App B §7 requires identification of risks materialised in the period and forward-looking risks affecting the schedule, sourced primarily from the project's risk register and Monte Carlo schedule risk analysis (where applicable). Neither input is available to a schedule-only engine — this analysis is based on schedule files alone. The contractor's own risk register and any SRA outputs should be referenced alongside this report to address App B §7.

Delay events aggregated by the work breakdown structure node of each affected activity.

Top 5 work packages by critical-path movement (negative = pulled in):

• Foundation Piling — +10 working days net · +10 working days on the critical path · 2 events (2 critical)
• Excavation — +5 working days net · +5 working days on the critical path · 1 events (1 critical)
• Permits & Approvals — +4 working days net · +4 working days on the critical path · 1 events (1 critical)
• Plumbing & Fire — +14 working days net · 0 working days on the critical path · 1 events (0 critical)

The full rollup — every WBS node with a recorded event — is in the Excel appendix under the Delay Register sheet (filter by WBS column).

Activities that exist in one schedule but not the other. Added activities represent new scope; removed activities represent scope deletion.

• Added activities: 1 (total planned duration 14 working days)
• Removed activities: 0

The activity matching process uses four cascading strategies before an activity falls into these pools:

• Exact ID
• Normalised ID
• Name plus WBS path
• Name-only fallback

Surviving entries are genuine scope changes, not renumbering or WBS-restructuring artefacts.

Full per-activity lists (every added and removed activity) are in the Excel appendix under the Scope Changes tab.

The largest critical event on this analysis is SUB-210 — Piling rig mobilisation, a Duration change event adding 6 working days in isolation. The recommendations below should be applied to this event as a priority before the lower-impact items.

Concrete next actions derived from this analysis. Every recommendation below references a specific number, finding, or warning elsewhere in the report — nothing speculative.

Industry precedent (AACE RP 29R-03 §4.3; CIOB Guide §5.5) treats this section as a required deliverable element of any forensic report.

• Prepare narrative and evidence for the 2 critical events with a material isolated contribution (≥5 working-day movement of the project finish; largest = 6 wd). That column in the delay register carries the per-event figure; for each flagged event the forensic record should document cause, contractual position, and supporting documentation.
• Review the 1 added activity event(s) flagged 'Not assessed' in the Entitlement column. The classifier could not determine origin from the description alone; these need to be checked against the variation register and contract to assign an Employer risk / Contractor risk classification.

This section lists time windows where two or more independent critical delay events overlap. The "net impact" column shows the delay days that flow through to the project completion date under the methodology named in the disclosure at the top of the report; the "absorbed" column shows delay days that would otherwise have been counted twice and are removed from the total.

The delay register contains 4 measurable critical events. None met the SCL §10.4 independence test for concurrency — the events are either causally linked in the schedule network (one activity is upstream of the other in either the baseline or the update) or their time windows do not overlap. This is a defensible zero, not an absence of analysis: SCL true concurrency requires two or more independent critical chains contending for the finish during the same period. Where a schedule shows a single dominant delay chain — for example a vendor procurement sequence or a commissioning chain — the events on that chain are causally linked and correctly excluded. Where two or more independent chains exist, this section will populate with the windows during which they overlap. Review the delay register and the schedule logic to confirm the chain structure is expected.

The activities and relationships behind each failing DCMA item, most severe first. Tables are capped at 20 rows; the Excel appendix's “DCMA detail” sheet carries the full lists.

This report assesses the uploaded schedule against the published industry standards listed below. Each finding traces to a specific rule in one or more of those standards. The analysis is automated and deterministic — the same schedule file will always produce the same findings.

Scope of this analysis. This report is based solely on the schedule file(s) you uploaded. Determinations that — under AACE RP 29R-03, the SCL Delay & Disruption Protocol, or other cited standards — require evidence outside the schedule file have been flagged as candidates rather than concluded. Specifically, the following determinations and analyses require manual verification by a qualified delay analyst before being relied on for contractual purposes:

• Pacing vs concurrency — distinguishing contractor pacing (AACE §4.2.F / SCL §10) from independent concurrent delay requires contemporaneous notice, correspondence, and resource records that are outside the scope of schedule-only analysis.
• Constructive acceleration — identifying directed or constructive acceleration (AACE §4.4) requires correspondence and contract notices not available to the engine.
• Contractual classification — categorising delay events as excusable, compensable, or non-excusable depends on contract terms outside the schedule file.
• Concurrency during the overlap window — the SCL §10.4 test asks whether two delays were both critical during their overlap. The engine evaluates this as the union of the two schedules' critical-path membership, which is a snapshot-level approximation of the window-level test. A precise test would require a CPM walk per overlap interval, which is outside V1 scope. The approximation will under-detect concurrency where an activity was on the critical path only during a sub-window of the overlap and not at either snapshot date.
• As-built critical path — the report does not produce a stitched as-built critical path across multiple updates. On comparison reports the per-update critical path is shown for each schedule in the comparison (Driving Path section); on series reports an interim methodology paragraph describes the per-period substitute. A V1.1 release will add a cross-period as-built CP synthesis section to the series report Brief layer.
• Date basis. Every start and finish date in this report is each schedule's *current forecast* — the date work is now expected to occur, or its recorded actual date where the work is complete. In Primavera P6 that is the Remaining Early date; in Microsoft Project and Asta Powerproject it is the scheduled Start/Finish. The report does not use a tool's frozen Planned/target dates, which stop updating once an activity is in progress and so understate movement on a progressed schedule. Baseline dates stored inside a file (e.g. a P6 baseline) are read as recorded, and every variance compares the current forecast on each side.
• Float and criticality — the source tool's — every total-float and critical-path figure in this report (including the DCMA float checks, float paths, near-critical detection and milestone deliverability) is the value recorded by the scheduling tool that produced the file. ScheduleLens does not overwrite it. Where the source recorded no float and the activity is incomplete, ScheduleLens's own calendar-aware pass supplies one; completed activities are left unfloated rather than given an invented value. That gap-filling pass applies Retained Logic/Progress Override per the file's scheduling options but does not model Start/Finish-No-Later-Than or As-Late-As-Possible constraints, Expected Finish forcing, or an imposed must-finish date. ScheduleLens's own critical-path pass is used for change between two schedules — critical-path churn, bounded what-if, retained-logic versus progress-override, between-snapshot slip — where both sides run through the same engine; those figures are labelled as ScheduleLens's. Where the independent pass disagrees with the file's own critical flags, the disagreement is reported by the critical-path staleness check rather than resolved.
• Engine-attributed-vs-observed divergence — the engine-attributed delay figure is an attribution of observed completion movement to specific activity-level events. It can diverge from the observed figure in either direction. Undercount divergence (engine attributes less than observed) typically reflects unquantified topology changes, scope absorption, or parallel-path absorption the activity-level formula cannot capture without a CPM recalculation. Overstate divergence (engine attributes more than observed) typically reflects double-counting along a critical chain, scope-add events whose full duration is being counted, or concurrency absorption gaps. In both directions the observed figure is authoritative for the headline; the engine-attributed figure is a subordinate diagnostic surfacing what specific events contributed.

Where the engine raises a candidate flag for any of these determinations, the relevant section explicitly says so. The engine does produce a rule-based first-pass entitlement classification on each delay-register row (Employer risk, Contractor risk, Neutral, Concurrent, or Not Assessed) — this is a preliminary tagging based on activity-description keywords and category defaults, not a contractual determination. The classification is presented as '(prelim.)' in the column header and every row carries a review-note prompt to verify against the contract, the variation register, NCRs, and documentary evidence before relying on it.

Units. Day figures in this report are calendar days unless they are marked as working days. Two different quantities are being measured and the distinction is deliberate.

Movement between two dates — how far completion, a milestone or the schedule end has moved between submissions — is reported in calendar days. Elapsed time is the same quantity for every activity on a programme, so figures measured this way can be compared with each other, and they do not change when a calendar's holidays are edited. AACE RP 29R-03 directs that as-built comparison be carried out in calendar days for this reason, and cautions that float expressed in workday units differs between activities on different calendars; SCL Protocol §8.8 gives the same caution where multiple work-day calendars are in use.

Schedule properties — float, activity durations, the delay quantum recorded against each event, and the DCMA thresholds — are reported in working days, and are marked as such wherever they appear. These are not spans between two dates and have no calendar-day equivalent: an activity whose duration grows from 10 to 20 working days has no single elapsed-day value, because that depends on where in the calendar the work falls. The DCMA 14-point checks define their thresholds in working days, so restating them would change what is being tested.

A working-day figure is counted on the calendar assigned to the activity it describes, not on the project default — on a programme running five-day and seven-day calendars together, the same elapsed period is a different number of working days for different activities.

Use of AI. The ScheduleLens analysis engine computed every finding, figure, score and chart in this report. At the requester's election, a language model (qwen3-6-27b, via Venice) then wrote the explanatory prose in the sections “Executive Summary”, “What happened · Why · Where to investigate” and “Float-path risk”. It worked only from those computed results. It did not see the schedule file and did no analysis of its own. Where prose and a table or chart differ, the table or chart governs.

ScheduleLens is not affiliated with, endorsed by, or certified by AACE International, the Project Management Institute, the Defense Contract Management Agency, the Chartered Institute of Building, the Society of Construction Law, or the Government Accountability Office. Citations to these standards in this report are bibliographic, indicating the analytical basis for each check.