Everyone can be working on the same project while only some parties can enforce the same promises.
The Week 3 material introduces the doctrine of privity and then explores agency, trusts, collateral contracts and third-party relationships. Its traditional construction diagram makes the problem clear: the client contracts with the main contractor, while the main contractor separately contracts with subcontractors.
Operationally this appears to be one delivery system. Contractually it is a network.
The Strategic Context
Complex projects rarely consist of a single bilateral contract.
A major program may include a client, head contractor, designers, subcontractors, specialist suppliers, financiers, operators, future owners and maintenance providers.
Each party may depend on the performance of others while lacking a direct contractual right against them.
The Week 3 material explains the traditional privity rule as limiting contractual enforcement to parties to the contract, subject to recognised exceptions and statutory reforms in some jurisdictions.
Current Australian third-party-rights law varies and requires jurisdiction-specific verification. [FACT CHECK REQUIRED]
What Leaders Commonly Misread
The first mistake is confusing operational dependency with contractual enforceability.
The second is assuming the client can directly instruct every subcontractor because they all work on the same project.
The third is believing a main contract automatically gives downstream parties rights.
The fourth is treating third-party rights as a legal technicality rather than part of delivery architecture.
The fifth is assuming that because a party benefits from a contract it necessarily has a direct right to enforce it. The Week 3 materials specifically use privity to show why benefit and enforceability have historically been different questions.
Reframing the Issue
A project should be mapped as a network of enforceable relationships.
For every critical obligation, ask:
- Who owes the obligation?
- To whom?
- Who depends on its performance?
- Who can enforce it?
- What happens if the obligated party disappears?
- Does another party need direct rights?
This creates a contractual interface map alongside the technical and schedule interface maps.
Strategic Analysis: The Accountability Gap
The Week 3 material describes traditional construction relationships where the main contractor remains responsible to the building client, while subcontractors are separately responsible to the main contractor.
This structure can work well because the client deals with a single accountable head contractor.
But it also creates vulnerability where a specialist designer's work is critical to a future owner, an operator needs ongoing rights after completion, the head contractor becomes insolvent, a manufacturer made specific assurances relied upon by the client, or warranties need to survive changes in ownership.
The source introduces collateral contracts as one method of creating an additional relationship alongside the main contract. It uses a construction example and the Shanklin Pier scenario to show how a separate promise may support a direct claim.
For executives, the lesson is that rights sometimes need to be deliberately extended across the project network.
The source also identifies agency and trusts as situations that can affect the traditional privity position. Those concepts are not developed deeply enough in the Week 3 materials to justify standalone articles, but they reinforce the broader principle that enforcement depends on legal structure, not just project organisation charts.
Decision Framework
For each critical interface, assess:
Dependency
Who suffers if the obligation fails?
Direct relationship
Does that party have contractual rights against the performer?
Intermediary strength
Is the head contractor or intermediary financially and operationally capable of carrying the risk?
Continuity
Will rights still be needed after completion, ownership transfer or insolvency?
Mechanism
Should the architecture use collateral warranties, direct agreements, third-party rights, assignment, novation or another mechanism? [FACT CHECK REQUIRED]
The correct legal mechanism depends on jurisdiction and contract type.
From Strategy to Execution
Immediate action: create a contractual relationship map for every major program.
Medium-term capability: integrate this map into design, procurement and handover. Critical warranties should not be discovered late in the project.
Long-term strategic positioning: treat contractual architecture as part of program architecture. Technical dependencies, information flows and enforcement rights should be designed together.
The map should be reviewed whenever packages are novated, subcontractors change, asset ownership transfers or the operating entity becomes different from the procuring entity.
Designing Rights for the Future Operating Model
Third-party rights are particularly important where the organisation that procures an asset is not the organisation that will ultimately own or operate it.
Major programs often transition through stages. A project entity may procure the asset, an operating business may later take control, and a different maintenance provider may support it. If rights are designed only for the original contracting structure, the future operator can inherit obligations without equivalent enforcement rights.
Hypothetical example: A project company engages a designer through a head contractor. After completion, the asset is transferred to an operating entity. A design defect appears several years later. If the operating entity lacks a direct contractual pathway, recovery may depend on the continuing existence and solvency of the original intermediary.
The correct structure depends on law and contract, but the governance insight is clear: contractual rights should be designed against the future-state ownership model, not only the delivery-stage organisation chart.
Contractual Interface Mapping
A useful program artefact is a matrix listing:
- critical deliverable or warranty;
- party performing it;
- party relying on it;
- direct contractual relationship;
- intended duration of the right;
- transfer or collateral mechanism required;
- insolvency or change-of-control contingency.
This can be reviewed alongside the technical interface register.
The benefit is strategic visibility. Program leadership can see where value depends on an intermediary and decide whether that dependency is acceptable.
Signals to Monitor
Watch for clients directly instructing subcontractors without contractual clarity, future operators lacking warranties from critical designers or OEMs, reliance on a financially weak intermediary, projects with many specialist interfaces but no direct-rights strategy, and handover teams discovering that warranties cannot easily be enforced by the eventual asset owner.
Questions for the Leadership Team
- Who can enforce each critical obligation in our current program?
- Where are we operationally dependent on parties with whom we have no direct contract?
- Which rights must survive completion, ownership transfer or contractor insolvency?
- Are collateral warranties or equivalent mechanisms identified early enough?
- Does our contractual structure match the technical dependency structure?
- Which single intermediary represents a concentration of enforcement risk?
Closing Perspective
Complex delivery creates networks, not chains.
Strong program governance therefore requires more than knowing who reports to whom. Leaders must know who owes what to whom, who can enforce it, and whether those rights survive when the structure changes.
Related article: Assignment, Novation or Subcontracting? Choosing the Right Structure When Responsibility Moves
Related article: Contract Management Is More Than Contract Administration
About EraNorth Insights
EraNorth Insights publishes practical analysis on strategy, projects, operations, transformation and decision intelligence for professional and organisational use. About EraNorth.