Dependency Spaghetti

AI projects can fail through couplings between components that were safe when they were separate and dangerous once they were combined. Where a PMO runs an AI project, it reports in milestone slips and RAG statuses. None of those artefacts has a slot for a combination that looked safe in isolation, so a project that fails this way is killed by things its own reports couldn’t see.

Installing a printer asks a small set of questions: is the tool in the room, does it print. Anyone who has shared an office printer knows the second question can take an afternoon, but once both answers come back positive, the remaining work concerns toner and the occasional paper jam. The deployment stays in the room, and success is a yes or a no.

Installing an AI system opens a much wider set of questions, and all of them stay open after the endpoint starts responding. The workflow couples to data flows and to the behaviour of the people using it, so the deployment never stays in the room. The same input produces different outputs on different days, and the workflow around the model drifts faster than any specification of it does. The endpoint can be responding perfectly while the outputs drift towards confident errors the process can’t catch. So success is never a yes or a no, at best a “mostly, the last time we looked”.

Run this like a rollout and the reports look very professional and miss the failure. The project continues, the status says green, and the failure comes on a schedule of its own: in production, after integration, once the distribution of live inputs meets the distribution of designed-for inputs and the two diverge.

None of this means the PMO has no role in an AI project. Somebody has to know when the steering committee meets. The mistake is letting it define how the state of the work gets reported.

Sort what a PMO produces by who consumes it and it goes two ways. Requests for status go down to the engineers as tasks, which in Graeber’s terms is a taskmaster’s output, and the statuses go up to a file as evidence that the project is under control, which is a box ticker’s. An agent can now do both ends, chasing the updates and writing the report from the tickets, every row with an owner and a colour. The report is as legible as ever and sees no more than it did, and the project pays when a combination nobody could enter as a row takes it down.

Steering slides list items that stand alone, one per row, each with an owner and a colour. What kills an AI project is connected to half a dozen other things.

A retrieval pipeline works cleanly in testing, then combines its latency with the downstream system’s timeout behaviour in ways neither team owns. A vendor update alters the system’s response to an edge case without notifying the integrator, because to the vendor it was a quality improvement. So whose incident is it?

A team that takes coupling seriously keeps a map of dependencies and a register of combinations that are survivable in isolation and dangerous together, and uses them as a running picture of where the system still behaves as designed and where it has started to drift. Sooner or later, someone will ask for it as a spreadsheet.

Checklists Flatten Risk

A checklist is a linear artefact, and producing one forces conditional, interacting reality into a flat list of discrete items. It works for inspections, and for hard gates with yes-or-no answers.

A checklist assumes that problems separate cleanly, and that ticking off items moves the project towards safety in a roughly additive way. Those assumptions hold reliably in infrastructure work and break down in AI work, where a workaround in one place creates fragility in another. The thing at risk is the relationship between components, which isn’t an item at all. And by the time a list is complete enough to look professional, the system it describes has already changed.

James C. Scott’s word for what the checklist does is legibility: the state, or the PMO, simplifies what it governs into a form it can read from a distance, and then governs the simplification.¹ Asking a technical team for “the list of problems” is asking for the legible version, and the project manager gets it. Leadership develops false confidence, because a list with statuses and owners reads as the unknown becoming known. And the accurate report gets punished: a technician’s explanation that the issue is a dependency pattern sounds vague next to a neat register, and whoever brought the register gets invited back.

Keep checklists for what they’re good at, and stop treating them as the reporting form for the whole system. A project leadership that wants a truer picture asks for dependency maps, and an account of what changed since the last review.

What the engineers know is conditional and relational: “this works if these conditions remain true”, or “this demos well and weakens in production”.

A request for red/amber/green statuses or “the list of problems” compresses that kind of truth until it lies. In practice the engineer picks amber, the colour for “it depends”, and nobody asks what it depends on.

A different request works better. Ask engineers where the system stops telling the truth, and under which combinations. The answer will be messier than a status code, and management’s job is to take it up the chain without tidying it.

A specification written for sign-off produces a document where each section exists because the template has that section, and where no section contains the information a builder would need to avoid the predictable failure. The approval table, on the other hand, is complete. The document is legible to approvers and of little use to the people who will have to keep the system alive. An agent now fills in the template in a minute.

Inside the PMO’s job is one nobody else on the project does: keeping the map of what depends on what, and noticing when a vendor update or a changed timeout makes two safe things dangerous together. The status report stood in for that map. An agent can help keep the map current, reading each change as it comes in, which no monthly report ever did.

Checklist

When you ask for status, do you get a list of problems or the shape of the failure: dependencies, the combinations that are dangerous together, and what changed since the last review?
Have you asked the engineers where the system stops telling the truth, what that depends on, and which combinations make it unsafe?
Was the specification written for the people who will keep the system alive, or for sign-off?
For each item on your checklist, is it a real gate, or a relationship between components that a checklist can’t hold?
If an agent now writes the status report, who keeps the map of what depends on what?

Notes

Scott 1998.↩