Draw the responsibility boundary.

Why scope boundaries fail under pressure

Most scopes look clear at the beginning because the project is still abstract. The boundary becomes difficult when information is incomplete, responsibilities overlap, conditions change, and urgent work moves faster than formal amendments.

A proposal may describe deliverables but not decision authority. A responsibility matrix may name an accountable party but not the assumptions supplied by others. A meeting may produce a practical direction without recording whether it changed the contract, design basis, schedule, or risk allocation. By the time an outcome is disputed, the neat original scope no longer describes how the project actually operated.

Scope is not a paragraph preserved at project start. It is a living chain of duties, dependencies, decisions, exclusions, and accepted handovers.

The objective is not to use scope as a shield after something goes wrong. The objective is to make interfaces visible while the work is happening so important decisions reach the person with the right authority and information.

Five tests for real responsibility

A title or signature may be relevant, but it is only one part of the analysis. Test responsibility through five separate questions.

1. Duty. What was the role engaged, appointed, contracted, or professionally required to do?
2. Authority. Which decisions could the role approve, reject, direct, escalate, or bind?
3. Knowledge. Which facts, warnings, requirements, and constraints were available or reasonably should have been obtained?
4. Reliance. Which information, specialist input, owner decision, field report, or third-party work was the role entitled, or required, to rely on?
5. Control. What could the role actually change, stop, inspect, verify, or enforce at the relevant time?

These tests prevent two opposite errors. The first is over-attribution: treating a person as responsible for every outcome because they were senior, visible, or copied. The second is under-attribution: claiming “outside scope” even though the role had authority, knowledge, and a duty to escalate a material interface risk.

A responsibility matrix needs evidence

RACI charts and similar matrices can be useful orientation tools, but a letter in a cell is not a complete responsibility record. “Accountable” means little unless the project can also produce the scope source, delegated authority, decision pathway, required inputs, exclusions, and acceptance evidence.

The matrix should be keyed to actual decision classes, not broad departments. “Engineering responsible” is weak. “Civil lead recommends stormwater basis; owner approves risk acceptance; architect controls interface geometry; contractor verifies field dimensions before installation” is more useful because it identifies decisions and dependencies.

Use verbs that reveal authority

Replace vague verbs such as support, coordinate, assist, oversee, or liaise with precise actions: design, supply, verify, review for stated purpose, approve, accept, instruct, install, witness, test, notify, or escalate. Then state the object and limit of the action.

Scope changes before the contract catches up

Operational scope often changes first through behaviour: an urgent request, an extra review, an informal instruction, a workaround, or a decision made “to keep things moving.” The commercial record may be updated days or weeks later. That gap is where responsibility becomes ambiguous.

Do not wait for a full amendment to record the operational change. A short interim notice can identify:

• the requested action and requesting authority;
• why it differs from the current scope or design basis;
• assumptions and information relied upon;
• affected interfaces, deliverables, schedule, cost, safety, and approvals;
• temporary limits and work that must not proceed;
• who must formalize the change and by when.

Repeated out-of-scope requests can reveal a real project gap. If the work is necessary and nobody owns it, continuously rejecting it does not manage the risk. The project needs an authorized assignment, an updated responsibility map, or a deliberate decision not to proceed.

Responsibility passes through accepted handover

Sending a file is not necessarily a handover. A defensible transfer records what was issued, revision and status, intended use, known limitations, open items, assumptions still requiring verification, decision authority, and the receiving party’s acceptance or response.

The handover should answer four questions:

1. What transferred? Identify the exact assets, records, work state, access, and operational knowledge.
2. What remained? Preserve unresolved issues, exclusions, temporary controls, and work still owned by the sender.
3. Who accepted? Record the receiving authority and any conditions attached to acceptance.
4. When did control change? Distinguish issue, receipt, review, acceptance, commissioning, and operational control.

Responsibility may pass in stages. A consultant may issue design intent; a contractor may assume means and methods; an owner may accept a commercial risk; an operator may assume ongoing control only after training and commissioning. The record should reflect those distinct transitions.

Language that protects clarity

A good responsibility boundary is not defensive language hidden in fine print. It is a practical operating system that helps the right person make the right decision before consequences compound.