How to map dependencies in a subcontractor schedule

Identify the handoffs that govern the work

A task list tells you what must happen. A dependency tells you what has to happen first. For a specialty subcontractor, the important relationships often cross organizational boundaries: approved drawings before a release, material arrival before fabrication, site readiness before installation.

Begin with the required delivery or installation milestone and ask what immediately precedes it. Repeat until you reach the earliest decisions. Do not link every row simply because one appears above another. Parallel work can stay parallel when it genuinely can proceed independently.

• Write each activity as an observable outcome, such as 'drawings approved'.
• Identify who controls the handoff.
• Mark external approvals separately from internal tasks.

Choose the relationship carefully

Most basic schedules use finish-to-start links: fabrication can begin after the needed drawings and materials are ready. Sometimes work can overlap. Partial approval may permit one area to enter production while the remainder is reviewed. Model that as separate areas or releases instead of pretending the whole package is approved.

Avoid using a fixed lag to conceal a missing task. If curing, shipping, inspection, or mobilization consumes real time, show it explicitly when it can change or has an owner. A short administrative gap may be a lag, but a procurement process is work.

• Use separate releases when a package can move in parts.
• Show real waiting periods that affect the finish date.
• Keep a note for any unusual overlap or assumption.

Test the logic with a change

Move one approval date by a week. Does the dependent purchasing or production date respond in a way the team expects? If the installation date stays fixed, does the schedule reveal lost float or a conflict? A schedule that shows no effect when a controlling approval slips probably has missing logic.

Then test the opposite: move a non-controlling activity. If unrelated work shifts, the plan may have unnecessary links. The point is not a perfectly connected diagram; it is a plan that explains consequences.

• Trace the path from approval to site milestone.
• Review any link that creates an implausible chain reaction.
• Document a manual override and the reason for it.

Worked example

A steel package has two drawing releases. The first supports columns and beams; the second supports miscellaneous metals. If both are tied to a single 'drawings approved' task, a late handrail review can appear to delay the main frame. Split the releases and connect each to the material and production it actually controls.

The frame can advance while the miscellaneous package remains under review. The site milestone for each area then has its own credible path. This produces a more honest conversation with the GC than one oversized approval bar.

• One package can have multiple approval and delivery paths.
• Link by scope or area when the handoffs differ.

Keep the logic maintainable

A dependency network can fail in two ways. With too few links, a delay appears to have no consequence. With too many, an unrelated change moves the entire plan. Review each link by asking: if the predecessor is late, must the successor truly wait? If the answer is sometimes, split the scope or document the condition.

Use milestones for handoffs that another party can verify. For example, 'approved for fabrication' is an event; 'review drawings' is an activity. A milestone should not carry a long duration to absorb uncertainty. Put the review and revision work before it so the schedule explains where time goes.

After a major change, inspect both the downstream path and the activities that did not move. The latter can reveal a missing link. Ask the shop and field leads whether the resulting sequence could actually be executed.

Review before sharing

Walk the plan with the people who perform the work. Ask what they could start before an approval, what they cannot start without materials, and where a release is too broad. Their answers often expose assumptions that a PM cannot see from a drawing log alone.

• Can every key milestone be traced to its prerequisites?
• Are external decisions assigned to an owner?
• Do parallel activities remain independent?
• Does a slipped date reveal a useful consequence?

Common questions