Map Minimum Resources and Hidden Dependencies

A dependency map begins with the service output rather than an equipment inventory. Put 'valid, confirmed field dispatch' at the top, then ask what activities must succeed to create it. The service may need an authorized request, an identity check, a worker assignment, contact with that worker and a record of acceptance. Draw from each activity to its necessary resource: appointment register, staffing list, access rights, communications channel, premises or supplier. A resource is different from usable capacity. Six vehicles do not prove six dispatches if there are no licensed drivers or a permit system has failed. Dependencies also have different degrees of necessity: a documented temporary process might allow later manual entry, whereas a safety or data-validity step cannot be deleted because the diagram is crowded. Define the minimum service level to be tested, then draw only routes capable of that output.

Use an AND relationship when output requires all named inputs and an OR relationship when either of two demonstrated alternatives suffices. Dispatch needs both a worker list and contact with the worker. Contact might be possible by mobile network or a demonstrably independent radio route. Test the independence claim. The mobile and radio paths may share one authorization server, or the main and alternate sites may depend on one power supplier. Drawing two branches has not removed a common point of failure. For each resource record its owner, the source of availability evidence, the switch authority and the time required. Where no trial or agreement supports an assertion, mark the branch unverified instead of drawing it green. A later exercise measures the entire service path, not just whether the diagram looks complete.

A simple cut-set test exposes false assurance. Imagine two ways to confirm an appointment, website and phone. If both depend on one availability register, removing that register cuts both paths. It is a common failure point even when two departments operate the channels. If an independent phone register is introduced, ask where its source data and updates originate; the common dependency may return through synchronization. A temporary fallback need not have identical real-time data, but it does need a rule preventing conflicting slots and a reconciliation method after restoration. State the effect of each loss on output: complete stop, reduced throughput or degraded validity. Technical availability is not the same as demonstrated operational capability. The word 'available' is meaningful only with an output, quality level, volume and time attached.

Calculate chain capacity from its bottleneck rather than adding departmental capacities. In a fictional dispatch path, triage can review 80 requests per day, validation can authorize 55, and vehicles can complete 45. Maximum complete output is 45 daily if all stages operate under the same assumptions and no usable work-in-progress inventory changes the flow. Adding triage staff does not raise that ceiling. Adding vehicles may move the constraint to validation at 55. Yet the number 45 does not establish what happens during a real disruption: every job might still require available communications or correct location data. Put a data-validity condition next to throughput. If ten percent of requests need correction, do not automatically multiply 45 by ninety percent before knowing whether corrections consume the same capacity or merely delay work. Record what needs measurement rather than projecting false precision.

People are dependencies too, but a name count is inadequate. Record skills, authority, location, shift coverage, rest and ability to work during connectivity loss. A single person authorized to approve exceptions may disable a complete alternate route by being absent, even when three other staff are present. Design a substitute mandate before the disruption with decision limits and an audit trail; do not presume any manager on duty may authorize the action. A full-day test helps because shift patterns can reveal a gap hidden in a one-hour trial. Ask the supplier whether the alternate path is on an independent site, which entry point both routes share, and whether minimum capacity persists if other customers demand recovery simultaneously. A marketing assertion is not a proven capability; seek an appropriate trial or contractual evidence.

Version the map whenever a database moves, a shift pattern changes or a supplier contract is renewed. Annotate each dependency edge with the date and method of verification, not merely the drawing date: owner interview, operating document, observed exercise or incident record. These support different conclusions. An interview describes intended design; a completed valid job during an exercise demonstrates bounded capability under the observed conditions. When a new common resource is found, recalculate both routes and their failure timing instead of adding a box without revisiting the decision. Test concurrent high demand too: a resource sufficient for one service can become the bottleneck when three services recover together. State who allocates that shared resource and what happens if a higher-impact service takes it first. Engineering redundancy does not equal independent recovery until data validity, authority and people capacity are checked. The evidence trail links the dependency map to impact analysis and readiness testing and helps reveal when a once plausible assumption has expired.