16-Civ-B8 Management of Construction · May 2014
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Paper format. National Exams, May 2014 — 98-Civ-B8 Management of Construction (the paper now catalogued as 16-Civ-B8). Three hours, closed book; one of two approved calculator models permitted. Six questions of equal value (20 marks each); the rubric states that any five constitute a complete paper and that only the first five presented in the answer book will be marked. All six are worked here, because this set is a study resource rather than an exam script.
Reference texts.
Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.
Delay analysis proceeds in two stages. The first is classification: deciding, event by event, who bears the risk of the time lost and therefore whether the contractor is entitled to more time, to more money, to both, or to neither. The second is quantification: proving how much of the overall project overrun each event actually caused, which requires a schedule model and a method for interrogating it. The four pairs in the question map onto that structure — the first three are classification questions, the fourth is a quantification question.
Excusable versus non-excusable delays. An excusable delay is one caused by an event that lies outside the contractor’s control and is not attributable to its fault or negligence. Owner-directed changes, late issue of drawings or approvals, late access to the site or to a work front, differing subsurface conditions, and force-majeure events such as fire, flood or abnormally severe weather beyond the specified baseline all qualify. The consequence of an excusable delay is an extension of time: under CCDC 2 GC 6.5 the contract completion date moves out, and with it the contractor’s exposure to liquidated or general damages for late completion. A non-excusable delay is the contractor’s own — late mobilisation, under-manning, defective work requiring rework, failure to procure long-lead material, or the default of its own subcontractor or supplier, whose acts are the contractor’s responsibility as against the owner. It earns no extension; the contractor must accelerate at its own cost or accept the consequences of finishing late. The distinction turns on risk allocation in the contract, not on fairness in the abstract: an event is excusable because the contract, expressly or by implication, has put its risk on the owner or on neither party.
Compensable versus non-compensable delays. This second cut applies only within the excusable category, and asks whether the extension of time comes with money. A compensable delay is an excusable delay caused by the owner or by someone for whom the owner is responsible — a change order, a suspension, late information, interference by a separate contractor, or an owner-supplied item that arrives late. Because the owner caused it, the contractor recovers its time-related costs: extended site overheads and general conditions, extended equipment and supervision, escalation on labour and material, and in appropriate cases the cost of disruption and lost productivity. A non-compensable delay is excusable but caused by neither party — force majeure, unusually severe weather, and in many contracts industry-wide labour disputes. The contractor gets relief from damages through the extension of time but bears its own prolongation costs, and the owner bears its own losses. CCDC 2 mirrors this split directly: GC 6.5.1 and 6.5.2 give time and, where the cause is the owner’s, reasonable costs, while GC 6.5.3 gives time alone for events beyond the control of either party. It is worth adding that a delay can be non-excusable and compensable in the other direction — the owner recovering its own losses from the contractor — which is what liquidated damages clauses exist to liquidate.
Concurrent versus non-concurrent delays. Concurrency arises when two or more delay events, at least one of them the owner’s risk and at least one the contractor’s, overlap in time and each is independently capable of delaying completion — that is, each affects the critical path. It is the hardest problem in the field because cause and effect can no longer be separated cleanly. The prevailing approach in Canadian and Commonwealth practice, reflected in the Society of Construction Law Delay and Disruption Protocol, is that true concurrency yields time but not money: the contractor receives an extension of time, because the owner cannot recover damages for a period it delayed itself, but recovers no prolongation costs, because it would have incurred them anyway through its own delay. The Protocol also draws two refinements worth naming. The first is the difference between true concurrency, where the two delays begin in the same period, and sequential delays whose effects merely overlap, which most analysts treat differently. The second is pacing: a contractor that consciously slows a following activity because an owner delay has already made speed pointless has not caused a concurrent delay at all, provided it can show the deliberate election and the available float. A non-concurrent delay is the straightforward case — a single event drives the critical path in a given period, so cause, effect and entitlement are traceable and the full remedy for that category of delay follows.
But-for versus windows analysis. These are the two dominant retrospective quantification methods. A but-for analysis, also called collapsed as-built or as-built but-for, starts from a validated as-built schedule of what actually happened, removes the delay events attributable to one party, and re-computes — “collapses” — the network to see when the project would have finished but for those events. The difference between the collapsed date and the actual date is the delay attributed to that party. Its attractions are that it needs no reliable baseline programme and that it works with facts rather than plans; its weaknesses are that it is a single retrospective model, that the answer depends on which events the analyst chooses to extract and in what order, and that it cannot represent a critical path that shifted during the works or the contractor’s contemporaneous re-sequencing decisions. A windows analysis, also called time-slice or time-impact analysis, divides the project into consecutive windows bounded by contemporaneous schedule updates, and within each window identifies the critical path as it then stood, measures the slippage that occurred, and attributes it to the events active in that window; the window results are then summed. Because it re-examines criticality period by period, it captures shifting critical paths, absorption of float, mitigation and pacing, and it aligns with how a project was actually managed — which is why the SCL Protocol prefers contemporaneous, window-based methods where the records support them. Its cost is exactly that dependency: it requires a validated, logic-sound baseline and regular, honest schedule updates, and where those do not exist the method degenerates into the analyst’s reconstruction. In practice a well-run claim uses a windows analysis as the primary method and a but-for collapse as a corroborating cross-check, and the choice is usually dictated by the quality of the schedule records rather than by theory.
