The chart shows reporting, not access.

Every name is an office

Last week ended on this. The execution plan says an approval sits with the project manager, information comes from the client's planning team, a submission goes to the Engineer. Each of those is a role, and behind each role is a person whose latitude you don't yet know.

The standard forms are unusually explicit about it, and the mechanism repays reading once. The Engineer may appoint a Representative and delegate the authority to act on the Engineer's behalf at site. The Engineer may also assign duties and delegate authority to assistants, and may revoke either — and the assignment or revocation doesn't take effect until both parties have received notice of it.

So the authority of the person in front of you is a documented fact, and the document is a notice that should be in your possession. Reading it is a choice, and so is leaving it unread.

Two things nobody on site can decide

The same clause draws a line that is worth knowing before you spend three months on the wrong side of it.

Certain authority can't be delegated at all. Making an agreement or determination — the mechanism by which claims and disputed entitlements are actually resolved — stays with the Engineer. So does issuing a notice to correct. And the Engineer has no authority to amend the contract.

Read that as an operational fact rather than a legal one. The person you deal with every day, whose judgement you trust and whose word is good, is structurally incapable of deciding the things that matter most to you. This is a limit on the office rather than a reluctance in the person, and treating it as a relationship problem wastes months. Pressing harder on the person at site can't produce the outcome, because the outcome isn't theirs to produce.

Responsible without access

The other half of the week comes from a planning engineer's account of a nuclear construction project, and it is the failure that turns up first on a new job.

He was expected to perform project control. He could not reach some of the systems that project control is fed from, the planning tool among them. So the output was his responsibility and several of the inputs sat behind somebody else's access.

Put plainly: he was accountable for a number he wasn't permitted to look up.

Withholding has nothing to do with it. Access sits with whoever administers a system, and administering a system is a different job from delivering a project, done by different people to different priorities. The two are connected by a request that has no place in any programme and no deadline attached to it.

And the request competes badly. To the administrator it is one item among many, from somebody they don't report to, with no date on it and no consequence attached to being late. Every property that would move it up a queue is absent.

What it produces is the same each time. Instead of using the system, you assemble the equivalent information from whatever is reachable — spreadsheets, daily reports, and asking people. It works. It works only as long as the person doing the assembling is there.

Deciding and releasing are different authorities

These two failures look different and have the same shape, which is why they belong in one week.

Somebody can agree that you should have a thing and still be unable to give it to you. A client planning manager can genuinely want you to have the file and lack the right to send it outside their organisation. An engineer at site can agree your entitlement is sound and have no power to determine it.

Agreement is cheap and it feels like progress, which is what makes this expensive. A meeting ends with everybody nodding, the thing doesn't move, and the natural reading is that somebody is being difficult. The accurate reading is that the person who nodded was never the person who could act, and may not have realised it either. Interfaces Week 8 follows this across organisational boundaries, where it compounds. Inside one project it is already enough to lose a month.

The waiting that no programme shows

An activity exists for pouring concrete. None exists for obtaining a login, a folder permission, or a monthly extract nobody has been asked to produce before.

So the time spent waiting for access is real, is measured in weeks rather than hours, and appears in no document.

It shows up instead as the report being late, which is attributed to the person who produced it late.

That mis-attribution is worth naming because it is correctable at almost no cost. A request with a date on it, recorded, converts an invisible dependency into a visible one, and it does so before anybody needs to argue about who caused what.

It also changes what the delay is about. Without the record, the conversation is about a person's performance. With it, the conversation is about a queue, which is a thing an organisation can act on.

System design

Row four is the row this week exists for, and its required quality is the whole argument compressed: holder and authoriser recorded separately, because they are different people in different organisations, and a register that assumes otherwise stops working on the first row where they differ.

Record	Produced by	Required quality	Verified against	Feeds
Organisation chart	The project, at start-up	Marked with what each box may decide, not only who it reports to	The delegations actually notified	Who to approach for what
Notice of delegated authority	The Engineer, to both parties	Held by you, with its date, and re-checked when people change	The contract clause permitting it	Whose instruction is an instruction
Named individual per office	You, by asking	A person against every role your work depends on	The chart and the notice	Every request that has to reach somebody
Access register	You, in the first fortnight	Holder and authoriser recorded separately, because they differ	The answer from the authoriser	Whether you can produce anything
Dated access request	You, each time	Recorded when made, not reconstructed when late	The register it belongs to	Attribution when a report is late

Row two is the one nobody asks for and everybody is entitled to. A delegation notice is issued to both parties, so it is already yours; not holding it means not knowing whose instruction is an instruction.

Practical insight

Build an access register in your first fortnight. It is one table and it is the most useful page you will produce in this phase.

One row per system or data source you need — the planning tool, the document management system, the cost ledger, the site daily reports, the survey records, the delivery notes. Five columns: what it is, who holds it, who authorises access to it, whether you have it, and the date it was asked for.

The value is in the third column, and filling it in requires asking. Expect the answer to name somebody in a different organisation from the person who holds the system, because that split is the normal case rather than a dysfunction — the first time you meet it, you will assume you have misunderstood.

Then keep the last column current, and put the open rows into your monthly report as a single line: these inputs remain unavailable and were requested on these dates. Not as a complaint — as a statement of the position. One sentence a month, and it is the difference between a late report and a documented dependency.

The first month you do this it will feel like paperwork. The month somebody asks why your report was late, it stops feeling that way.

Key takeaways

• An organisation chart answers who reports to whom and neither of the two questions your work depends on.
• Those are who can decide the thing you need decided, and who can open the system holding the data you are accountable for.
• Every name in a plan is an office, and the latitude of the person behind it is a documented fact you should be holding.
• Delegated authority takes effect only when notice of it has been received by both parties, and it can be revoked the same way.
• Agreements, determinations and notices to correct can't be delegated, so the person you deal with daily can't decide what matters most.
• Pressing harder on somebody at site fails when the outcome lies outside the office they hold.
• Being answerable for an output whose inputs sit behind somebody else’s access is the ordinary condition rather than a dysfunction.
• Access sits with whoever administers a system, and administering a system is a different job from delivering a project.
• Deciding and releasing are separate authorities, so agreement at a meeting isn't movement.
• No programme has an activity for obtaining access, so the waiting appears as a late report attributed to whoever produced it.
• A dated request converts an invisible dependency into a visible one, before anybody has to argue about cause.

Records born here. The organisation chart as issued · the notice of delegated authority, and any revocation of it · the named individual behind each office · the access register · each access request with the date it was made · the escalation route when the person who agrees isn't the person who can act.

What is coming next

Once you can reach the data, a different problem starts, and it is the one that decides whether any of this can be assembled at all.

A quantity in a bill, an activity in a programme and a line in a daily report describe the same piece of work and carry three unrelated identifiers. Nothing joins them except a person who knows both ends. The next question is the structure that would join them, why it can only be built on day one, and what it costs to discover in month twenty that nobody built it.