A schedule is not a calculation. It is arithmetic performed on a list of claims, and almost nobody audits the claims.
A refinery turnaround is planned at thirty-four days. The commercial window is thirty. The network has been run, the software has produced a critical path, and the number is what it is.
Then someone senior spends an afternoon with the sequence and finds four days — not by working faster or adding crews, but by pointing at three links and asking what makes each one true. One of them was a habit.
That afternoon is either the most valuable work anyone did on the turnaround, or the moment the plan stopped being a forecast. Which it is depends on a question nobody in the room will ask: would we have found that link if we hadn't needed to?
The Strategic Context
A modern schedule arrives looking computed. Software calculates early and late starts, float, the critical path and resource loading, and produces dates to the day.
None of that is where the duration comes from. Every calculated number is a consequence of statements a person typed in: this cannot start until that finishes. The teaching material behind this article is candid about the division of labour: it lists what scheduling software can do — the calculations, the scenarios, the reports — and then what it cannot, and the second item is that software cannot "determine the logical dependencies of tasks one to another".
The tool computes the consequences of a judgement it cannot make. That judgement is made early, usually by people junior to the decision it will eventually govern, and almost never revisited — because once it is inside the model it looks like output.
What Leaders Commonly Misread
The first misreading is that a schedule is a calculation. It is arithmetic performed on assertions. Change one and the arithmetic produces a different answer with the same authority — which is why two competent teams can plan the same work and differ by a fifth.
The second misreading is that a dependency is a fact. The standard taxonomy — finish-to-start, finish-to-finish, start-to-start, start-to-finish — describes the shape of a link and says nothing about whether it exists. A more useful classification asks what enforces it:
- Physical. Concrete cures before you load it; the vessel is cool before anyone enters. Properties of the world, not negotiable.
- Contractual or regulatory. A permit precedes the work; an inspection precedes sign-off. Real, but with owners and dates, and occasionally movable.
- Resource. B follows A because the same crew does both. Real today; removable with money.
- Convention. We have always done it in that order. Not real at all, and indistinguishable from the other three inside the model.
Only the first two are properties of the work. The others are properties of the organisation, and the fourth is nobody's decision in particular.
The third misreading is that compression is a technique. It is presented as a set of moves — crash the path, run things in parallel, add resource. In practice the largest single source of time is discovering that a link was never there. Nothing was sped up. The model was corrected.
The fourth misreading is that this correction is unambiguously good news. It is the same act whether it is performed as analysis or as accommodation, and the difference is not visible in the output. A dependency tested before anyone knew the target is a finding. The identical dependency removed on the afternoon the target became unavoidable is a hypothesis that happened to be convenient, and it will be tested for the first time in the field.
Reframing the Issue
The reframing is to treat the schedule as a register of claims, each with an owner, rather than as a plan.
That sounds administrative and it changes what governance can ask for. A plan can only be approved or challenged whole; a register of claims can be audited one line at a time. Three columns suffice for every link on the longest path: who asserted it, what enforces it, what happens if it is wrong.
The third column does the work. A physical dependency that is wrong produces a safety event; a convention that is wrong produces a slightly longer programme. Those errors have nothing in common, and a schedule that does not distinguish them treats them identically.
This is not a claim about what limits the work. Constraints — the conditions that bound how an initiative may be delivered at all — are a different object with their own reading, set out in [Related article: Read the Constraints, Not the Deliverables]. A constraint says you may not. A dependency says not yet. Organisations routinely record the second in a tool and the first nowhere.
Nor is it a claim about interfaces. Where work crosses a boundary between two functions and value is lost because nobody owns the crossing, that is a distinct failure with its own treatment in [Related article: The Work Happens Inside Functions. The Value Is Lost Between Them.]. Here the boundary may be entirely internal to one team. The defect is in the assertion, not the handover.
Strategic Analysis
A teaching exercise that gives the game away
A course exercise supplies a fourteen-task technology rollout with stated durations and dependencies. Along its longest path the programme runs twelve weeks. The allowed time is eleven, and students are asked to close the gap.
The worked answer is a single line: "'Plan Installation' is not dependant on purchase or training." One link in the supplied list was never real, and removing it closes the entire gap. The exercise then asks the students a question that most enterprises never ask themselves: what does this experience tell us about the logic of the dependencies?
The most instructive words are in the answer slide: the programme has been "re-aligned to match the allowed time for project management". The eleven weeks were not derived from the work. They came from a management budget line — one of the fourteen tasks is Manage Project, at eleven weeks — and the sequence was then found to accommodate them.
Read charitably, that is exactly right: a target forced a re-examination and the re-examination found an error. Read less charitably, the error was found because it needed to be found. Both readings are available from the same evidence, and that is the point. An organisation that cannot tell which of the two it just did has no idea how much confidence its schedule deserves.
The same property, one level down
Duration estimates carry the identical defect in a less visible form. The three-point method presents a duration as arithmetic — the optimistic, four times the probable and the pessimistic, divided by six — and the teaching material's definitions of the inputs are the interesting part: the optimistic figure is "the shortest time within which only 1% of similar projects are completed", the pessimistic "the longest time within which 99% of similar projects are completed".
Those are percentile claims about a population of comparable work. Almost no enterprise holds that population, and the numbers are supplied instead by whoever is asked, in a meeting, from memory. The formula is honest; the inputs are an opinion wearing a distribution.
Whether a plan's load-bearing numbers survive comparison with what the organisation has actually achieved is a separate discipline with its own method, set out in [Related article: Enough Technical Depth to Test the Answer]. That method interrogates a rate. What is at issue here is a precondition — a claim that one thing cannot begin until another ends — which no historical rate can confirm or refute. It is tested by asking what physically or contractually enforces it, and the answer is usually available in under a minute from the person who does the work.
What the confusion costs
A live broadcast build shows the cost in miniature. The install schedule says cabling precedes rigging because it always has. In fact rigging is prevented by cabling only where the two share access — about a fifth of the venue. Held as a blanket dependency the sequence adds two days to every build; examined once, it adds two days to a fifth of one.
That difference had been paid for years, and no incident, overrun or post-project review would have surfaced it, because the programme always finished on the schedule it set itself. An unnecessary dependency does not produce a failure. It produces a slower baseline that everybody hits — the hardest waste to see and the easiest to keep.
None of this is an argument for planning less. The economics of defining work poorly and paying for it later are a separate and substantial matter, treated in [Related article: The Front End Owns the Outcome]. This is an argument for planning with a record of who claimed what.
Decision Framework
Five steps, applicable to any schedule before it is baselined and worth repeating at any major replan.
1. Extract the longest path and nothing else. Between eight and twenty links on most programmes. Everything off that path can wait; nothing off it is setting your duration.
2. For each link, name what enforces it. One of four answers: physical, contractual, resource, or convention. The person answering should be the one who does the work, not the one who built the schedule. Where nobody can answer, the link is a convention that has not admitted it.
3. Record who asserted it, and when. This column changes behaviour more than any other step, because it makes a dependency an act by a named person rather than a property of a diagram.
4. Price the resource dependencies. These are the removable ones. For each, state what it would cost to break — a second crew, a second rig, a parallel line — and what that buys in days. Few organisations have seen their schedule as a purchasable set of options, and two or three are usually cheap.
5. Re-test on a fixed date, not on a bad day. Set the re-examination before the pressure arrives — at the end of definition, or at a gate. A dependency challenged on a calendar date is analysis. The same challenge made in the week a deadline becomes unavoidable is something else, and everyone downstream will treat it accordingly.
A supporting convention: an assertion that survives a challenge should be recorded as tested, with a date. Otherwise the same link is re-argued every cycle by people who do not know it was already examined, and the organisation pays the analysis cost repeatedly without ever banking the answer.
From Strategy to Execution
Immediate. Take the schedule closest to baseline and run steps one and two on its longest path. Half a day with the planner and two people who do the work. The typical result is that one link in six cannot be defended, and that at least one of those is worth material time.
Medium term. Change what a baseline submission must contain. A schedule presented for approval should arrive with its longest path listed, each link classified, and the asserter named. This is a reporting change rather than an analytical one, and it converts an unexaminable artefact into an examinable one.
Long term. Build the record. An organisation that keeps a register of tested dependencies across programmes accumulates a body of knowledge about which of its habitual orderings are real — and its absence is why the same unnecessary link survives ten programmes in a row.
Two boundaries are worth naming here. This is a discipline of examination, not of delegation: nothing above sets a threshold, obliges a notification or bounds anyone's authority, which is the separate design argued in [Related article: Authority With an Expiry Date]. And a function that spends its time reconciling dependencies across a portfolio is doing real and undervalued work that is frequently mistaken for something else — a question examined in [Related article: Is Your Portfolio Function Selecting, or Supervising?].
Signals to Monitor
- Time found late, repeatedly. Where the last few programmes each recovered days shortly before a deadline, the organisation is discovering false dependencies under pressure rather than by design.
- Schedules that never vary between similar jobs. Identical durations across different sites or scopes indicate a copied network, and a copied network carries copied assertions.
- Planners who cannot name the source of a link. Ask about three links on the critical path. If the answer is the previous schedule, the assertion has no owner.
- Compression achieved without cost. Genuine crashing costs money. Compression that costs nothing is a model correction, and it should be recorded as one so that the next programme starts from the corrected model.
- The same sequence surviving a change of method or technology. New equipment, old ordering — where conventions are most visible and least examined.
- Estimates arriving as single numbers. Where the three-point inputs are never seen, nobody can tell a range from a preference.
Questions for the Leadership Team
- On our largest current programme, who asserted the three links that set the end date — and has anyone asked them what enforces those links?
- When we last recovered time late in a programme, did we find an error or accommodate a target? How would we know?
- Which of our dependencies are resource dependencies we could buy our way out of, and what would each cost in days?
- Do we hold any record of dependencies we have previously tested, or does every programme re-argue them from scratch?
- Where in our schedules does the duration come from the work, and where does it come from a budget line?
- If a competitor ran the same scope, would they arrive at our duration — and if not, what would they have questioned that we did not?
Closing Perspective
The most consequential numbers in a delivery plan are not the ones the software calculates. They are the ones a person typed in before anybody senior was paying attention, and they acquire the authority of computation simply by being inside the model.
Some of those assertions describe the physical world and cannot be moved. Some describe a contract, and have an owner. Some describe how the organisation currently allocates its people, and can be bought out. And some describe nothing at all except the order in which the work happened to be done the last time, which is a poor reason for it to determine when a market window opens.
Telling those four apart takes an afternoon. It requires somebody senior to ask a question that sounds naive, in a room where the schedule is treated as a result rather than a set of claims — and to ask it on a date chosen in advance rather than on the day the answer is needed. Everything else in the plan rests on it, including the promises other people have made to it, which is the subject of [Related article: Most of Your Plan Is Somebody Else's Promise].
About EraNorth Insights
EraNorth Insights publishes practical analysis on strategy, projects, operations, transformation and decision intelligence for professional and organisational use. About EraNorth.