The writer has finished. The editor has a slot available. The publishing team has prepared the page. Yet the article cannot move forward because nobody can establish whether one important source can be used in the intended way.

Each team can describe useful work it has completed. The project still cannot complete the next handoff.

Project dependency management is the practice of identifying what one piece of work needs from another, agreeing the conditions under which that input becomes usable, and keeping its ownership, timing and evidence visible until the receiving work can proceed. It concerns the relationship between the work, not merely the work items themselves.

A dependency is therefore more than an arrow in a schedule. That arrow might conceal a technical requirement, an approval, an available specialist, a compatible version, a delivery condition or a decision nobody has yet made. Managing it means discovering what the arrow actually requires.

This guide develops that practical skill through a fictional publishing project, a worked schedule and a usable dependency register. The examples and suggested operating rules are teaching designs, not records of an actual eduKate project, externally validated benchmarks or mandatory professional standards.

1. Start with the receiving work

A task list usually begins with what people will do. A dependency conversation becomes more useful when it begins with what someone needs before they can do their work properly.

Ask an editor, “What must be available before you can complete this review?” The answer may include a stable manuscript, access to the sources, a defined reader, the approved topic boundary and enough time to resolve disputed claims. “The writer must finish” is only an abbreviated description of that arrangement.

Ask a teacher what must exist before a new teaching unit can begin. The answer might include suitable materials, familiarity with the lesson sequence, access to required equipment and a clear plan for assessing understanding. Receiving a folder does not establish all those conditions.

Ask an operations team what it needs before supporting a new system. A working application is necessary, but so may be monitoring, access, troubleshooting knowledge and an agreed route for incidents. The handoff cannot be judged solely from the delivery team’s perspective.

The University of Essex’s project-delivery guidance distinguishes dependencies within a project, across projects in a programme, and on external conditions. That distinction is helpful because the receiving team may depend on work outside its manager’s authority. Source: University of Essex, Dependency management.

A practical starting rule is simple: for every important deliverable, identify the next person or process that will use it. Ask that receiver what would make the input usable, what would make it unusable, and when those differences must be known.

2. Separate a dependency from a risk, an issue and an assumption

These concepts often appear together, but they perform different jobs. Keeping them separate helps a project choose the right response.

Concept	Question it answers	Illustrative statement
Dependency	What must another activity receive or satisfy?	The publication-readiness review requires the approved source packet.
Assumption	What are we currently treating as true?	The source reviewer will be available in the planned review window.
Risk	What uncertain event could affect the plan?	The reviewer may be unavailable when the packet arrives.
Issue	What has already happened?	The reviewer has withdrawn and no replacement is confirmed.
Decision	What authorised choice is needed?	Appoint another qualified reviewer, change the sequence or move the release.

A dependency can exist without being unusually risky. A routine internal handoff may be well understood and reliable. Conversely, a project may face a risk that is not usefully represented as a relationship between two scheduled activities.

In the example, retain one dependency identity and link the assumption, risk, issue and decision to it. Do not create five unrelated descriptions of the same situation. The aim is to preserve the relationship while allowing its condition to change.

For a fuller treatment of uncertain events and responses, use Project Risk Management. This article concentrates on the practical question left behind: who needs what from whom, under which conditions, before which moment?

3. Use a precise dependency sentence

“Waiting for finance” is not a sufficient dependency description. It identifies a department but leaves the required action, decision, evidence and timing unclear.

A stronger sentence is: “The procurement lead needs the authorised spending limit and named contract signatory from the finance owner before issuing the final supplier instruction.” The receiving action is clear. The required input is clear. The handoff has a meaningful purpose.

A useful writing pattern is: Receiver needs input from producer, meeting specified conditions, by the required point, so that a named action can proceed. This is a practical template proposed here. Its value lies in the questions it forces into the open, not in the wording itself.

For the fictional publishing project, write: “The publication-readiness reviewer needs manuscript version 3 and its approved source packet from the writing and research owners by the opening of working Day 11, so that the three-day review can proceed against one stable edition.”

That sentence immediately reveals two inputs, two supplying roles, a version requirement, a review window and an intended downstream action. It also reveals a question: what happens when the manuscript changes after the source packet is approved?

Precision does not require a long document for every task. A low-consequence handoff may need only one well-written line. More detail becomes justified when misunderstanding could cause expensive rework, unsafe action, invalid acceptance or a missed external commitment.

4. Distinguish sequence from permission

A schedule relationship describes a timing constraint. It does not necessarily contain all the conditions that authorise the next action.

Microsoft’s Project documentation describes four relationship types: finish-to-start, start-to-start, finish-to-finish and start-to-finish. A start-to-start relationship does not mean two tasks must start simultaneously; a finish-to-finish relationship does not require simultaneous completion. These are constraints on timing. Source: Microsoft, Link tasks in a project.

Relationship	Timing meaning, with no added lag	Illustrative use
Finish-to-start	B cannot start before A finishes.	Final release follows completion of required checks.
Start-to-start	B cannot start before A starts.	An observation activity begins only after the pilot begins.
Finish-to-finish	B cannot finish before A finishes.	A running reconciliation cannot close before the final input collection closes.
Start-to-finish	B cannot finish before A starts.	An outgoing coverage period cannot end before replacement coverage begins.

The examples illustrate timing, not complete operating procedures. Replacement coverage may also require competence, access and an acknowledged handover. Representing the start-to-finish link does not prove that those conditions have been satisfied.

Similarly, a manuscript may be marked finished while an unsupported claim remains unresolved. A schedule can accurately report that writing ended without establishing that publication is authorised. Keep a separate acceptance condition where permission matters.

This separation prevents a dangerous shortcut: a calendar event becoming an assumed approval. Dates describe when something is intended or observed to happen. Evidence and authority establish whether it may happen.

5. Treat important handoffs as agreements between two sides

The producer understands what it intends to deliver. The receiver understands what it needs to use. A workable handoff requires those descriptions to agree.

NASA’s interface-management guidance addresses work divided among different parties. It emphasises defining interfaces, compatibility, responsibilities, controlled changes and verification. Its engineering context is more demanding than many ordinary projects, but it makes a useful distinction: a connection needs its own management, not only competent work on either side. Source: NASA Systems Engineering Handbook, Interface Management.

For an ordinary project, an important handoff agreement can stay compact. Record the required input, supplying role, receiving role, usable condition, relevant version, timing, evidence location and escalation owner. The receiver should be able to recognise success without guessing what the producer intended.

Consider a data handoff. “Spreadsheet delivered” does not tell the receiving team whether identifiers are unique, required fields are present, dates follow the expected convention or missing values have been explained. The producer may have delivered exactly the file it promised, while the receiver still cannot use it.

Describe the interface instead: which fields, which definitions, which checks, which version and which receiving test? Once those conditions are explicit, both sides can estimate their work more honestly.

The point is not to turn colleagues into opposing contractual parties. It is to give cooperation a shared definition of what successful exchange looks like.

6. Give ownership enough detail to prevent gaps

“The project manager owns the dependency” can mean several different things. It might mean the project manager monitors it, produces the input, accepts the input or resolves disputes. Those are not interchangeable responsibilities.

For consequential handoffs, distinguish a producer, a receiver and a coordinator. The producer is responsible for the promised input. The receiver assesses whether the input satisfies the agreed need. The coordinator maintains visibility and routes unresolved cross-boundary decisions.

One person may perform more than one role in a small project where that is appropriate. The important safeguard is not a compulsory number of people. It is that the project understands which responsibilities exist and where independent approval is required by its actual rules.

For example, an editor might coordinate a publishing dependency, while a researcher provides the source packet and an authorised reviewer decides whether it supports the intended claims. The editor’s ability to chase the packet does not give the editor authority to approve its contents.

Also identify who can resolve the conflict when the producer and receiver disagree. That may be a product owner, technical authority, sponsor or another defined decision-maker. Without this route, two competent teams can remain blocked while each waits for the other to concede.

7. Keep the required date, promised date and forecast distinct

A dependency conversation often contains three different dates disguised as one.

The required date is when the receiver needs the input under the current plan. The promised date is what the producer has agreed to supply. The forecast date is when current evidence suggests the input will actually become usable.

Suppose the receiver needs an approved packet on Day 11, the producer promised Day 6, and the latest forecast is Day 9. The producer is later than promised, but the receiving activity may still be protected. Calling the whole project late would be premature.

Now suppose the forecast becomes Day 13. The required date is no longer protected. A conversation about downstream consequences is necessary even though the producer might still describe the packet as “almost complete.”

The United States Government Accountability Office describes a reliable integrated schedule as a way to assess whether planned events are achievable and to understand the effects of change. That is the reason these dates should connect to the schedule rather than remain isolated promises in email. Source: GAO Schedule Assessment Guide, overview.

Record the date on which the forecast was refreshed. An old forecast is not necessarily false, but its age tells the reader something important about the evidence supporting it.

8. A worked example: publishing a researched learning guide

Consider a fictional project to publish one researched learning guide. The project has eight activities. These durations are invented for teaching. They are not promises about actual writing, review or publishing performance.

Assume one shared working calendar, no holidays, sufficient resources, no extra lag and finish-to-start relationships throughout. Day 0 is the starting boundary. An activity running from Day 0 to Day 2 consumes two working days.

For this example, the team has chosen to start its consolidated publication-readiness review only after both the manuscript and the approved source packet are available. Other projects may review portions earlier; that would be a different network.

ID	Activity	Duration	Predecessor	Earliest interval
A	Agree reader, topic boundary and acceptance criteria.	2 days	None	Day 0–2
B	Prepare and approve the source-use packet.	4 days	A	Day 2–6
C	Develop the selected outline.	3 days	A	Day 2–5
D	Write the manuscript.	6 days	C	Day 5–11
E	Complete publication-readiness review.	3 days	B and D	Day 11–14
F	Resolve findings and confirm the revised edition.	2 days	E	Day 14–16
G	Stage the edition and perform technical checks.	2 days	F	Day 16–18
H	Complete the authorised release and verification.	1 day	G	Day 18–19

The longer route is A → C → D → E → F → G → H. Its duration is 2 + 3 + 6 + 3 + 2 + 2 + 1 = 19 working days. The other route, through source preparation, takes 14 working days. In this simplified network, the source branch therefore has five working days of total float.

The review starts at the later of two input-ready times. With the source packet ready on Day 6 and the manuscript ready on Day 11, it starts on Day 11. An early source packet does not pull the review forward while the manuscript remains unavailable.

That gives the project a more useful question than “Which task is late?” It can ask, “Which missing input currently controls the next meaningful start, and how much time remains before another input becomes controlling?”

9. What happens when the source packet slips?

Suppose Activity B finishes on Day 9 rather than Day 6. Its own commitment has slipped by three days. However, Activity E still cannot begin until the manuscript arrives on Day 11. Under the example’s assumptions, the final completion remains Day 19.

This does not mean the delay is irrelevant. Three days of flexibility have been consumed. The team should investigate the cause and refresh the remaining forecast. But it should not automatically add three days to the project finish.

Now move the source packet’s usable date to Day 13. Activity E begins on Day 13, finishes on Day 16, and the downstream activities shift the final completion to Day 21. The source packet is seven days later than its original finish, but the project is two days later because the first five days were absorbed by float.

These results follow from this particular network, not from a universal rule about source reviews. Different calendars, resource bookings, acceptance failures or external release windows can change the outcome.

For example, a missed review window may delay the project more than the input itself. A reviewer booked only once a week introduces an availability constraint that is absent from the table. The apparent float cannot be relied upon until that constraint is represented.

Use Critical Path Method for the fuller scheduling mechanism. Dependency management supplies the reliable inputs that make that analysis worth using.

10. A file can arrive before the dependency is satisfied

Return to the publishing case. The researcher sends a folder on Day 6. The team marks Activity B complete. On Day 11, the reviewer discovers that two references do not support the manuscript’s actual wording.

The folder arrived on time. The usable input did not.

A practical register should distinguish submission from acceptance where that difference matters. The producer’s submission date records an observable event. The receiver’s acceptance records a separate judgement against agreed conditions. Neither should silently replace the other.

In this guide’s proposed terminology, a handoff can move through identified, agreed, preparing, submitted, accepted and consumed. “Consumed” means the receiving work has actually used the accepted input for its intended purpose. These labels are optional operating terms, not a universal standard.

Do not make every project maintain six status fields. Use the distinctions that prevent real ambiguity. A straightforward equipment booking might need only requested and confirmed. A consequential publication or technical release may need to distinguish approval, transfer, acceptance and use.

Where an exception is accepted, record its scope. Acceptance of a draft for discussion is not acceptance for public release. Acceptance of a sample is not necessarily acceptance of the whole collection.

11. Build a register that leads to action

A dependency register should help someone decide what to do next. A register that contains only names, dates and colours can look complete while failing that test.

For the fictional learning guide, the following compact view is enough to expose several important relationships. The references shown as evidence descriptions are illustrative; they are not links to actual project files.

ID	Producer → receiver	Required usable input	Required point	Evidence to check
DEP-01	Commission owner → writer	Agreed reader, topic boundary and acceptance criteria.	Before detailed outline work.	Approved brief and named owner.
DEP-02	Research owner → readiness reviewer	Sources supporting the current claims, with use conditions resolved.	By Day 11 in the baseline example.	Source packet tied to the submitted manuscript.
DEP-03	Writer → readiness reviewer	The identified manuscript edition.	By Day 11.	Edition identifier and accessible manuscript.
DEP-04	Review coordinator → correction owner	Specific findings with evidence and disposition requirements.	Before correction begins.	Finding record linked to the reviewed edition.
DEP-05	Correction owner → publishing operator	The approved revised edition.	Before staging is treated as release-ready.	Resolved findings and current approval.
DEP-06	Publishing operator → maintenance owner	Verified destination and accepted maintenance responsibility.	Before project closure.	Observed publication record and owner acknowledgement.

The working register would also hold the latest forecast, current condition, last verification time and next action. Keep detailed evidence in its authoritative location rather than copying the same material into multiple reports.

A useful next-action field reads: “Research owner to replace the unsupported source or narrow the claim before the readiness review is reconfirmed.” A weak field reads: “Monitor closely.” The former identifies a change that could unblock work. The latter may merely describe continued observation.

12. Make every status explain its evidence

Suppose a dependency is marked green. Ask what observation makes it green.

Is the input already accepted? Has the producer made a credible commitment? Is the date merely unchanged? Has somebody checked the forecast recently? Those conditions deserve different confidence.

For a small team, use plain-language conditions: “accepted and available,” “not yet needed; current forecast protects the required date,” “required date threatened,” or “current state unverified.” Such descriptions can be more informative than an unexplained colour.

Missing evidence should remain missing evidence. Silence from a supplier is not proof of on-time delivery. An unchanged dashboard is not proof that a test passed. A document labelled approved is not proof that the approval covers its latest version.

This does not require treating every unknown as a crisis. It requires keeping uncertainty visible so the project can decide which unknowns need immediate attention and which can wait within an agreed review window.

13. Watch the date at which a decision becomes necessary

The required delivery date is not always the last useful decision date. A project may need to activate an alternative much earlier.

Suppose the approved packet is required on Day 11. A substitute source needs two working days to find, review and incorporate. In the simplified case, the team needs an actionable decision by Day 9 to preserve Day 11, assuming immediate availability and no further disruption.

Waiting until Day 11 to discover that the original packet will not arrive removes the alternative’s useful window. The dependency was not just a delivery promise; it was also a timed decision about when to stop relying on that promise.

Where the alternative itself is uncertain, do not present the latest possible decision point as comfortable margin. Allow a deliberate buffer, document the assumption or escalate sooner. The correct allowance depends on the consequences and the evidence, not on a universal percentage.

A practical escalation message can therefore say: “The input is required on Day 11. The current forecast is Day 13. The alternative needs two days. A decision is required by Day 9 to preserve the current review start.” This gives the decision-maker a choice rather than a general expression of concern.

14. Resource dependencies need their own reality check

A schedule may show two activities in parallel because neither logically depends on the other. That does not mean both can occur simultaneously with the available resources.

Suppose one qualified reviewer is required for two full-day reviews on the same day. The work has no necessary technical sequence, but the allocation is impossible under the stated assumptions. The project must add suitable capacity, move one review or change the agreed method legitimately.

Do not disguise this as an inherent technical dependency. Label it as a resource constraint. That distinction preserves alternatives: another suitable reviewer may remove the conflict, whereas no amount of extra staffing removes a genuinely necessary predecessor condition.

Also test whether “available” includes the preparation needed to work. A replacement might need access, context and time to understand the material. A person’s name on a booking is not the same as usable capability at the required moment.

Use Project Resource Management for capacity planning. In the dependency register, retain the specific handoff consequence: which receiving activity cannot proceed, which capability is missing, and who can resolve the allocation.

15. External promises need observable intermediate evidence

A project has less direct control over an external supplier’s internal work. That makes an unexplained final delivery promise a weak basis for confidence.

Choose intermediate evidence relevant to the actual delivery. For equipment, this might be design approval, material availability, completed inspection or confirmed shipment. For a commissioned report, it might be an agreed outline, an accessible working draft and an identified review arrangement.

These are suggestions for designing visibility, not universal contract requirements. The appropriate information, access and approval rights need to match the agreement and the project’s authority. Do not assume a project manager can demand information the supplier has not agreed to provide.

Separate the supplier’s contractual obligation from the project’s internal need. A contract may permit delivery on Day 15 while the internal plan requires the same input on Day 11. Chasing the supplier harder does not repair that inconsistency.

The project must reconcile the two commitments through an authorised commercial or planning decision. Project Procurement Management addresses that wider relationship. The dependency record should make the mismatch visible before downstream teams rely on the earlier date.

16. Version changes can reopen completed dependencies

The source packet supports manuscript version 3. The writer adds a new section and submits version 4. Has the dependency remained satisfied?

Not automatically. The new section may introduce claims outside the approved evidence. A cosmetic change might require little additional review; a material claim change can require renewed verification. The point is to assess the difference rather than carry the old approval forward blindly.

NASA’s configuration-management guidance treats identification, baseline control, change management, status records and verification as connected disciplines. The applicable general principle here is that a product and the information describing its approved state must remain consistent. Source: NASA Systems Engineering Handbook, Configuration Management.

For a modest project, begin with stable identifiers. Record which manuscript, dataset, drawing, requirement set or configuration the handoff concerns. Keep its approval and acceptance evidence connected to that identity.

When something changes, ask which downstream work used the earlier version. Do not mark all dependent work invalid reflexively. Some outputs will remain unaffected. Others may need correction, retesting or renewed approval. Record the assessed impact and who owns the follow-through.

A dependency is closed for a defined relationship and state. It is not a permanent certificate that every future version will also be suitable.

17. Resolve circular waiting without pretending the uncertainty is gone

The writer wants an approved example before completing the draft. The reviewer wants a completed draft before approving the example. Both requests can sound reasonable, yet the arrangement creates circular waiting.

Start by examining whether both sides truly need the final state. Often one side needs a bounded provisional input. The reviewer may be able to approve the factual treatment of the example without approving the finished article. The writer can then complete the manuscript for a separate final review.

This breaks the cycle by separating decisions. It does not relabel provisional approval as final approval.

In iterative work, represent successive versions explicitly: provisional example, draft using that example, reviewed example, revised manuscript. A schedule can then show a sequence of learning steps instead of an impossible demand for everything to be final before anything begins.

Some cycles cannot be solved by splitting work. They reveal a missing authority, incompatible requirements or an unresolved design question. In those cases, the dependency is waiting on a decision, and the project should name that decision instead of circulating reminders.

18. Reduce dependencies where the relationship is unnecessary

Not every dependency deserves to be managed forever. Some deserve to be removed through an authorised redesign of the work.

Suppose five writers wait for one specialist to format their sources. A shared, understandable source template might allow writers to prepare the initial records themselves, leaving the specialist to review exceptions. The specialist’s judgement remains where necessary; a routine preparation queue becomes smaller.

Or suppose every change to an article title requires a full committee meeting. The organisation might delegate small title adjustments within an agreed topic boundary while retaining stronger approval for changes that alter claims or ownership. That is a governance redesign, not permission for a project manager to ignore the current rule.

Distinguish three possibilities: the dependency is inherent, the dependency is a deliberate control, or the dependency is a habit. Inherent requirements need accommodation. Deliberate controls need appropriate authority to change. Habits are candidates for simplification once their purpose has been examined.

The objective is not the smallest possible dependency count. Some dependencies protect quality, coordination and legitimate authority. Remove unnecessary waiting without removing necessary judgement.

19. Review the exceptions, not every row every time

A dependency review becomes exhausting when every owner narrates every item, including inputs that are already accepted and no longer changing.

A more useful meeting concentrates on changed forecasts, threatened required dates, missing evidence, disputed acceptance, new version impacts and decisions approaching their latest useful point. Routine confirmations can remain in the shared record.

For each exception, ask what changed, which receiving work is affected, what options remain, who can decide and what evidence will demonstrate resolution. End with a named action or an explicit decision to continue observing until a defined review point.

For example, “The source packet remains unverified; research owner to confirm the disputed references by tomorrow’s review” is an accountable temporary state. “Still amber” is not enough because it gives no mechanism for changing the condition.

Choose the review cadence according to the pace of change. A slow early-stage dependency may not need daily attention. A launch-critical handoff may need more frequent checks. Reassess the cadence when the dependency enters a more consequential stage.

20. Measure reliability without rewarding concealment

A team that is rewarded only for closing dependencies can improve its numbers by lowering acceptance standards or removing difficult items from the register. The measurement design should therefore preserve the meaning of closure.

Useful candidate measures include accepted-on-time handoffs, days of downstream blocking, forecast age, unresolved acceptance disagreements and the number of accepted inputs reopened by material change. Treat these as proposed signals, not compulsory indicators.

For an accepted-on-time rate, define both numerator and denominator. Count handoffs accepted by their required dates among the handoffs due during the reporting period. A dependency not yet due does not belong in that denominator merely because it exists.

Also preserve required-date changes. Otherwise a team can improve apparent performance by moving dates after delivery becomes late. Reporting may show performance against the original commitment and the current authorised plan separately, with the reason for change visible.

None of these metrics explains cause on its own. Repeated blocking might reflect weak supplier performance, unrealistic acceptance timing, insufficient review capacity or poorly defined inputs. Use Project Performance Measurement to connect indicators to the decisions they are meant to support.

21. Apply the same method beyond publishing

A teaching programme

Imagine a new learning unit supported by worksheets, teacher preparation and a practical activity. The worksheets are complete, but the teacher has not had the opportunity to rehearse the activity. The project should not interpret material completion as classroom readiness.

Define the receiving condition: the teacher can explain the intended concept, operate the activity and recognise the main misconceptions. The evidence might be a short rehearsal or discussion against agreed criteria. This is an illustrative readiness design, not a claim that one rehearsal proves educational effectiveness.

A service migration

Imagine a new booking system. Data transfer completes, but the receiving application cannot reconcile several records. Treat transfer completion and usable migration as separate conditions. The dependency should identify what reconciliation is required before the next authorised stage.

Likewise, a rollback procedure that has been written is different from one demonstrated under the conditions relevant to the project. The receiving operations team should know which state is evidenced and which remains untested.

An event

Imagine a school event whose room booking is confirmed but whose access arrangements remain unclear. A booking receipt alone does not establish that the setup team can enter at the required time with the required equipment.

Use the same dependency sentence: the setup team needs confirmed access and the agreed room condition from the venue owner before preparation begins. The method remains simple because the actual handoff is simple. Add detail only where the uncertainty or consequence warrants it.

22. Keep AI suggestions separate from verified project state

When using an AI assistant to examine a task list, ask it to propose missing relationships rather than to declare them established. A plausible dependency still needs confirmation from the people responsible for the work.

For example, an assistant might suggest that a guide requires specialist review. That is a useful question to investigate. It does not prove that the reviewer exists, is available, has accepted the assignment or has approved the current manuscript.

Design the workflow so a proposed relationship has a different state from a confirmed one. Require the underlying source record when an assistant summarises a date, approval or acceptance. Do not let fluent wording replace the evidence that the receiving work actually needs.

A useful prompt is: “Identify possible missing inputs for each receiving activity. Mark every inferred relationship as proposed. Do not infer approval, availability or completion. State what evidence or owner confirmation would resolve each uncertainty.” This is a suggested use pattern, not a guarantee about any model’s reliability.

The broader relationship between generation, verification and accountability is developed in AI Project Management. Here the boundary is narrow: machine-produced dependency suggestions must not silently become project facts.

23. A practical first working session

Begin with one important upcoming milestone rather than trying to model the whole organisation. Invite the people who must supply its inputs and the person who must accept the resulting state.

Write the milestone in observable terms. “Learning guide ready for authorised release” is more useful than “publishing complete” when different teams interpret completion differently. Then ask what must be true for that state to be reached.

For each required input, record the producer, receiver, acceptance condition and required point. Add the current forecast only when there is evidence for it. Where there is no confirmed forecast, write that it is unconfirmed and assign the action needed to obtain one.

Next, inspect the relationships together. Look for a shared scarce reviewer, a decision that is required before the delivery date, two teams waiting on each other, a supplier promise later than the internal need, or an approval tied to an older version.

Finish by assigning the next actions and the escalation route. The session has succeeded when the team knows which evidence or decision will unlock the next stage. It has not succeeded merely because a larger register now exists.

24. Questions that reveal whether a dependency is genuinely controlled

Must every task have a separate dependency record?

No. Routine relationships can remain in the schedule. A separate record is most useful when the relationship crosses owners, involves consequential acceptance, depends on external evidence or needs deliberate escalation. Avoid maintaining a second administrative system that adds no decision value.

Can a dependency be complete while a related risk remains open?

Yes. A component can be accepted for the agreed handoff while a separately owned risk concerns its later operation. Conversely, an accepted input can be reopened by a material version change. Define what has been completed and what continuing obligation remains rather than giving the whole situation one permanent status.

Should every late dependency be escalated to the sponsor?

Not necessarily. The worked example shows a late source packet that does not move project completion. Escalate according to consequence, available alternatives and delegated authority. A modest-looking delay may still need urgent escalation when it consumes the last opportunity to activate a viable alternative.

Can downstream work begin before an input is final?

Sometimes, under an explicitly authorised provisional arrangement. State what can proceed, which assumptions it uses, what rework might follow and which actions must still wait for final evidence. Do not turn a bounded permission to explore into a general permission to release or make irreversible commitments.

What should happen when the receiver rejects an input?

Compare the rejection with the agreed acceptance criteria. Record the specific gap, its evidence and the next action. The producer may need to repair the input; the receiver may have introduced a new requirement; both sides may have misunderstood an ambiguous agreement. Identify which condition applies before assigning blame or changing dates.

Who owns a dependency after project closure?

Any continuing obligation needs an enduring owner. An operating dependency on a support contract, data feed, maintenance activity or periodic review does not disappear when the temporary project closes. Transfer it deliberately through Project Closure and Handover.

What is the strongest sign that the register is working?

The team can explain a blocked handoff without relying on vague language: what is missing, why it matters, who supplies it, who accepts it, what evidence is needed and which decision becomes necessary next. A register that produces that clarity is useful even when some dependencies remain unresolved.

25. The final test: can the next piece of work proceed responsibly?

Return to the apparently finished article at the beginning. Writing is complete. An editor is available. The page is staged. The unresolved source condition is not a minor administrative detail if the project requires that evidence before release.

The useful response is not to repeat that everyone is busy, or to mark the handoff complete because a folder arrived. It is to identify the precise missing condition, preserve the current edition, assign the necessary action and show the consequence for the receiving work.

Once that condition is satisfied, record the evidence and let the next authorised activity proceed. When it cannot be satisfied within the current commitment, give the appropriate decision-maker real alternatives.

A dependency is managed when the project can explain what makes the handoff usable, how it knows that state has been reached, and what it will do when the state is threatened. That is the difference between a project whose tasks appear connected and a project whose people can rely on those connections.

Sources, boundaries and further reading

The definitions and technical distinctions above draw on the following primary institutional sources, checked on 5 September 2026. The fictional case, register, operating terminology, worked arithmetic and suggested meeting practices are original teaching material. They should be adapted to the project’s actual authority, contracts, risks and acceptance requirements.

1. University of Essex — Dependency management. Institutional guidance distinguishing project, programme and external dependencies.
2. Microsoft — Link tasks in a project. Timing meanings of finish-to-start, start-to-start, finish-to-finish and start-to-finish relationships.
3. NASA Systems Engineering Handbook — Interface Management. Engineering guidance on interfaces, responsibilities, compatibility and controlled changes; not a mandatory framework for every project.
4. United States Government Accountability Office — Schedule Assessment Guide, overview. The role of reliable integrated schedules in evaluating timing and change. The worked example here is not a GAO case study.
5. NASA Systems Engineering Handbook — Configuration Management. Identification, baselines, changes, status and verification across product configurations.

Continue through the series with How Project Management Works for the whole delivery system, Project Schedule Management for timing and forecasts, and Project Governance for the authority that resolves consequential trade-offs.