6.3 Features of Different Contractual Relationships
Key Takeaways
- The contractual relationship decides who is responsible for what; the reimbursement method then decides who carries the cost consequence.
- Design ownership is the pivotal question: a client that specifies the solution in detail keeps design risk, while design-and-build transfers it along with control of the outcome.
- Using many specialist packages gives the client price transparency and control but leaves the client owning the interfaces between them.
- No relationship type is inherently best — the right choice puts each risk with the party best able to manage it.
- Obligations such as payment terms, ethical standards, and quality requirements only reach sub-contractors if they are flowed down through the first-tier contract.
Outcome 5c has two halves. The first is to know the features of different contractual relationships; the second, covered in the next section, is to understand supplier reimbursement methods. This section takes the relationship itself — who is contracted to whom, who owns design, and who manages the interfaces between packages.
Contractual relationships on the PMQ
Learning outcome coverage for procurement includes features of different contractual relationships and supplier reimbursement methods, with judgement on when each is appropriate. Relationship design and payment mechanism work together: the same technical scope can produce very different behaviour under a one-off fixed-price order versus a multi-year framework with shared targets.
A contract creates enforceable rights and obligations. A contractual relationship is the pattern of interaction, trust, information sharing, and commercial stance that develops around those terms. Project managers influence relationship quality through specification clarity, fair change control, prompt payment, and joint problem-solving — not only through legal clauses.
Features of different contractual relationships
Think of relationship types as a spectrum. Labels vary by sector; PMQ answers should describe features and fit, not argue for one branded model.
| Relationship style | Typical features | Best fit | Watch-outs |
|---|---|---|---|
| Transactional / adversarial lean | Discrete purchase; detailed specification; price-focused competition; limited collaboration beyond delivery | Clear, simple, well-specified goods or services; one-off buy | Claims culture if scope was ambiguous; little incentive to innovate |
| Collaborative / partnering | Shared objectives, open information, joint risk workshops, early warning of problems, continuous improvement | Complex, uncertain, or long-duration work needing joint problem-solving | Needs cultural commitment; weak if one party still acts purely transactionally |
| Framework / call-off | Pre-competed terms and suppliers; call-offs for packages over a period | Multiple similar packages over time; speed of award; consistent standards | Mini-competitions still need fairness; capacity may be constrained at peaks |
| Prime contractor / integrated supply | Single point of responsibility coordinating many subcontractors | Buyer wants one accountable interface for complex delivery | Prime markup and interface risk; ensure flow-down of critical obligations |
Transactional relationships
Transactional relationships treat each purchase as a largely self-contained exchange: specify, bid, deliver, pay, close. They suit catalogue products, routine maintenance tasks with clear standards, or one-off specialist inputs that are easy to define. Management overhead is lower when specifications are solid. They fail when uncertainty is high and parties need ongoing joint design — rigid terms then generate variations and conflict.
Partnering and collaborative relationships
Partnering (and related collaborative models) emphasise mutual objectives, early involvement of suppliers in design or planning, transparent cost and risk data where agreed, and processes for resolving issues before they become disputes. They are appropriate when interfaces are complex, innovation is needed, or long programmes make "win-lose" behaviour destructive. Partnering does not remove the need for a contract, clear scope boundaries, or change control; it changes how parties work within commercial rules.
Framework arrangements
A framework pre-establishes terms with one or more suppliers so individual call-offs can be awarded faster for defined categories of work. Frameworks suit programmes with many similar packages (for example regional site works, IT professional services days, or facilities projects). They improve speed and consistency but still require package-level definition, capacity checks, and compliant mini-competition or direct award rules as applicable.
Relationship choice scenario
A university is building a research facility. Structural steel packages are standard and well specified — a transactional competitive fixed-price route may be efficient. The experimental fit-out is novel and will evolve with researchers — a collaborative relationship with early supplier design input and a reimbursement method that handles uncertainty (for example target cost or carefully controlled cost-plus for defined design stages) is more appropriate than a rigid low-bid fixed price on incomplete drawings.
Choosing the relationship before choosing the price mechanism
Candidates often jump straight to fixed price versus cost plus. The syllabus puts the relationship first for a reason: the relationship decides who is responsible for what, and the reimbursement method then decides who carries the cost consequence. Get them in that order in a written answer.
Three questions settle the relationship in a scenario:
- Who owns the design? If the client specifies the solution in detail, the client keeps design risk and the supplier is executing someone else's design. If the supplier designs and builds, design risk transfers with it — but so does control over the outcome.
- How many interfaces is the client willing to manage? Many specialist contracts give the client control and price transparency but leave the client integrating between them, and carrying the risk when two packages do not meet. A single main contractor absorbs those interfaces at a price.
- How much does the client need to change its mind later? Highly defined, arm's-length arrangements punish change. Collaborative and framework arrangements are built to absorb it.
Where relationships fail
| Relationship pattern | Typical failure mode | Early warning sign in a scenario |
|---|---|---|
| Client-designed, supplier-built | Client's design is incomplete; every gap becomes a claim | Rising volume of requests for information and variations |
| Design-and-build | Supplier optimises for its own cost, not the client's operating cost | Whole-life cost queries answered vaguely at tender |
| Multiple specialist packages | Nobody owns the interfaces between packages | Two suppliers each say the other is responsible |
| Framework / call-off | Convenience erodes competitive tension over time | No benchmarking of call-off prices against the market |
| Partnering / collaborative | Good relations substitute for records; no evidence when it goes wrong | Decisions agreed verbally, contract never varied |
The examinable judgement is that no relationship type is inherently best. The right answer names the project's dominant uncertainty and constraint — design maturity, need for price certainty, interface complexity, likely change — and selects the relationship that puts each risk with the party best able to manage it.
Relationships in the supply chain, not just the first tier
Finally, remember that the client's contract is with the main supplier, but delivery usually depends on sub-contractors the client has no contract with. Payment terms, ethical standards, and quality requirements only reach those tiers if they are flowed down through the main contract. A scenario describing modern slavery risk, late payment of small sub-contractors, or a critical sub-supplier failing is testing whether you understand that the first-tier contract has to carry those obligations downward.
A client lets five separate specialist packages directly rather than appointing a single main contractor. Two packages later dispute which of them is responsible for a failed interface. Who carries that risk?
A main contractor is appointed under terms requiring 30-day payment, but its small sub-contractors report being paid after 90 days. What does this most clearly indicate about the contract?