Skip to content

Lesson 8 — Cross-Organisational and Jurisdictional Practice

At a glance

  • Track: Part VI — Advanced Practice (Lesson 8 of 8)
  • Level: Advanced
  • Estimated time: 105 minutes
  • Topics: Distributed software teams · Vendor and procurement considerations · Ethical project management · Project closure and organisational learning
  • Prerequisites: Module 12 Lessons 1–4, Lesson 1 — Governance and Decision Rights
  • Example project: the public service information system, from the example projects

Learning objectives

By the end of this lesson you should be able to:

  1. Explain how crossing an organisational boundary changes the project's problem, and why a contract cannot replace trust.
  2. Compare fixed-price, time-and-materials, and outcome-based arrangements by the behaviour each one encourages, and describe what the risk transfer in each one actually transfers.
  3. Set up cross-organisational delivery so that interfaces, acceptance, evidence, and escalation are owned rather than assumed — including in a multi-vendor arrangement.
  4. Design a distributed working agreement, and quantify what distance costs before committing to it.
  5. Identify the ethical questions that arise across jurisdictions, and say what a project manager can and cannot determine without qualified advice.
  6. Close a project or programme in a way that transfers ownership, measures benefits later, and changes organisational practice rather than only producing a document.

Prerequisites

  • Module 12 Lessons 1–4: procurement, documentation and closure, distributed teams, and ethics. This lesson assumes that material and concentrates on the parts that only appear when more than one organisation, or more than one legal system, is involved.
  • Lesson 1, because cross-organisational work is where governance is most often vague and most costly.

Introduction

Everything in the core course assumes you can decide. You can ask for a person, change an environment, choose a design, or stop work — inefficiently perhaps, but within one authority structure. Crossing an organisational boundary removes that assumption, and it removes it in a specific way: the other party's incentives are not yours, and you cannot fix that with a meeting.

This lesson covers the four advanced topics that all sit on that boundary — supplier relationships, distributed delivery, ethical obligations across jurisdictions, and closure at the end of a programme. What they share is that the project manager's authority is partial, and the professional skill is in making the arrangement work anyway: writing interfaces, agreeing evidence, quantifying distance, and recording decisions so that obligations are visible.

1. What changes when you cross a boundary

Inside one organisation Across organisations
Authority is delegated; escalation is internal and cheap Authority stops at the contract; escalation means a commercial conversation
Shared assumptions about standards and quality Assumptions are unstated and often different
Information is available to whoever needs it Information is negotiated; some of it is contractual
Problems are solved by prioritising them Problems may be a change under the contract, with a price
Trust is the default and the fallback Trust must be built, and the fallback is the contract

That last row is the important one. In a commercial relationship, trustworthy behaviour and contractual behaviour are different things, and both need to work. A supplier who is pleasant and misses dates is not helped by goodwill, and one who is competent and treated as an adversary will price the relationship accordingly. The project manager's job is to run the relationship so that the contract's protections are rarely needed and always available.

2. Contract shape determines behaviour

Contract types are usually described as ways of allocating risk. It is more useful to ask what behaviour each one rewards:

Arrangement Who carries the cost of overrun Behaviour it encourages The illusion it creates
Fixed price Supplier Protecting margin: minimal scope interpretation, formal change requests, defensive documentation That the buyer's risk has gone. Cost risk is transferred; delivery and quality risk is not, and the supplier now has an incentive to define "done" narrowly
Time and materials Buyer More work, honestly reported — but no incentive to finish That the buyer is in control. They carry all the cost risk, and the supplier has no reason to reduce effort
Outcome or performance-based Shared, by design Delivering the outcome, because payment depends on it That the outcome is measurable. Where it is not, disputes move from cost to definition
Capped time and materials Shared to the ceiling Working efficiently up to the cap, with a real conversation at it That the cap is not the finish line. It usually becomes a decision point rather than a limit

Two practical consequences follow. First, the change control regime is part of the commercial deal, not an add-on: with a fixed price, changes are the supplier's revenue, so the buyer needs an internal change process capable of saying no. Second, acceptance criteria are the interface. Where they are vague, the disagreement is not about quality; it is about what was bought, and it will be resolved by whoever has more commercial leverage. Writing testable acceptance criteria before signature is the single highest-value thing a project manager does in a procurement.

3. Making cross-organisational delivery work

Mechanism What it means in practice
Named interface owners One person per side for each interface, with authority to decide within a limit — the cross-organisation version of Lesson 1's decision rights
Written acceptance criteria and evidence What will be delivered, how it will be tested, and what proves it passed
Evidence rights Agreed access to test results, build records, defect data — and, where relevant, audit rights and source-code or exit provisions
A joint change process Who assesses, who decides, timescales on both sides, and the escalation route when the answer is no
A delivery cadence that both sides attend Demonstrations at a fixed rhythm, so problems surface while they are cheap
Multi-vendor interface register With several suppliers, each interface has one owner and one documented version; unowned interfaces are where multi-vendor programmes fail
Exit and transition provisions What happens at the end or on termination: knowledge transfer, licence continuity, data return, and who supports what during transition

Multi-vendor arrangements deserve specific warning. The commonest failure is not poor performance by any one supplier; it is an interface between two suppliers that nobody owns. Each supplier is contractually compliant, each blames the other, and the buyer discovers the problem at integration. The buyer's responsibility is to own the interfaces across suppliers, including their versions and their change routes — nobody else's incentives require it.

4. Distributed delivery: design it, then quantify it

Module 12 Lesson 3 covers the practice of distributed teams. Two things matter more when the distance crosses company boundaries as well:

Asynchronous work needs written artefacts. When overlapping hours are few, decisions must be recoverable from written records — which makes documentation a product rather than an overhead. A team that communicates only in meetings is a team that loses four hours a day across a time-zone boundary.

A working agreement replaces ambient information. Explicit rules about response times, decision ownership, meeting hours, escalation, and where artefacts live are what allow people who never meet to work as one team. Writing the agreement is not bureaucracy; it is the substitute for the corridor conversation that does not exist.

Then quantify what distance costs, before committing to it, in the same spirit as Lab 24:

Cost How to estimate it
Overlap shortfall Hours of shared working time lost per person per week, converted to delayed feedback
Handoff latency Elapsed time added per handoff, multiplied by handoffs in the plan
Travel and induction Cost and days per trip, plus ramp-up time for people who join remotely
Rework from misread requirements Estimate as a probability against the affected work packages, and say it is an estimate
Coordination roles The capacity consumed by the people whose job becomes keeping the arrangement working

The output of that table is a decision, not a verdict. Distributed delivery can be the right answer — for cost, for capability, for resilience, for following the sun on long-running work — and it is never free.

5. Ethics across jurisdictions

Module 12 Lesson 4 covers the professional obligations. Across jurisdictions, three questions change character, and one rule governs all of them:

The governing rule

This course cannot tell you what is lawful or required in your jurisdiction. Data-protection law, employment obligations, anti-corruption rules, and professional regulation differ by country, by region, and over time. Establish requirements from a qualified source — your organisation's legal or compliance function, or a professional adviser — and record the basis of the advice you relied on. A confident summary of another country's law written by a project manager is a risk, not a document.

The three questions:

  1. Whose data, and under whose rules? Personal data handling depends on where the individual is, where the processing happens, and where the data rests — and several jurisdictions assert requirements over processing connected with their residents. The project's job is to map the flows precisely, ask the qualified question early, and treat "we always do it this way" as unanswered.
  2. Whose labour practices are you relying on? Where delivery depends on suppliers or subcontractors, the buyer's exposure to labour conditions in the supply chain is a real and increasingly regulated concern. The practical step available to a project is transparency: knowing the delivery chain, asking for the supplier's policies, and recording what was asked and answered.
  3. What is expected of you as a professional, not just as an employee? Conflicts of interest, gifts and hospitality, facilitation payments, and pressure to misrepresent status are the recurring cases. The ACM/IEEE-CS Software Engineering Code of Ethics and Professional Practice (1999, published jointly by the ACM and the IEEE Computer Society) is a verifiable reference that speaks to honesty about status and capability, professional competence, and the public interest — and it is written as obligations on the individual, which is precisely why it is useful when the pressure is organisational.

Practical questions worth answering before they arise: who in your organisation can advise on ethics or compliance, and is that route independent of your reporting line? Where would you record a concern? What did you agree to in the contract about reporting accuracy and disclosure? A project that has answers to those can act in days; one that does not will act in months, or not at all.

6. Closing a programme, and making learning stick

Closure at programme level has three parts that a single project closure does not.

Handover is a gate with evidence, not an announcement. Operations or the receiving team accepts each component, with the support arrangement, documentation, access, and warranty obligations confirmed and named. A handover to "operations" without a person who accepted it is not a handover, and the first incident will establish who actually owns it — usually by argument.

Benefits are measured later, by someone who is not the project. Name the benefit owner at approval, with the measure, the baseline (or an explicit note that none exists yet), and the review date. A post-implementation review scheduled after closure, on the benefit owner's calendar, is the difference between benefits realisation and an aspiration.

Organisational learning requires a change to a standard, not a document. A lesson that changes nothing outside the project has not been learned. The mechanism that works is to route it into the artefact the next project will use: an estimating basis in the template, a definition-of-ready criterion, an environment standard, an onboarding checklist. Two additional habits reduce the loss of knowledge as people move on: record why decisions were taken (the decision log), and identify which knowledge exists only in one person's head and would take a successor weeks to reconstruct.

Key terms

Term Meaning
Fixed-price contract An arrangement where the supplier carries cost overrun, with a matching incentive to narrow scope
Time and materials Work paid by effort, where the buyer carries cost overrun
Outcome-based contract Payment tied to a measured outcome rather than to effort or deliverables
Evidence right Contractually agreed access to test results, records, or audits
Interface owner The person accountable for a boundary between components, teams, or suppliers
Exit provision The agreed arrangements for transition out of a contract
Working agreement The explicit rules that substitute for shared context in distributed teams
Handoff latency Elapsed time added by transferring work between people, sites, or suppliers
Benefit owner The named person accountable for a benefit being realised and measured after closure
Post-implementation review A scheduled assessment of outcomes and benefits after closure

Worked example

Task: set up a contracted delivery of the public service information system, with one supplier building the service and another hosting it, over two jurisdictions. Figures are invented for teaching.

Step 1 — Decide what is being bought before choosing a contract type. The requirements are initially unclear — the content model will emerge as the editorial team works with real services — so the recommendations section of the business case states this explicitly. A pure fixed-price arrangement on unclear requirements produces either a narrow interpretation of "done" or a stream of change requests. The arrangement chosen is capped time and materials for a discovery-and-pilot phase, then fixed price for the remaining defined work, with the pilot's acceptance criteria written before signature.

Step 2 — Treat acceptance criteria as the interface. For each deliverable the arrangement specifies what will be tested, on what data, and what evidence will be produced. Two criteria that would otherwise be argued at the end are made testable in advance: "the service information page meets the published accessibility conformance level, verified by the named test method" and "the content update process is executed by an editor who has not previously seen the system, unaided". The second is deliberately written as an observation by a third party, because usability arguments are otherwise unwinnable.

Step 3 — Assign interface owners across the two suppliers. The service-to-hosting interface gets one named owner on each side, a documented version, and a change route with a two-day response expectation. The register lists every interface with a single owner — including the ones between the two suppliers, which the buyer owns, because no supplier's incentives require them to own it. The escalation route is written on both sides: technical disagreement to the two leads within two days, commercial disagreement to the buyer's delivery manager and the suppliers' account managers within five.

Step 4 — Quantify what distance will cost, and design for it. Three sites, two time zones with four hours of overlap. The estimate: four hours of lost feedback per person per week, five handoffs adding a day each, and two coordination roles consuming half a person between them. Converting the feedback loss at the project's own day rate gives a cost figure that is put beside the arrangement's commercial saving, so the decision is made with both numbers visible. The design response follows from the figures: decisions are recorded in writing, demonstrations happen in the shared hours, and the working agreement names response times (one working day for a question, two for a decision).

Step 5 — Establish the compliance position from qualified advice, not assumption. The data flows are mapped: which information about which people crosses which border, and where it rests. The organisation's data-protection adviser confirms the applicable requirements in writing, and the answer — including any restrictions on where the data may be processed — is recorded in the requirements list as a constraint with a source. Note what is not in the project's own analysis: any assertion about which law applies. The project establishes the question precisely and records the qualified answer.

Step 6 — Record the professional obligations in advance. Two questions are put to the supplier before signature: how they report progress when it is unwelcome, and who in their organisation owns accuracy of status reporting. The buyer's own answer is written down as well — variance is reported to the sponsor within 24 hours of being known. The contract's change and status clauses are then checked against those answers so that the contractual position and the intended behaviour agree; where they disagree, the contract wins in a dispute, which is why they must agree.

Step 7 — Plan closure and the transfer of ownership at the start, not the end. The acceptance criteria, handover evidence, support arrangement, and exit provisions are agreed before work begins: what happens to the content model and the data if the contract ends, who supports the service during transition, and how the first ninety days of live support are funded. The benefit owner is named in the business case — the service director — with the review date twelve months after go-live and the explicit note that no baseline exists for complaint-handling time, so establishing one is part of the work rather than an assumption.

Common misconceptions

“A fixed-price contract transfers the risk”

It transfers the cost risk. Delivery risk remains with the project — the date, the quality, and the integration are still the buyer's problem — and the supplier now has an incentive to interpret the requirement narrowly and to treat every clarification as a change. Risk that is transferred at the price of rigidity is not necessarily risk reduced.

“The supplier is responsible for that interface”

In a multi-vendor programme, every supplier is responsible for their own side, which means the interface between them is owned by nobody unless the buyer owns it. Interfaces need one accountable owner, a version, and a change route — and that accountability has to sit with whoever has something to lose if it fails, which is usually the buyer.

“We can settle the data-protection question ourselves”

A project manager can — and should — map the data flows precisely, ask the qualified question early, and record the answer. Asserting which jurisdiction's rules apply, or summarising them from memory, is a different activity with a much worse failure mode. The honest deliverable is a precise question and a recorded qualified answer.

“Lessons learned are a closure document”

A lessons document changes nothing. A lesson changes something only when it is routed into the artefact the next project will use — a template, a checklist, a definition of ready, an estimating basis — with an owner and a confirmation that it landed. Anything else is an archive.

Practical activity

Design one cross-boundary arrangement, end to end.

  1. Choose a project that involves an external supplier or a distributed team. State, in one sentence, what decisions you cannot make because of the boundary.
  2. Write the two or three acceptance criteria that will matter most, in observable terms, naming who tests and what evidence counts.
  3. List every interface across the boundary — technical, procedural, or human — and name a single owner for each. Mark any interface that no party's incentives require them to own.
  4. Quantify what distance costs, using the table in section 4, and compare it with the arrangement's stated benefit. State whether the comparison changes your recommendation.
  5. Write the two compliance questions you would put to a qualified adviser for this project — precisely enough that the answer can be recorded as a constraint with a source.
  6. Plan closure now: acceptance, handover evidence, benefit owner, measure, review date, and what happens on early termination.

What "good" looks like: acceptance criteria a third party could test, an interface register with one owner per line and at least one interface explicitly owned by the buyer, distance costs estimated rather than assumed, a compliance question rather than a compliance assertion, and a closure plan written before delivery rather than after.

Self-assessment

  1. Why can a contract not replace trust in a supplier relationship, and what should the contract do instead?
  2. What does a fixed-price contract transfer, and what does it leave with the buyer?
  3. In a multi-vendor programme, who should own the interface between two suppliers, and why?
  4. What are two consequences of a large overlap shortfall in a distributed team, and how would you identify them before committing?
  5. What is the professional response when asked to report progress in a way you believe is misleading?

  6. What makes a lesson actually learned rather than merely recorded?

  7. Apply it — cross-organisational delivery. A ministry contracts a supplier to build a public service portal. The contract is fixed-price with a detailed specification. Six months in, a policy change requires a different eligibility rule, the supplier prices the change at a level the ministry considers extortionate, and delivery slows whenever the two sides disagree.

    Hint: A strong answer explains the behaviour the contract is producing and what to do about the relationship.

Show answers
  1. Because contracts specify consequences, not cooperation: they cannot tell you what to do when an unforeseen problem appears, and they are expensive to invoke. The contract's role is to make the fallback position explicit and credible — acceptance criteria, evidence rights, change process, exit terms — so that trust is the working method and the contract the safety net. Relying on trust alone leaves you with no recourse; relying on the contract alone guarantees disputes.
  2. It transfers cost risk — the supplier absorbs overrun — while leaving the buyer with delivery risk (dates, integration, quality, and operational readiness), and it creates an incentive for the supplier to interpret scope narrowly and to price clarifications as changes. The buyer's exposure does not disappear; it changes form.
  3. The buyer, because neither supplier's incentives require it: each is contractually responsible for its own side, so the boundary itself is unowned. Assigning it to one supplier sets up a conflict of interest over the other supplier's obligations, so the buyer names an owner, versions the interface, and runs its change route.
  4. Delayed feedback, which lets misunderstandings persist until an integration or demonstration exposes them, and reduced hours for joint problem-solving, which shifts work toward written exchange and slows decision-making. Identify them by estimating the overlap hours, the handoffs and their latency, and the coordination capacity required — before committing, and against the arrangement's stated benefit.
  5. Report what you believe is accurate, in writing, to the person accountable for the decision, and record both the request and your assessment. The professional obligations of honesty and public interest are on the individual, not on the role, and a project manager's value in that moment is precisely the accurate picture. Use whatever internal route exists — quality, compliance, audit, or an independent advice line — and if the accuracy of reporting is itself the issue, that is a matter to escalate rather than to accommodate.
  6. A change to something the next project will actually use, with an owner, and a confirmation that the change was made. Lessons recorded in a project document disappear when the project does; lessons routed into templates, checklists, definitions of ready, or estimating bases change behaviour after the people who learned them have moved on.
  7. The contract is producing exactly the behaviour it rewards: under a fixed price against a detailed specification, the supplier's margin comes from excluding everything not written down and from pricing every change as a variation — so a policy change becomes a negotiation and delivery slows while it is contested. The immediate problem is not the price, it is that authority and trust sit in different organisations, so the contract must handle what the contract cannot: agree a change mechanism with pre-agreed rates and a fast decision route rather than pricing each change from scratch; get visibility of progress through milestones and working demonstrations so disputes are about evidence rather than positions; and keep a named counterpart on each side who can decide. Longer term, the arrangement for work of this kind is outcome-based or time-and-materials with a ceiling rather than fixed-price against a specification that policy can invalidate, because the specification was never the stable thing. Note the jurisdiction question too: if the policy change touches data location or retention, that is a compliance obligation on the ministry, not a variation to be bargained over.

Summary

  • Crossing an organisational boundary removes your authority and your assumptions. Contracts specify consequences; trust is the working method and the contract is the fallback.
  • Contract shape drives behaviour: fixed price encourages narrow scope and priced changes, time and materials leaves cost risk with the buyer, and outcome-based payment depends on a measurable outcome. Acceptance criteria are the interface — write them before signature.
  • Cross-boundary delivery needs named interface owners, evidence rights, a joint change process, a shared cadence, and exit provisions. In multi-vendor work, the interfaces between suppliers are the buyer's to own, because no supplier's incentives require it.
  • Distributed delivery must be designed — written artefacts, a working agreement, response times — and quantified, including overlap shortfall, handoff latency, travel, rework risk, and coordination roles.
  • Ethical obligations across jurisdictions require qualified advice: map the flows, ask the precise question, and record the answer. Professional obligations on individuals — honesty, competence, public interest — are the reference point when organisational pressure points the other way.
  • Programme closure entails handover as a gate with named acceptance, benefits measured later by their owner, and lessons routed into the artefacts the next project will use. Nothing else counts as learning.

Further learning

Verifiable references for the obligations discussed above: the ACM/IEEE-CS Software Engineering Code of Ethics and Professional Practice (1999), published jointly by the ACM and the IEEE Computer Society; and ISO 31000 for the organisational-level treatment of risk mentioned in the prerequisites. For jurisdiction-specific legal questions — data protection, employment, anti-corruption — this course deliberately provides no summary: obtain qualified advice and record what you relied on.