Give two experienced executives the same scope document and ask what kind of leader the work needs. They cannot answer, and neither can you, because the scope document does not contain the information.
Here are two initiatives, described as most organisations describe them.
The first, a hypothetical teaching scenario: extend water infrastructure to regional townships and agricultural land. Connect small townships to the mains supply. Provide irrigation to grape growers, accessed under a strictly monitored roster. Maintain optimum mains pressure throughout the year.
The second, also hypothetical: design and construct a new convention centre. A multifunction exhibition space usable for exhibitions, conferences and conventions. Large seating areas alongside smaller presentation spaces. Catering, audio and information systems capable of supporting a full-capacity convention. Car parking to service the area.
Both read as conventional infrastructure and construction scope. Both would be assessed by most capital committees on cost, schedule and technical feasibility. Both would attract a shortlist of delivery leaders drawn from broadly the same pool.
Now read what actually binds each of them, and the two initiatives stop resembling one another at all.
The Strategic Context
Deliverables describe what will exist when the work is finished. They are necessary, they are what the money buys, and they are almost useless as a guide to how the work must be led.
Constraints describe what cannot move. They determine the sequence, the risk profile, the negotiating posture, the governance cadence and — most consequentially — the kind of judgement the leader will be required to exercise under pressure. Two initiatives with similar deliverables and different constraints are different jobs.
The first hypothetical carries these constraints: salinity in the region; local resistance to the scheme; the fact that the project takes more water from the local river system; and a requirement to be economically viable through the sale of water.
The second carries these: a limit set on budget; a strict timeframe, because convention bookings are already in place; construction over a suburban rail terminus that must continue to be used at the required capacity at all times; minimum disturbance to access to the surrounding cultural precinct; and nil disruption to access to the nearby hotel and its surrounds.
The first is not, in any important sense, a water engineering problem. It is a legitimacy problem with a water engineering component. The binding constraint is consent — from a community that resists the scheme, in a catchment where taking more water is contested, with an environmental condition that will be used as the argument against it.
The second is not a legitimacy problem at all. It is a problem of building on top of a live operating asset that cannot be interrupted, against a deadline set by commercial commitments already made to third parties, with two adjacent access constraints deliberately specified at different thresholds — minimum disturbance to the precinct, nil disruption to the hotel.
Same scope grammar. Entirely different work.
What Leaders Commonly Misread
The first misreading is that the constraint list is a risk register. It is not. A risk is something that might happen. A constraint is a boundary condition that already applies. Treating "local resistance" as a risk to be mitigated is the error that produces two years of community engagement addressed to a problem the organisation has misdiagnosed; treating it as the binding constraint changes the project's entire design, because it means consent must be sequenced before commitment rather than managed alongside it.
The second misreading is that constraints are equally binding. They rarely are. Every constraint set contains one that will break first, and identifying it is the single most valuable analytical act available at initiation. On the convention centre, the operational continuity of the rail terminus is binding: it cannot be traded, it constrains the construction methodology absolutely, and every other constraint bends around it. On the water scheme, consent is binding, and technical difficulty is comparatively negotiable.
The third misreading is more subtle and more common. Constraints are frequently confused with assumptions, and the two demand opposite treatment. An assumption is something believed but unverified — it should be tested, and it may turn out to be wrong. A constraint is something that holds — it should be designed around, and testing it is usually a waste of effort. Registering constraints as assumptions produces a program that spends its early months trying to verify things that were never in doubt; registering assumptions as constraints produces a program that has quietly frozen a decision nobody actually made. The discipline of separating the two is treated in [Related article: What Must Be True: The Assumptions Register as a Strategy Instrument].
Reframing the Issue
The reframing is that the constraint set is the job description, and the deliverable list is not.
This has an immediate practical consequence for appointment. Asked what capability a delivery leader needs, most organisations answer from the deliverables — a water scheme needs someone with water experience, a convention centre needs someone from major construction. The answer is not wrong, but it is second order.
Read from the constraints, the first hypothetical needs a leader who can hold a negotiation with a hostile community over several years without either capitulating or hardening, who understands regulatory and environmental process well enough to sequence consent ahead of expenditure, and who can tell an executive team that the scheme is not viable if consent does not arrive. Water engineering is the entry ticket. The job is legitimacy.
The second needs a leader who can plan and stage complex physical work around an asset that cannot stop, who is comfortable with an immovable external deadline set by other people's contracts, and who can hold two adjacent stakeholders to two genuinely different service standards without letting the stricter one collapse into the looser. That is a different person, and a different temperament.
The question of how an organisation develops such people at all — and why the transition into these roles so often goes unsupported — is a separate matter, examined in [Related article: From Specialist to Delivery Leader: The Promotion That Is Actually a Career Change]. What is at issue here is narrower: how to read the work well enough to know which capability it requires.
Strategic Analysis
A working typology
Constraints fall into a small number of types, and the type determines the response.
Physical and operational — something exists and cannot be interrupted or moved. Response: design the methodology around it and treat it as fixed. Non-negotiable, but usually solvable with engineering and money.
Temporal — a date set outside the organisation's control, by contract, statute or commitment already made. Response: work backwards from it and identify what must be sacrificed. Almost never movable, and the most frequently underestimated.
Financial — a cap on what can be spent. Response: scope is the variable. Note that a financial constraint combined with a temporal constraint means quality or scope must move, and if neither is permitted to, the plan is not a plan.
Legitimacy and consent — someone whose agreement is required does not agree. Response: sequence consent before commitment. This is the type most often misclassified, because organisations prefer to treat it as a communications task.
Regulatory — a condition imposed by an authority. Response: treat as a dependency with a decision date and a named counterparty, not as a duration.
Ethical or welfare — a condition on how the work is done rather than what it produces. Response: it constrains method, and it usually conflicts with cost.
Most constraint sets contain three or four types. The binding one is rarely the type the organisation is most comfortable managing.
When the constraints conflict and nobody says which wins
A third hypothetical teaching scenario, more instructive than either of the first two. A zoo must relocate. The stated objectives: sell the existing site; be operating at the new location within eighteen months; generate a twenty million dollar profit. The stated scope: retain and reuse the existing staff; relocate all current exhibits, with animal welfare placed as the highest priority. The stated constraints: retain and reuse as much of the existing enclosures and exhibits as possible in order to minimise cost; and transport every creature with a zero-percent casualty rate, with long-term survival a critical success factor.
Read that set carefully and the conflicts are structural, not incidental. Reusing enclosures designed for a different site pulls directly against long-term animal survival. A profit target pulls against a zero-casualty standard, because the measures that eliminate transport casualties are expensive. An eighteen-month operating deadline pulls against both.
Exactly one priority is ranked: animal welfare is stated as highest. Everything else is left to collide — and here is the important part. Unranked conflict does not disappear. It is resolved silently, at working level, by whoever is standing in front of it. A procurement officer choosing between a cheaper transport option and a gentler one is making a strategic trade-off that the executive team declined to make, without the authority, the information or the accountability to make it.
The failure is not in the constraint set. It is in the delegation of an unranked constraint set, which delegates the strategy along with the work. Ranking the conflicts is the sponsoring office's work, and an organisation whose sponsor cannot perform it will export the decision downward by default — see [Related article: Sponsorship Is an Office, Not an Endorsement].
Why this reaches the boardroom
An executive who can read a constraint set can answer three questions that a deliverable list cannot: what will break first, what kind of leader this needs, and which trade-offs must be settled before the work is delegated. Those are governance decisions. They are also, in most organisations, made implicitly or not at all — which is why testing them explicitly, in the manner set out in [Related article: Enough Technical Depth to Test the Answer], repays the few minutes it takes.
Decision Framework
Five steps, applicable at initiation and repeatable at any major gate.
1. List the constraints separately from the deliverables and the risks. Physically separate documents or sections. The mixing is where the analysis is lost.
2. Type each one against the six categories above. The distribution is diagnostic on its own: a set dominated by legitimacy constraints is a different project from one dominated by physical constraints, whatever the scope says.
3. Identify the binding constraint by asking which one, if pressed, breaks first — and confirm it by asking what would have to change for it to stop binding. If nothing plausible would, it is genuinely binding and the initiative should be designed around it.
4. Rank the conflicts explicitly, in writing, before delegation. For every pair that cannot both be maximised, state which yields. This is uncomfortable and it is the entire point: the alternative is not the absence of a decision but an unrecorded one made further down.
5. Derive the capability requirement from the binding constraint, then select against it. Domain familiarity is an entry condition. The binding constraint tells you what the job actually is.
From Strategy to Execution
Immediate. For the initiative currently causing the most concern, run steps one to three. It takes under two hours and frequently reveals that the organisation has been managing a constraint that is not the binding one — deploying engineering effort against a legitimacy problem, or communications effort against a physical one.
Medium term. Require a typed and ranked constraint set as a condition of initiation approval, and require the appointment recommendation to reference the binding constraint. This is a small change to two standard artefacts and it improves selection more than any competency framework.
Long term. Build the habit of ranking conflicts at executive level. The instinct to leave trade-offs open — to preserve flexibility, to avoid an unpopular choice — feels like good management and is the mechanism by which strategy leaks downward into a hundred small decisions made by people who were never asked to make them.
Signals to Monitor
- Constraints written as aspirations. Language such as minimise, where possible or as far as practicable usually marks a constraint that has not been decided. On the convention centre, the difference between minimum disturbance and nil disruption is the difference between a preference and a boundary.
- Effort concentrated on the non-binding constraint. Compare where the program's hours are going against the binding constraint identified at initiation. A mismatch is common and expensive.
- Trade-off decisions appearing in operational forums. When choices between cost and quality, or speed and safety, are being settled in a working group, the executive ranking was not done.
- A constraint set unchanged since initiation. Constraints move as circumstances move. A static set means nobody is maintaining it.
- Appointment recommendations that cite domain experience only. If the case for a delivery leader does not reference what actually binds the work, the selection was made from the deliverable list.
Questions for the Leadership Team
- For our largest current initiative, what is the binding constraint — and would the delivery leader give the same answer we would?
- Which constraints in that set conflict, and have we stated in writing which one yields?
- Where are we deploying our strongest capability against a constraint that is not binding?
- Have we classified any legitimacy or consent problem as a communications task?
- When we last appointed a delivery leader, what in the recommendation referred to the constraints rather than the scope?
- What trade-offs are currently being made below this table that we have never explicitly delegated?
Closing Perspective
Scope tells you what you are buying. Constraints tell you what the work is.
Most organisations run their appraisal, their governance and their appointments off the first and are then surprised by the second — surprised that a technically straightforward scheme foundered on consent, that an unremarkable building programme was defeated by a railway that could not stop, that a relocation with a clear objective produced a hundred quiet compromises nobody sanctioned.
None of those outcomes required foresight. All of them were legible at initiation, in a document the organisation already had, in the section everyone skimmed on the way to the deliverables.
About the author
Kevin Jogin is Founder & Principal Advisor at EraNorth. Meet the Founder.