Project dependencies need reasons and release conditions

To tell whether project dependencies are real prerequisites or only preferred sequences, ask what makes the ordering necessary and what evidence would release it. Requirements, limited resources, outside inputs and team preferences explain different constraints. Start/finish links describe their timing. In a hypothetical release, frontend mock work may begin under an agreed interface before the backend is complete. Integration testing still needs a working endpoint and environment. A missing reason calls for investigation, not automatic parallel work.

An arrow can carry an ordering rule without explaining what releases it.

An arrow records order, not its justification

Asana's dependency guide distinguishes logical, resource and preferential dependencies, alongside external dependencies. Those descriptions explain causes or control. Atlassian's scheduling relationships answer a different question: which start or finish must wait?

Finish-to-start (FS) means B cannot start until A finishes. Start-to-start constrains B's start against A's start; finish-to-finish constrains B's finish against A's finish. Start-to-finish means B cannot finish until A starts. These are event restrictions, not instructions that both events happen simultaneously. Microsoft's scheduling documentation makes that distinction explicit and documents FS as Project's default when linking tasks.

Project's default cannot establish that your frontend needs the entire backend finished. The reason still needs checking. Here, a release condition is evidence that the waiting task may start or finish, not approval to ship the whole release.

A revisited schedule is an occasion for that check. Microsoft's Project Online retirement announcement, updated August 24, 2026, specified September 30, 2026 for Project Online only, excluding Project desktop, Project Server and Planner. That announcement does not establish how teams transferred their plans or whether any rationale was lost.

Keeping the plan's sequence in shared state addresses continuity across handoffs. Preserving that sequence does not justify it. For each disputed arrow, the useful question is what would make its ordering change.

Ask what would change the ordering

A preference is an order the team chooses; a prerequisite is a condition the waiting activity actually needs under the current requirements and circumstances. Asana describes preferential dependencies as team-imposed processes that are not necessarily required for completion, and resource dependencies as constraints arising from limited resources.

Apply that distinction narrowly. If two independent reviews share one reviewer, the second review may wait because that person is occupied. A qualified substitute with confirmed availability could change the order. Adding a name to a staffing plan would not establish either qualification or availability.

For a claimed requirement, ask for its source: the actual agreement, policy or technical input. An API approval gate is binding in the hypothetical case below only if the applicable agreement requires approval before implementation. The label alone settles nothing.

Does external mean mandatory?

No. External describes something outside the team's control, not whether its ordering is mandatory. This is a synthesis of Asana's control-based definition and the separate timing definitions above.

Vendor sandbox access can be external and genuinely necessary for a particular integration test. A vendor's preferred meeting order can also be external without being a binding prerequisite. Inspect the obligation or required input before deciding.

Keep reason, location and temporal relationship as separate fields. An internal reviewer can create a resource-driven FS constraint; an external environment can create an input-driven FS constraint. Choosing where the plan lives addresses storage, which cannot decide whether either arrow is justified. That requires looking at the work they connect.

Audit project dependencies in one hypothetical release

Consider a release with API contract approval, backend implementation, frontend mocks, integration testing, vendor sandbox access and reviews sharing one reviewer. This author-constructed audit illustrates assumptions to verify, not engineering rules or measured results.

Hypothetical dependency audit. Each row states what permits the waiting activity to proceed, or what must change before its ordering can be revised.

The second row narrows an oversized task boundary without releasing every frontend activity. The integration wait remains.

Separate satisfying a prerequisite from changing it. Recorded approval satisfies the first row's existing gate. Deciding approval is unnecessary changes the governing constraint and needs separate authorisation. Neither action follows from changing a task's status.

The tempting mistake is to treat permission for mock work as permission for the real test.

Mocks do not release the integration gate

Can frontend work start before the backend is complete?

Conditionally, yes: mock-based UI work may start under an agreed interface if its owner accepts the assumptions and rework risk. Testing the real frontend-backend interaction still requires the actual endpoint and suitable environment.

In this hypothetical release, a mock can return an agreed response so the frontend developer can build an empty state or display a validation message. It cannot establish that the deployed endpoint accepts the intended credentials or returns that response. Those claims require observations of the real interaction.

A proposed evidence path: identify the interface version, record which behavior the mock covers, then check endpoint and sandbox readiness before running the integration test. The distinction between status and evidence that a prerequisite is actually complete matters here: a completed backend ticket is not itself an observation of the interaction the next task needs.

A conservative sequence may be cheaper to coordinate, especially for a small team with a volatile interface. Keeping frontend work behind backend completion may avoid mock maintenance and repeated revisions. An audit can also cost more than it saves on an uncomplicated plan.

I would inspect disputed or high-consequence arrows rather than document every harmless ordering choice. Keep a preference when its owner can explain the tradeoff. Record that reason honestly, then identify who may decide it no longer applies.

Give one person the release decision

What evidence releases an ordering constraint?

Evidence releases the wait when an authorised owner verifies that the required condition is satisfied, or approves a justified change to that constraint. For the sandbox row, that means observed usable access for the intended test, not a promised delivery date.

For project dependency management, I propose attaching this record to disputed task dependencies:

• Exact task pair, constrained start or finish, and internal or external location.
• Reason for the wait, with its agreement, policy, required artifact or capacity evidence.
• Named verifier, observable release condition, and person authorised to change the constraint if different.
• Risk of relaxation and next check, such as an interface revision or reviewer reassignment.

For a resource edge, the next check might confirm a substitute's availability. For an interface edge, a changed response shape should reopen the assumptions supporting mock work. Attach the record during dependency mapping so the next reviewer can find why the arrow remains.

An unknown reason is an unresolved question. Keep the wait under review while someone checks it; do not silently delete it. Extra capacity is no assurance that an order can change, and it cannot by itself waive contractual, legal or safety obligations. Those need review by the relevant authority.

Take one arrow to your next planning review. Ask its owner what would let the waiting task start.

Source notes

All four external source bodies were inspected in captures dated November 6, 2026. They support definitions and the bounded announcement, not evidence that this audit improves delivery speed.

• Asana, “Project dependencies: Types, examples, and how to manage”. Rendered date September 6, 2026. Used for logical, resource, preferential and external descriptions, not its blanket software-package examples or benefit claims.
• Atlassian, “Project dependencies”. Undated. Used for start/finish relationship definitions, not claims about delivery outcomes.
• Microsoft Support, “How Project schedules tasks: Behind the scenes”. Undated. Used for precise event restrictions and the documented default FS link.
• Microsoft, “Microsoft Project Online is retiring: What you need to know”. Published September 5, 2025; updated August 24, 2026. Announcement scope only, not independent service-availability testing or migration evidence.