Dependencies carry the real sequencing logic

A predecessor link says that a successor cannot begin until an earlier task finishes. The reason for the link matters as much as its position in the network. Physical sequence, information release, scarce resources and contractual permission can all create apparent dependencies. They do not have the same remedies. A planner who deletes a link to improve the finish date must know whether the link represented an unavoidable physical condition or a convenience that can be changed. Network editing without a causal explanation creates a schedule that may be shorter but less executable.

A physical dependency arises from the work itself. Equipment cannot be assembled on an unready support if the required interface is absent. An information dependency arises because a successor needs a released specification, decision or verified measurement. A resource dependency arises when activities require the same unavailable crew or specialist. A contractual dependency arises because a notice, approval or permission must occur before the successor can be authorised. Some relationships contain several causes. A test may need both a physically complete subsystem and formal permission to energise it.

The Delivery atlas represents finish-to-start edges without encoding these dependency types. This is a deliberate limit of the small model, not evidence that the distinctions are unimportant. The paper's dependency register supplies the reason, owner and evidence behind each edge. The app then calculates the consequences of the entered topology and duration assumptions. A resource relation that is omitted from the network remains omitted from its result. A typed register helps a reviewer understand what the model includes and what supplementary planning is still needed.

In the fictional installation, design release enables supply and receiving works in parallel. This topology assumes each branch can proceed from the same released information and neither needs the other's completed result. A revised method may instead require equipment readiness before receiving works can be finalised. The serial-release study changes that dependency while retaining the duration assumptions. Its expected completion becomes 25.00 weeks. The lesson is causal: changing the relationship can alter delivery even when no activity becomes slower. It is not evidence that parallel working is always preferable.

A dependency register should name the condition that releases the successor. Finished design is insufficient if the relevant specification remains unapproved. Equipment delivered is insufficient if it is not available in the configuration required for assembly. The wording should point to an observable event and its evidence. Otherwise the predecessor can be marked complete while the successor still lacks what it needs. This creates a hidden lag whose duration is later attributed to execution, although the original logic never represented the actual release condition.

An edge deserves a challenge when its reason is unclear, its evidence is unavailable or its consequence is disproportionate. The challenge should preserve the original link while examining alternatives. Can the successor begin with partial information? Can a separate release package be created? Can different resources remove the conflict? Can authority be delegated within the actual rules? These are different interventions. A blanket request to overlap tasks skips the question of what exposure the overlap creates and who is authorised to accept it.

Partial information release can be valid when the successor's scope is bounded. A supplier may begin a standard component before a custom interface is finalised, provided the frozen portion and rework exposure are clear. The network then needs a meaningful partial-release milestone and a later interface condition. Replacing the whole design predecessor with a shorter arbitrary duration erases the distinction. It also makes it difficult to explain responsibility if the unfinished information later changes. The dependency record should retain what was known and what was knowingly left open.

Resource sequencing can be mistaken for physical logic. A specialist may perform equipment inspection and then support site acceptance because both assignments rely on the same person. A finish-to-start link can encode this sequence, but it hides the cause if the resource register is absent. Bringing in another qualified specialist might remove the dependency without changing the work method. Conversely, deleting the link while retaining the same resource creates an infeasible overlap. The causal type determines whether a recovery proposal is a topology change, a resource change or an unsupported wish.

Contractual approval can be mistaken for inevitable waiting. Some decisions have mandatory periods or external jurisdictional constraints. Others wait because evidence arrives incomplete or the approver has no scheduled review capacity. The schedule should not assume all waiting can be compressed, nor should it treat administrative latency as a natural constant. Record the applicable requirement, the completeness condition for submission and the responsible decision authority. A legal or regulatory interpretation belongs to the appropriate specialist and actual instrument, not to a generic scheduling rule.

Dependency challenges should be visible to the recipient. The producer may consider a predecessor unnecessary because its own work can start without it. The successor's accepting party may still need the result before it can approve completion. These are different release points. The integrated record should state whether the proposed change affects start readiness, completion acceptance or both. A local optimisation that accelerates production but defers essential acceptance evidence can leave the overall service date unchanged.

A typed release register adds a practical layer to the network. For each material edge it records predecessor, successor, causal type, release evidence, owner, challenge status and consequence if the condition fails. It need not repeat every scheduling field. Its purpose is to let someone test the logic without reverse-engineering a chart. A reader should be able to follow why assembly waits for the receiving works and what precise evidence would allow that relation to be satisfied or changed.

The register is most valuable where the project crosses organisational boundaries. The supplier may forecast readiness using its factory acceptance event, while the assembly contractor plans from availability at the site. Transport, receiving inspection and discrepancy resolution sit between those events. If each party maintains a coherent local schedule but the integrated schedule joins mismatched milestones, the overall model contains a gap. The register makes the shared boundary explicit. It can reveal missing tasks without prescribing how either party manages its internal work.

A dependency must also have a version. A link that was valid for one design may be invalid after a change in installation method. Retaining it unquestioned may make the forecast unnecessarily conservative. Removing it without recording the new basis may make the forecast unsupported. The register should record when the causal basis changed and which downstream assumptions were reviewed. The affected closure often extends beyond the immediate successor, since a new sequence can shift resource demand, acceptance timing and the critical path.

Do not infer a dependency from correlation in a historical report. Activities may have occurred sequentially because the team preferred that order, even when parallel work was feasible. They may also have appeared parallel because the report's time resolution concealed a real release condition. Historical observation can suggest questions, but the executable relationship needs a current causal and acceptance basis. This is especially important when using lessons from another project, where equipment, authority, resources and contracting arrangements differ.

The register does not turn every uncertainty into a fixed edge. Discovery can reveal work that is not yet definable, and external decisions can create alternative branches. A static precedence model may then be a conditional scenario rather than the whole delivery plan. State that condition and preserve the decision that selects the branch. The useful discipline is to make the relationship inspectable, not to force every possible future into a single tidy network. A model is strong when its boundary is clear enough that a reviewer can identify what would make it wrong.