WK10: | The Dependency Map Nobody Builds Until It's Too Late

Assumption Is the Default Operating Condition

Assumption is not an occasional project defect. It is a normal human shortcut — and unless it is deliberately challenged, it becomes the default operating condition of complex programs.

Every statement on the cover of this advisory is reasonable in isolation. Together, they produce a system that nobody has fully documented and nobody owns end to end.

The mechanism is well established. In 1968, social psychologists John Darley and Bibb Latané demonstrated diffusion of responsibility: as the number of people believed to be present increases, each individual becomes less likely to intervene and slower to intervene, because responsibility is felt to be shared. The mechanism transfers precisely — shared awareness does not produce individual ownership.

At cutover, assumptions stop being harmless. They become incidents.

A Migration Can Look Completely Ready and Still Be Structurally Unprepared

The application is online. Users can authenticate. The database is responding. Infrastructure monitoring is green.

Then a scheduled process fails. A third-party interface stops exchanging data. A service account cannot reach a legacy file share. A certificate chain points to an overlooked server. A downstream reporting platform receives nothing.

The cutover did not introduce a new defect. It exposed an old dependency that the migration plan never captured. That distinction matters because it locates the failure correctly: the failure began during discovery, not during cutover.

The Greatest Exposure Sits Outside the Visible Boundary

Discovery concentrates on the visible — servers, applications, databases, named interfaces. The exposure usually sits elsewhere:

• Indirect integrations and hardcoded addresses
• Scheduled jobs and legacy service accounts
• Vendor-side dependencies and informal file transfers
• Processes that run only weekly, monthly, or at period close

These remain invisible for a structural reason, not a technical one: someone knows about each of them, but nobody owns the complete picture.

‍

That is how assumption becomes architecture.

‍

Validation Proves Components Work. Dependency Mapping Proves the System Works.

The Cloud Migration PM Bible™ states the principle directly: validation confirms that each layer functions; dependency mapping confirms that the system functions as a whole. Enterprise systems operate through relationships — and it is those relationships, not the individual components, that most often fail. (Chapter 8, pp. 311–312)

A dependency map cannot be produced by asking one team to review an old diagram. It must be treated as an investigation — and an investigation requires three independent forms of evidence.

1.  Human knowledge

Application, Infrastructure, Network, Database, Identity, Security, Operations, Support, vendors, and business process owners. Every group sees a different portion of the system; no single team is the complete source of truth.

2.  Existing records

Architecture diagrams, CMDB entries, firewall rules, identity records, runbooks, schedules, and contracts. Records are a starting point — not proof of completeness.

3.  Observed system behavior

Logs, traffic flows, authentication records, API calls, scheduled-job histories, service-account activity, queues, and file transfers. Behavior is what the system does, as distinct from what it was documented to do.

The Three Sources Will Disagree. The Disagreement Is the Finding.

• In the diagram, absent from behavior — investigate it.
• In behavior, absent from the diagram — document it.
• In neither, but an expert says it exists — test it.

The objective is not to decide which source is correct. It is to reconcile them until the model reflects operational reality — and then to attach a name to every relationship in it. Evidence without ownership reproduces the original problem at higher resolution.

The PRE-MORTEM Risk Discovery Framework™

Ordinary discovery asks teams what they believe is connected. This framework reverses the mental model and asks what has already failed. Executed through the P.R.E.M.O.T. Model™, it exposes what ordinary discovery overlooks.

Without treatment and tracking, a pre-mortem produces insight. With them, it produces control.

‍

The Dependency Control Record

A dependency is not governed because it appears on a diagram. It is governed when every field below is populated and defensible.

The record is not a side artifact. Each material dependency enters the cutover runbook as a validation step; any dependency still lacking owner or evidence enters the RAID log as open exposure. Readiness approval is conditioned on closure, not on confidence.

A record with a blank field is not a documented dependency. It is an assumption with formatting.

‍

Systems Fail at the Edges

Cutover does not create hidden dependencies. It removes the conditions that allowed them to remain hidden.

The danger is not that nobody knew. In most cases, somebody did. The danger is that knowledge was fragmented, ownership was diffused, documentation was trusted without evidence, and no mechanism forced the assumption to be challenged.

The book states the control principle plainly: failures rarely occur at the center of systems. They occur at the edges — between systems, across environments, through integrations, and within dependencies. What breaks is not what you saw. It is what you did not map. (Chapter 8, p. 317)

If a dependency has no named owner, no validation evidence, and no cutover control, it is not understood. It is assumed.

‍

And assumptions do not remain assumptions forever. At cutover, they become operational truth.

Primary Source

Noël, Gérald L’Ouverture. Cloud Migration PM Bible™: The Complete Framework for Running Successful Infrastructure, Application, and Cloud Migrations.

External Research Foundation

• Darley, J. M., and Latané, B. “Bystander Intervention in Emergencies: Diffusion of Responsibility.” Journal of Personality and Social Psychology, 8(4), 1968, pp. 377–383.
• Mitchell, D. J., Russo, J. E., and Pennington, N. “Back to the Future: Temporal Perspective in the Explanation of Events.” Journal of Behavioral Decision Making, 2(1), 1989, pp. 25–38.
• Klein, Gary. “Performing a Project Premortem.” Harvard Business Review, September 2007.

Evidence note: the cited research establishes the mechanism, not the outcome — it does not measure cutover results. Claims here about dependency failure at cutover are execution principles grounded in practice.

© 2026 Cloud Migration PM Bible™ • All frameworks proprietary and reserved. • www.cloudmigrationpmplaybook.com

‍

‍