Project dependencies are the main reason a confident project plan turns into an awkward status meeting. Your schedule says the launch is on the 14th of March. Behind that date sit a supplier delivery, a security review, a data clean-up and an approval, and none of them belong to your team. Each one came with a friendly promise. Each promise is now a date in your plan, and the plan treats it like a fact.
That gap between a promise and a fact is what we call the dependency promise problem. In this guide, you’ll learn what project dependencies are, why dates built on other people’s work keep slipping, how to spot trouble early and how to turn vague promises into commitments you can actually manage. We’ll also look at how this plays out for project teams in Sydney, Melbourne, Brisbane, Perth, Canberra and Adelaide, and which courses build the skills to handle it.
What Are Project Dependencies?
Project dependencies are relationships between tasks, deliverables or people where one thing can’t start or finish until another has happened. If task B needs the output of task A, then B depends on A. Simple enough on paper. The trouble starts when A belongs to someone else.
Every project has them. Painters can’t paint before the plasterer finishes. A developer can’t test an integration until the other system is available. A marketing campaign can’t launch until legal approves the copy. Project dependencies are how schedules actually work, which is why understanding them is a core skill in any project management course.
The important question isn’t whether you have dependencies. It’s how many of them sit outside your control, and what you’re doing about those.
The Dependency Promise Problem Explained
Here’s how it usually happens. In a planning meeting, you ask another team when they can deliver. They say “should be done by the 20th”. It sounds helpful, so you type 20th into the schedule. From that moment, a hopeful estimate has quietly become a commitment in your plan.
Nobody lied. But look at what’s missing. The other team hasn’t agreed to the date in any formal sense. Their manager may not know about it. They have their own priorities, and yours is one of many. And you have no visibility into whether they’re on track until the date arrives.
A promise is a statement of intent. A commitment has an owner, a date, a clear definition of done and a way to check progress. Most project dependencies live in the first category and get managed as though they were in the second.
Why Project Dates Rely on Work Nobody Controls
Dates slip for plenty of reasons, but unmanaged project dependencies sit behind a surprising number of them. Here are the most common culprits.
Other teams have their own priorities
A shared services team supporting ten projects will always favour the most urgent or most senior request. Your task isn’t ignored out of malice. It’s just not their top priority this week.
Suppliers and vendors work to their own schedules
Lead times change. Stock runs short. A vendor’s “two weeks” becomes six once the order is actually in their queue. External project dependencies like these are the hardest to influence because you may have no contract lever beyond a polite email.
Approvals and regulators move at their own pace
Council permits, security reviews, legal sign-off and executive approvals all have processing times you can’t speed up. Public holidays also vary by state and territory, so check the Fair Work Ombudsman calendar when a dependency crosses borders.
Shared resources get double-booked
A specialist who is “available from April” may be committed elsewhere by the time April arrives. Resource dependencies are some of the most fragile project dependencies because they rely on someone else’s schedule staying still.
Hidden dependencies surface late
Some dependencies don’t appear on any plan until they cause a problem. A licence renewal, a data format, an environment that needs setting up. If nobody mapped them at the start, you discover them when they stop you.
Optimism gets built in
People tend to underestimate how long things take, a pattern researchers call the planning fallacy. When every dependency owner is a little optimistic, the errors stack up along the schedule.
Dependencies are logged once and never reviewed
Plenty of teams list their project dependencies at kick-off and then never look again. By the time one is at risk, the people who made the original promise have forgotten it, moved on or changed their plans.
Types of Project Dependencies You Need to Track
Project management frameworks usually describe four main types of dependency. Knowing which type you’re dealing with tells you how much room you have to manage it.
| Type | What it means | Example | Who controls it |
| Mandatory (hard logic) | Physically or contractually required order | Foundations must be poured before walls go up | Often the project, sometimes others |
| Discretionary (soft logic) | Preferred order based on good practice | Design review before build starts | The project team |
| External | Depends on something outside the project | Supplier delivery, regulator approval, other team’s output | Someone else |
| Internal | Link between your own project tasks | Testing can’t start until development finishes | The project team |
Dependencies also have relationships, which describe how the timing connects. The four standard ones are finish-to-start (B can’t start until A finishes), start-to-start, finish-to-finish and start-to-finish. Finish-to-start is by far the most common, and it’s usually where the dependency promise problem bites hardest.
Warning Signs Your Project Dates Rest on Shaky Dependencies
Wondering if your schedule has this problem? Watch for these signals:
- Key dates are based on “should be done by” rather than a confirmed commitment.
- Nobody can name the person accountable for each external deliverable.
- Your plan has no confidence level, buffer or range for dates owned by other teams.
- You hear about a delay at the milestone, not a week before it.
- The dependency list was written at kick-off and hasn’t changed since.
- Your team spends status meetings explaining slips caused by “waiting on” someone else.
If three or more sound familiar, your project dependencies are probably carrying more risk than your plan admits.
A Realistic Example: The Go-Live Date That Belonged to Someone Else
Here’s an illustrative scenario. A retail company in Sydney plans to launch a new online booking system on 1 March. The project manager builds a tidy schedule with the launch at the end.
Three project dependencies sit in the middle. The payment provider needs to approve the integration. The internal security team has to complete a review. And another department has to clean up customer data before migration. Each one gave a verbal estimate. Each estimate went straight into the plan as a hard date.
Then reality arrives. The security team is busy with an unrelated incident. The payment provider’s approval queue is longer than expected. The data clean-up slips because two people are on leave over the Christmas and New Year period. None of this is dramatic. But because the dates were promises and not commitments, nobody sees the problem until February.
By then, there’s no float left, the launch moves to April and the project manager is explaining delays in a room where nobody else feels responsible. This is the dependency promise problem in its classic form.
How to Manage Project Dependencies: 8 Practical Steps
1. Identify dependencies early and as a group
Run a short dependency mapping session at the start with everyone who touches the work. Ask a simple question: “What do you need from others, and what do others need from you?” You’ll find things that never appear in a solo planning exercise.
2. Record every one in a dependency register
Create a log with the dependency, the owner, the agreed date, a confidence rating and the date it was last confirmed. This often sits alongside risks, assumptions and issues in a RAID log. If it isn’t written down, it isn’t managed.
3. Turn promises into commitments
For each external dependency, agree on a named owner, a date, a clear definition of done and a checkpoint. A short email confirming those four things is often enough. It changes “should be done by the 20th” into something you can follow up.
4. Use ranges and confidence levels, not single dates
Replace “20 March” with “between 18 and 28 March, 70% confident”. Ranges tell the truth about uncertainty and prevent a single optimistic date from driving the whole plan.
5. Build buffers where dependency risk is highest
Don’t pad every task. Place visible buffers ahead of milestones that rely on external deliverables, so a slip upstream doesn’t automatically become a slip in your go-live.
6. Check in often and set early-warning triggers
Review your project dependencies at least weekly. Agree on triggers, such as “if the draft isn’t in by the 10th, we escalate”. The goal is to hear about trouble when it’s still cheap to fix.
7. Escalate early with a clear ask
Escalation isn’t blame. It’s giving a decision-maker time to act. Bring the dependency, the impact on the date and a specific request, such as extra resource or a change in priority.
8. Reduce the number of dependencies
The best dependency is one you’ve removed. Look for ways to decouple work, run tasks in parallel, use temporary stand-ins while waiting, bring a task in-house or change the sequence so the risky item isn’t on the critical path.
Project Dependencies Checklist Before You Commit to a Date
| Question | Who should answer | When |
| Is every external dependency listed with a named owner? | Project manager | Before baselining the plan |
| Has the owner agreed to the date, not just suggested it? | Dependency owner | At the agreement stage |
| Is there a clear definition of done for the deliverable? | Project manager and owner | At the agreement stage |
| Is the date shown as a range or with a confidence level? | Project manager | During planning |
| Is there a buffer ahead of any milestone that relies on others? | Project manager | During planning |
| Who checks status, and how often? | Project manager | Weekly |
| What is the trigger for escalation, and who receives it? | Sponsor and project manager | Before work starts |
Managing Project Dependencies in Agile and Hybrid Projects
Agile doesn’t make dependencies disappear. It changes how you deal with them. Short timeboxes surface delays earlier, regular planning meetings give owners a natural point to confirm commitments, and prioritisation lets teams protect the date by flexing the scope.
The AgilePM approach, supported by the Agile Business Consortium, fixes time and cost and flexes features using MoSCoW prioritisation. That’s a powerful way to protect a deadline when a dependency slips, because you decide in advance what gets dropped first. You can learn it through our AgilePM Foundation course, then build practical skills with the AgilePM Practitioner course.
For wider professional standards and resources, the Project Management Institute, the Australian Institute of Project Management and the Association for Project Management are all worth exploring.
Skills and Tools That Help You Control Project Dependencies
- Critical path analysis: Shows which dependencies directly drive your end date.
- Gantt charts and network diagrams: Make links between tasks visible to everyone.
- Dependency register or RAID log: Keeps owners, dates and confidence in one place.
- Three-point estimating: Gives a realistic range instead of a single guess.
- Stakeholder engagement: Builds the relationships that turn promises into commitments.
These are the same skills covered across our project management courses, where you can learn to plan, schedule and control work that depends on others.
Project Dependencies Across Australian Cities
Dependencies look different in every market, but the principle is the same everywhere.
- Sydney: Complex technology and finance projects with many vendors and approval layers. See project management courses in Sydney.
- Melbourne: Large healthcare, education and construction projects with multiple stakeholders. See project management courses in Melbourne.
- Brisbane: Infrastructure and growth projects with tight timelines and many contractors. See project management courses in Brisbane.
- Canberra: Government projects with formal approval and procurement processes. See project management courses in Canberra.
- Perth: Resources and engineering work with long supply chains and remote sites. See project management courses in Perth.
- Adelaide: Defence, manufacturing and public sector programs with interlinked deliverables. See project management courses in Adelaide.
Professionals in Hobart and across the rest of Australia can also join through live online or in-house delivery. See all options on our locations page.
Frequently Asked Questions About Project Dependencies
What are project dependencies?
Project dependencies are relationships between tasks or deliverables where one must happen before, or alongside, another. They determine the order of work and heavily influence your schedule.
What are the four types of project dependencies?
The four types are mandatory (hard logic), discretionary (preferred logic), external (outside the project) and internal (within the team’s control). External dependencies are usually the riskiest for dates.
How do you manage project dependencies?
Identify them early, record them in a register, assign owners, agree on dates as commitments, use ranges and buffers, review them weekly and escalate early when something looks at risk.
What is the difference between a dependency and an assumption?
A dependency is something your work relies on. An assumption is something you believe to be true without proof. Many failed plans treat a dependency as an assumption, which is how the dependency promise problem starts.
Which course teaches schedule and dependency management?
Our AgilePM Foundation and AgilePM Practitioner courses cover planning, prioritisation and delivering within fixed timeframes. You can see everything on our courses page or read the FAQs.
Final Thoughts: Turn Promises Into Commitments
Project dependencies aren’t a sign of poor planning. Every real project has them. The problem is treating someone else’s good intentions as a guaranteed date. The projects that stay on track are the ones that make dependencies visible, give them owners, check on them often and plan for the chance that they’ll slip.
Dates rarely slip because people are careless. They slip because nobody was clearly responsible for the work in between.
Ready to build these skills? Explore our project management courses, see where we deliver on our locations page, or contact our team on 1300 649 299 to find the right pathway. You can also read more on our blog or learn about us.