Why your schedule cannot hold your contract's rules

What a programme can say

A CPM programme is a directed network of activities connected by dependencies. Each dependency says: this work enables that work, with a type (finish-to-start, start-to-start, finish-to-finish, start-to-finish) and a lag (a number of days between them). Each activity carries a duration. Calendars define which days are working days. Constraints pin activities to dates or date boundaries. The engine computes the earliest and latest dates, the float, and the critical path.

This model is good at a specific thing: representing the physical and logical sequence of work. Concrete must cure before formwork is stripped. Rebar must be placed before concrete is poured. Electrical rough-in follows framing. The relationships are real, the durations are measurable, and the schedule computes from them deterministically.

The model also handles resource constraints, date commitments, and progress. A planner can represent “this milestone must finish by 30 June” with a Finish-No-Later-Than constraint. A planner can record that an activity started on 14 March and has twelve working days remaining. The engine folds those facts into the computation and produces dates, float, and a critical path.

Within its domain, CPM scheduling is precise, auditable, and well understood. P6 has been the dominant tool for this computation for decades, and it is capable.

What a programme cannot say

Consider a contract clause: “The Employer shall provide site access for Block C no later than 14 days before the Contractor’s planned commencement of foundation works for Block C.”

A planner reads this clause and models it as a predecessor. Perhaps a milestone — “Block C site access” — linked finish-to-start to the first foundation activity, with a lag. The schedule computes, and the milestone sits at its expected date.

But the programme has lost the rule. What the contract actually states is a conditional obligation: when the Contractor plans to commence foundation works, a clock starts, and the Employer must provide access within a window measured backward from that date. The obligation belongs to the Employer. The clock is 14 days. The trigger is the planned commencement. The consequence of breach is a delay entitlement.

None of that is in the programme. The programme holds a finish-to-start link with a lag. It holds no party. It holds no clock. It holds no trigger condition. It holds no consequence. If the milestone slips, the programme recomputes dates — it does not know that someone failed an obligation.

This is not a deficiency of P6 specifically. It is a structural limitation of CPM logic. Dependencies express enablement — X enables Y. They do not express conditions — when X occurs, Y is required within N days, by party Z.

Rules that live outside the schedule

Construction contracts are dense with conditional rules. Here are four patterns that appear in nearly every large project.

Notice periods. The contract requires written notice within a defined number of days of an event — a delay, a variation, an instruction. “The Contractor shall give notice to the Engineer within 28 days of becoming aware of the event.” The event is the trigger. Twenty-eight days is the window. The Contractor is the responsible party. Failure to give notice within the window may forfeit an entitlement. This rule cannot be modelled as a dependency, because the trigger is an event that may or may not happen, and the obligation arises only when it does.

Access and possession obligations. The Employer shall provide access to designated areas by specified dates, or within a period before planned commencement. These are often sectional — Block A by one date, Block B by another — and they interact with the programme because the planned dates determine when the obligation falls due. A planner models the access as a predecessor, but the programme cannot record that the obligation belongs to the Employer and that late access is a delay event with contractual consequences.

Approval windows. The Engineer shall respond to a submission within 21 days. The Contractor shall revise and resubmit within 14 days of receiving comments. These are sequential conditional obligations — the clock on the second starts when the first is satisfied. A planner might model the approval as an activity with a 21-day duration, but the programme cannot distinguish between “the work takes 21 days” and “the other party has 21 days to respond, and failure to respond is a breach.”

Sectional completion. The contract defines sections of the works with individual completion dates and individual delay damages. Each section has its own deadline, its own float, and its own commercial consequences. A planner models sectional milestones, but the programme cannot hold the commercial rule: delay beyond this date, by this party, costs this amount per day. The milestone is a date; the rule is a conditional commercial consequence.

Where the rules live today

In practice, these rules live in several places at once, and no single place holds them all.

The contract holds the definitive text, but contracts are not structured data. A 200-page contract might contain dozens of conditional obligations scattered across clauses on access, notices, variations, extensions of time, testing, completion, and defects. Reading them requires a lawyer or a planner who has studied the contract carefully, and even then, the rules are held in the reader’s interpretation, not in a system.

Some planners maintain a tracker — a spreadsheet listing key obligations, responsible parties, and deadlines. This works as long as the planner maintains it, remembers to check it, and connects it mentally to the programme. But the tracker is disconnected from the schedule: when the programme moves, the tracker does not know, and when an obligation falls due, the programme does not know.

Meeting minutes record discussions about obligations — “the Employer confirmed access to Block C will be provided by 1 September” — but minutes are prose, filed in folders, and rarely connected back to the programme or the tracker.

Email threads hold commitments and responses — “we confirm that drawings will be issued by Friday” — but email is unsearchable in the way project control requires: by party, by obligation, by deadline, by whether it was fulfilled.

Memory holds the rest. An experienced project manager carries an internal model of who owes what and when. This model is accurate, current, and entirely personal. When that person moves to another project, the model goes with them.

What this fragmentation costs

The fragmentation is invisible during smooth execution. When work proceeds as planned, obligations are met on time, and notices are given when required, the system works — not because it is connected, but because people are attentive.

The cost arrives when a dispute begins.

A delay claim requires demonstrating that a specific party failed a specific obligation at a specific time, and that the failure caused a specific consequence. The evidence must be assembled retrospectively: the contract clause that creates the obligation, the event that triggered it, the correspondence that shows when (or whether) it was satisfied, the programme that shows the effect on dates, and the contemporaneous record that connects them all.

This reconstruction is manual, expensive, and uncertain. Months of email, minutes, and correspondence must be searched. The sequence of events must be rebuilt from fragments. The connection between a contractual obligation and a programme activity must be argued, because it was never recorded. The planner’s tracker — if one existed — may not have survived a personnel change. The project manager’s memory is no longer available, or is contested.

A claims consultant reconstructing a delay chronology is doing, after the fact and at great expense, what the project should have been doing continuously: tracking which obligations exist, when they were triggered, whether they were satisfied, and what the consequence was when they were not.

Holding the rules as facts

What would it mean for a system to hold these rules as structured data?

A conditional rule has four components: a trigger (an event that causes the obligation to arise), a requirement (what must be done), a window (the time within which it must be done, counted in working or calendar days against a stated calendar), and a responsible party (who must do it).

When an event matching the trigger occurs — a milestone is reached, a document is issued, a delay is recorded — the rule produces an obligation: a specific act required of a specific party, due on a computed date. The obligation carries its trigger event, its source clause, and its deadline. It is either satisfied (with evidence — the notice sent, the access provided, the approval issued) or it is not. If the deadline passes without satisfaction, the breach is a fact — computed, not alleged.

The system watches. A notice period does not depend on someone remembering to check a spreadsheet. An access obligation does not depend on someone connecting a contract clause to a programme date. An approval window does not depend on someone filing the response and updating a tracker.

And when a dispute begins, the record already exists. The obligation, its source clause, its trigger event, its deadline, and its satisfaction (or lack of satisfaction) are all connected and timestamped. The delay chronology does not need to be reconstructed, because it was recorded as it happened.

This is not a reporting feature bolted onto a scheduler. It requires a different data model — one where obligations, events, evidence, and parties are first-class entities connected to the programme, not annotations beside it.

The schedule is a view, not the model

Here is the broader point. A CPM programme is a temporal model of work: what happens, in what order, and when. It is the right model for computing dates and float. It is not a complete model of a construction project.

A project is also its contract — the obligations it creates, the conditions it sets, the clocks it starts. A project is its documents — the specifications that define requirements, the drawings that define scope, the BOQ that defines quantity. A project is its events — what actually happened, when, caused by whom, evidenced by what. A project is its procurement — not just the installation activity, but the chain of design, approval, ordering, manufacture, and delivery that must complete before installation can begin.

The schedule represents the temporal relationships between activities. It does not represent the contractual relationships between parties. It does not represent the causal relationships between events. It does not represent the documentary relationships between requirements and the work that fulfils them.

What CPM scheduling software does — computing dates, float, and critical paths from a network of activities and dependencies — it does well. The limitation is not in the computation. It is in the model: the schedule can hold activities and dependencies, and the project needs to hold much more.

A richer project model — one that connects activities, documents, obligations, events, evidence, and parties in a single structured graph — does not replace the schedule. The schedule is the temporal view of the model. The critical path is still computed from activities and dependencies. Float is still the room an activity has before it moves something that matters.

But the model also answers questions the schedule never could. Which contractual obligations are due this month? Which ones were triggered by last week’s events? Who is responsible, and what is the evidence that they satisfied (or failed) the requirement? When the completion date moved, which events contributed to the movement, and which party’s actions caused each one?

These are not reporting questions. They are questions about facts that the system either holds or does not hold. A system that holds them can answer. A system that holds only activities and dependencies cannot — regardless of how well it computes the critical path.

We are building Humigo to hold them. The programme is the foundation — full CPM scheduling, exact semantics, XER in and out. The project model is what makes the programme worth more than a schedule: the contract’s rules as facts the system watches, the site’s events as evidence the record keeps, the documents’ requirements as structure the programme carries. One connected model, where the schedule is the view that computes dates, and the project is everything those dates are accountable to.