Project Dependencies Software

What "project dependencies" usually means, and what we built instead

Search for this and most tools show you the same screen: boxes connected by arrows, a critical path drawn in red, a button that recalculates everything when one date slips. ShipSprint doesn't have that screen. Better to say so here than let you find out after you've set up a workspace.

What ShipSprint has instead are three plainer mechanisms aimed at the actual problem underneath "dependencies," which is rarely "draw me the graph" and almost always "stop my team from starting work it can't finish because something upstream isn't ready." A graph answers the first question. It doesn't, on its own, answer the second.

The three mechanisms are WIP limits, a triage inbox, and a wiki that keeps decisions next to the work they affect. None of them draw a picture. All three change what actually happens when work isn't ready, which is the part a picture was never going to fix on its own anyway.

Where this genuinely falls short

If you run construction-style scheduling, dozens of tasks with calculated float, a critical path that shifts automatically when one trade runs long, resource-levelling across a multi-month programme, this isn't that tool, and we'd rather tell you now than have you discover it during a trial. ShipSprint's approach assumes a team small enough that "what's blocking this" fits in a sentence on a wiki page and a tap on a phone, not a formula.

For most software, marketing and operations teams, that assumption holds. Dependencies at that scale are usually two or three things: a decision that hasn't been made, an asset that hasn't arrived, a person who's on someone else's project this week. A chart doesn't fix any of those. A place to write the blocker down, a limit that stops the team from pretending it isn't blocked, and a fast way to flag it when it bites: that fixes all three.

It's also worth naming what a graph tends to cost that rarely shows up in the sales pitch: someone has to build it, and someone has to keep it current as reality moves, or it becomes actively misleading rather than merely unhelpful. A wiki sentence and a WIP limit don't need that upkeep. They're either true right now or they visibly aren't.

A concrete example

Say checkout redesign work can't start until the payments API ships a new endpoint. Nobody draws that as a linked pair of boxes. Instead: the checkout card sits in the triage inbox, not on the board, because the person triaging knows the endpoint isn't ready. The payments team's release page in the wiki carries a sentence, "checkout redesign is waiting on this," with a history of when that sentence was added and by whom.

When the endpoint ships and the pull request merges, GitHub sync closes the payments card. Someone, usually the triage owner, sometimes the wiki page itself, since any sentence there can become a task, pulls the checkout card onto the board. If the checkout team starts anyway, before that happens, the review column's WIP limit stops the work from stacking up past what the team can actually absorb. Three small mechanisms, no chart, and the dependency was never in doubt to anyone who looked. This is the kind of thing teams on ShipSprint mention when asked what actually changed: not a fancier chart, just fewer surprises about what wasn't actually ready.

What this looks like day to day

• A column fills up to its WIP limit and the team stops starting new work in it, instead of quietly exceeding the limit and calling it busy.
• A request that depends on legal sign-off sits in triage, visible to whoever owns triage, instead of landing as an unplanned card on an engineer's board.
• Someone opens the wiki page for a release and reads, in one sentence, what has to ship before this one can.
• A blocked task gets flagged from the phone in one tap, and the right person is pulled in with the task's context already attached. No forwarding a thread.
• A merged pull request closes its card automatically, so a downstream task's "ready" state reflects the code, not someone's memory of the code.
• The owner command center shows which projects are at risk this week, which is often the first place a dependency problem becomes visible to someone who can actually reprioritise.
• A wiki page's history shows exactly when a blocker was noted and when it was resolved, which is more auditable than an arrow that simply disappears from a chart.