Principles

What Kind of Work Were These Instruments Built For?

Delivery governance instruments were designed for large, physical, contract-heavy programs. They still carry those assumptions into work that shares none of them.

Kevin Jogin · 23 Aug 2026 · 11 min read

Instruments carry the assumptions of the problems they were invented to solve, long after anyone remembers what those problems were.

Look at the standard apparatus of delivery governance — the bar chart, the critical path, the dependency network, the work breakdown, the earned value index, the phase gate. Ask a straightforward question about each: what kind of work was this designed for?

The answer is remarkably consistent, and it is not the work most enterprises are doing now.

The formative instruments of the discipline emerged from a specific and unusual class of program: very large, physical, contract-heavy, single-client, schedule-dominated, with specifications that were difficult to change once set. Munitions production. Aircraft manufacture. A fleet ballistic missile. Oil pipelines. Civil construction. Naval facilities. Work where the task list could be enumerated in advance, where the hard problem was coordinating thousands of known activities across hundreds of contractors, and where the thing being built was the same thing at the end as it had been on the drawing.

Those instruments were superb answers to that question. The difficulty is that they are still the default answer, and the question has changed.

The Strategic Context

The conventional histories of project management run through a familiar sequence. [FACT CHECK REQUIRED] — the dates and attributions summarised in this paragraph and the next appear in teaching material dating from around 2013 and should be verified independently before publication; the argument that follows does not depend on any individual date being correct.

A production scheduling chart developed at a military arsenal around 1914. A project office established in a military materiel division in the 1930s to monitor aircraft development. The term project manager applied to a single accountable individual on a major pipeline in 1951. A special projects office created in 1955 to develop a submarine-launched ballistic missile, which in 1957 produced a network technique for managing its many hundreds of contractors. A critical path method developed in 1959. Recognition of project management as a distinct discipline in the management press in the same year [SOURCE DETAILS REQUIRED]. A precedence diagramming method developed in 1964 for a naval facilities authority. Adoption beyond construction and defence during the 1970s [FACT CHECK REQUIRED], alongside the establishment of the first professional bodies [FACT CHECK REQUIRED].

Recited as a timeline this is inert. Read as evidence about design intent it is highly informative, because every entry describes the same class of problem.

A separate account in the same literature lists the forces that turned project management into a distinct career: the need to sustain defence capability during the Cold War, the pursuit of primacy in space research, the drive for greater speed to market in consumer goods, rising complexity in project requirements, the growing influence of what it calls people power and its effect on delivery, flatter management structures, and faster global communications enabling teams dispersed across the world. Its conclusion is that traditional functional structures, with specialist managers overseeing specialist teams, were no longer adequate to deliver complex projects.

That conclusion was right. It is also the last time most organisations examined the question.

What Leaders Commonly Misread

The first misreading is that these instruments are neutral. They are not, and no instrument is. A critical path network encodes the belief that the sequence of activities is knowable and that the binding constraint is the arrangement of tasks in time. A work breakdown structure encodes the belief that the whole can be decomposed into parts before the work begins. An earned value index encodes the belief that a stable baseline exists against which progress is meaningfully measured.

Each belief was true of a Polaris-class program. Each is contestable in a program whose scope will be discovered, whose dependencies are behavioural rather than technical, and whose value depends on whether people change how they work.

The second misreading is that the answer is to abandon them. It is not, and this is where a good deal of contemporary commentary goes wrong. These instruments remain excellent for the work they were built for, and a considerable amount of enterprise work still is that work: a substation upgrade, a plant relocation, a regulatory implementation with a fixed statutory date. Discarding a critical path network on such a program in the name of modernity is not sophistication.

The useful move is neither adoption nor abandonment. It is knowing which assumption each instrument rests on, and checking whether that assumption holds for the work in front of you.

The third misreading is temporal. Executives tend to assume the instruments have been continuously updated to match the work. Some have. But the default governance architecture in most large organisations — phase gates, baselines, variance reporting against plan — is recognisably the architecture of a mid-twentieth-century capital program, adapted at the edges. [FACT CHECK REQUIRED] — the principal body of project management guidance has itself moved substantially toward a principles-based structure in recent editions, away from the prescribed process architecture the teaching material behind this article describes; the current edition and structure should be confirmed before publication. That shift is itself evidence that the profession recognised the problem well before most enterprises adjusted their governance.

Reframing the Issue

The reframing is to treat every governance instrument as a claim about the work, and to check the claim rather than the instrument.

Four claims sit underneath the standard apparatus:

  • Scope is knowable in advance. Required by the work breakdown, the baseline, and any variance-based reporting.
  • Dependencies are technical. Required by network scheduling, which represents dependency as a logical relation between tasks rather than as a negotiation between parties with different objectives.
  • Value arrives at handover. Required by phase-gated funding and by completion-based measures of success.
  • The constraint is coordination. Required by the entire apparatus, which was built to sequence very large numbers of known activities.

Where all four hold, the instruments perform superbly. Where one fails, the instrument does not merely become less useful — it becomes actively misleading, because it continues to report confidently on a quantity that no longer means what it appears to mean.

Strategic Analysis

What happens when a claim fails

Take the second claim. Network scheduling represents a dependency as a logical relation: activity B cannot start until activity A finishes. That is a faithful model of pouring concrete before framing. It is a poor model of the most common dependency in modern enterprise change, which is that a team in another function must agree to something, and their willingness depends on their own objectives, incentives and workload.

Represented on a network, that dependency has a duration and a predecessor. In reality it has a negotiation, a set of competing priorities, and no reliable relationship between elapsed time and progress. The plan will show it as fifteen days. It will take fifteen days or four months depending on factors the instrument cannot represent, and the schedule will report variance as though the difference were an execution failure.

This is the same phenomenon described in [Related article: The Work Happens Inside Functions. The Value Is Lost Between Them.] — the organisational interface, invisible to instruments built for technical interfaces.

Take the third claim. Phase-gated funding with completion-based success measures assumes value arrives when the thing is delivered. For a bridge, near enough. For a program whose benefit depends on thousands of people working differently, value arrives over the following two years, in operations, and the instrument stops measuring at exactly the point the interesting part begins. The consequence is examined in [Related article: The Hidden Cost of Putting Work Into Project Form].

The stakeholder instruments carry the same inheritance

It is not only the scheduling apparatus. The standard stakeholder instruments were shaped by the same era — large programs with a clear client, an identifiable set of contracting parties, and consent that was mostly procedural. That inheritance shows in what they measure: authority and attention, rather than exposure and the capacity to withhold consent, which is treated in [Related article: Your Stakeholder Map Measures Attention, Not Exposure].

Why this is a strategy question rather than a methodology question

Governance instruments determine what an executive can see. An organisation whose entire governance apparatus assumes knowable scope will systematically under-detect problems in work where scope is discovered, because its instruments report variance against a plan rather than uncertainty about a goal. The reporting will look healthy until it does not.

That is a strategic exposure, not a process preference. It means the enterprise's early-warning system is calibrated for a class of failure that is no longer its dominant class — and no amount of diligence at the steering committee compensates for an instrument that is not measuring the thing that will go wrong.

The related question of whether a single standard method can be enforced across genuinely different kinds of work is examined in [Related article: Why "The Principles Apply to Any Project" Is Only Half True]. This article explains why the transfer fails: the instruments were designed against assumptions, and the assumptions do not travel.

Decision Framework

A four-claim test, applied to any significant initiative at initiation.

1. Is scope knowable in advance? If most of it is, baselines and variance reporting are appropriate. If a material portion will be discovered, add an explicit measure of what remains unknown, and treat variance reports as provisional rather than as performance data.

2. Are the dependencies technical or behavioural? Count them. Where behavioural dependencies dominate, network scheduling will produce a plan that looks precise and predicts poorly; supplement it with a named owner and an agreed decision date for each inter-party dependency.

3. Does value arrive at handover or afterwards? Where it arrives afterwards, extend the measurement period past closure and assign the benefit to the receiving function, or the instrument will declare success before the question has been answered.

4. Is the constraint coordination, or something else? If the binding constraint is a scarce skill, a regulatory decision, a legitimacy problem or an unresolved strategic choice, coordination instruments will not relieve it, and applying more of them consumes attention without moving the constraint.

The output is not a methodology selection. It is a short statement of which standard instruments will be trusted on this initiative, which will be used with a caveat, and what has been added to cover what they do not see.

From Strategy to Execution

Immediate. Apply the four-claim test to the three largest initiatives in the portfolio. Where an initiative fails two or more claims, the governance pack it produces is probably reassuring the leadership team about the wrong things, and the first correction is to name that openly at the next board.

Medium term. Build a small instrument register: for each governance artefact the organisation requires, one line stating what it assumes and when it should not be trusted. This is a one-page document, it takes an afternoon of argument to produce, and it is more valuable than a methodology refresh because it makes the assumptions discussable.

Long term. Reconsider the default. Most large organisations have one governance architecture applied to all significant work, inherited from the capital program tradition. A deliberate choice of two or three architectures, matched to the four claims, is a substantial change and should be made consciously rather than allowed to happen through local workarounds — which is what happens now, invisibly, when teams maintain a real plan alongside the one they report.

Signals to Monitor

  • A shadow plan. When teams maintain their own tracking alongside the official artefact, the official instrument has stopped representing the work. This is the single most reliable indicator, and it is usually well known below the executive level and never reported upward.
  • Repeated rebaselining. More than two rebaselines in an initiative's life indicates that scope was not knowable in advance and the baseline instrument was the wrong claim.
  • Green until red. Status that holds steady and then fails discontinuously indicates instruments measuring activity against plan rather than uncertainty about outcome.
  • Dependencies expressed only as dates. Where an inter-party dependency has a duration but no named counterparty and no decision date, it is being modelled as technical when it is behavioural.
  • Post-closure benefit questions with no owner. If nobody can answer what happened to the benefits eighteen months after delivery, the measurement apparatus stopped at handover.
  • Guidance changing faster than governance. The professional standards have moved toward principles and judgement; where an organisation's internal governance has not moved at all in a decade, the gap is worth examining deliberately.

Questions for the Leadership Team

  1. For our three largest initiatives, which of the four claims — knowable scope, technical dependencies, value at handover, coordination as constraint — actually hold?
  2. Where do our teams maintain a shadow plan, and what does that tell us about what our official reporting represents?
  3. Which of our governance instruments have we ever examined for the assumptions they carry, as opposed to the compliance they require?
  4. Is our early-warning system calibrated for the kind of failure we are now most likely to experience?
  5. When did we last change our governance architecture, and what prompted it?
  6. If an initiative's dominant risk is legitimacy or an unresolved strategic choice, what in our current apparatus would surface it?

Closing Perspective

There is nothing wrong with instruments designed for mid-century capital programs. They solved a genuinely hard problem and they solve it still. The error is not in their design; it is in their promotion to universal defaults by organisations that never asked what they were built to assume.

An instrument that reports confidently on an assumption that has failed is worse than no instrument, because it substitutes precision for accuracy and gives an executive team the impression of visibility. That is how programs stay green until the quarter they do not.

The remedy is unglamorous and available immediately: write down what each of your governance artefacts assumes, and check the assumptions against the work. Organisations that do this rarely conclude they should throw the instruments away. They conclude they had been reading them as measurements when they were only ever claims.


About the author
Kevin Jogin is Founder & Principal Advisor at EraNorth. Meet the Founder.