Dependencies: What They Are and How They Affect Project Management
Imagine that you’re part of a complicated project. It has many moving pieces and collaborators scattered throughout multiple teams. It’s just one of the many things you’re working on, and there’s a big task in it that’s been looming over you all week. But you get a fresh cup of coffee, crack your knuckles, and sit down to start working on it. Only to find out that you can’t start. Maybe you’re missing work from someone else, or another task that you’re waiting on hasn’t even been started. You’ve just run into the first of your project’s many dependencies.
An unexpected dependency can bring a project to a grinding halt. But don’t worry. Here’s our guide to dependencies, their different forms, and what you can do to manage them.
What are dependencies?
Dependencies in project management are relationships between multiple tasks. Surfacing a dependency between two tasks is a way of communicating that the completion of one task relies on the other. By identifying them early, you can be sure that no one on your team is stuck holding the bag because someone else didn’t realize their work had slowed your whole project to a crawl.
Think about it this way. Imagine that your project is building a birdhouse. Your project has multiple tasks, like acquiring building supplies, gathering your tools, putting the house together, and painting it. In this project, each task depends on the others before it. Can you paint your birdhouse before it’s built? Can you build it without supplies?
Seems obvious? Maybe not, but remember that the dependencies in this example are all just one type. There are actually multiple categories of dependencies. Knowing what those categories are can make the difference between crushing a project, and despairing over a bunch of incomplete tasks at 5:30 on a Friday. AM or PM? You tell us.
The different types of dependencies
A dependency links a pair of tasks when one can’t progress without the other. But that exact relationship can vary depending on the nature of these tasks. Other elements can come into play, too, like resources and preferences. Below are some examples of dependencies and how they’re differentiated.
Start and finish dependencies
One way dependencies are categorized is with a “start” and “finish” dichotomy. Imagine two tasks, task 1 and task 2, with the latter depending on the former. Each one has its own start and finish, which can interact in one of four ways.
Finish-to-start
This is the most obvious type of dependency, outlined in the birdhouse example. If the dependency between task 2 and task 1 is finish-to-start, it means task 1 has to be completed before the work on task 2 can begin.
Start-to-start
In this dependency, work cannot begin on task 2 until work has started on task 1. Completion of task 1 isn’te necessary.
Finish-to-finish
Task 2 can be started without even having to look at task 1, but it can’t be completed until task 1 is.
Start-to-finish
This is a rarer type of dependency. Work on task 2 cannot be completed until work on task 1 starts.
These dependencies can exist between tasks handled by the same individual, multiple individuals, even multiple teams and departments.
Cause, resource, and preferential
Another way you can differentiate between dependencies is by determining what they originate from. That can be due to constraints, an element inherent to the task itself, or best practices.
Causal dependencies: Think “cause and effect.” You can’t start writing a blog post before you’ve figured out your topic, or start fixing a bug before it’s been reported. These relationships are inevitable, and core to the task at hand.
Resource dependencies: While causal dependencies are simple and inevitable, resource-based dependencies are more malleable; they can be worked around. If you only have one backend developer, all backend tasks will be limited by their bandwidth. That means completion of certain tasks can become dependent on that one developer having more bandwidth.
Preferential dependencies: A preferential dependency isn’t as immutable as a causal one. Often, preferential dependencies are rooted in conventional wisdom, best practices, or simply force of habit. If you only send your newsletters on Tuesdays, the “send newsletter” task is dependent on the day of the week. But it isn’t inherent to the task; it’s just generally accepted as a good rule of thumb.
The outside-inside dependency grid
Another dimension used to differentiate between dependencies is across the “in-out” axis, for both the project itself and the company at large. This helps determine which dependencies you can control, which you can eliminate, and which ones you simply have to deal with.
A dependency can be any combination of “in” and “out,” as shown in the table above. Here’s a quick breakdown:
Company In and Project In
These dependencies are both within the project itself and the company. Tasks that have to happen sequentially within the same project are an example of these dependencies.
Company In and Project Out
Some tasks depend on work happening in other projects within the company. This is especially true when you’re collaborating with other departments.
Company Out and Project In
Usually, this will happen when you’re working with third parties on in-project tasks. Work done by freelancers, agencies, and consultants falls in this category.
Company Out and Project Out
These are the dependencies you have little control over. Some aspect of your project depends on an external group, whether that’s, say, a governmental agency, another company, or an investor.
How to manage dependencies
It’s simply not possible to avoid all dependencies. Even if you stubbornly refused to collaborate with anyone else, your own work would be crisscrossed by these complicated relationships. However, even if you can’t eliminate dependencies, you can make sure they don’t keep you from delivering on your projects. Here are a few ways that project managers — and other collaborators — can manage dependencies throughout their project:
Build a roadmap
These are widely used by product and software teams, but everyone can benefit from a roadmap. Roadmaps represent key initiatives that your team will tackle, usually over a pre-determined period of time, like a fiscal year. With a roadmap, you can establish dependencies before any work begins.
Keep stakeholders informed
It’s tough to know exactly what each team is up to. If you’re frequently collaborating with other teams, you need to keep stakeholders from other teams involved. Their different perspectives can help you spot dependencies you’d otherwise miss.
Think outside the box
Before tackling your next project, bring in the project team. Set up a brainstorming session where you ask them to come up with every possible dependency they can think of. Encourage them to be creative. You might be surprised by what they come up with.
Run retrospectives
If you’ve had a project go a bit haywire because of unexpected dependencies, you need to take the time to look back and figure out what happened. By running regular retrospectives, you can iterate on your team’s processes and get better at spotting potential problems.
Use a work management tool
Many work management tools, like Asana, Wrike, and Trello, have built-in features for tracking project dependencies. For instance, Asana lets you build these relationships right into its tasks, so you always know exactly what to expect.
15 dependency examples
Most projects have dependencies, since you usually need to complete essential tasks in a particular order. Here are some examples of projects where they can happen.
Design
When working with designers, here are some examples of dependencies you’ll have to watch out for.
Work on a new design can only start with a complete brief.
Reviewing preliminary designs can only happen when all stakeholders have given their input.
Designs can only be finalized when size and resolution requirements are shared with designers.
Blogs
Managing a blog comes with its own dependencies.
Editors can only start their work when a first draft comes in.
Writers can only begin their drafts when an editor plans out their editorial calendar.
Reworking existing blog posts can only happen when there’s a good baseline of content to work from.
Software development
Dependencies are particularly important in software development.
New code can only be added to a project after it’s been reviewed by a senior developer.
Some parts of a piece of software can only be worked on after other parts have been made stable by other developers.
A new feature can only be tested and launched when work on all the components is completed.
Marketing campaigns
Even though they’re not software projects, marketing campaigns have their own dependencies.
Work on the campaign can’t start until requirements are clearly established.
Design work often depends on copywriting being done first.
Campaigns can’t launch until all materials, like copy and designs, are completed.
Customer support
Customer support workflows can often involve interdisciplinary work, and that means you’ll deal with dependencies.
Some support tickets require intervention from a supervisor, meaning customer support agents can only work on them after that happens.
More technical support tickets can only be resolved when a developer has had a chance to look at the issue.
Tickets where threats of legal action have been made might need work from official counsel before a support agent can close them.
Dependencies and the Gantt chart
The Gantt chart looks a bit like a horizontal bar graph. Time is tracked on the horizontal axis while the vertical axis lists all the work that needs to happen to complete a project. Each of the bars represents the time an individual task will take to complete. They’re stacked so you can quickly recognize which tasks need to be tackled before work on another. The bars can also overlap slightly, showing that work on one task can begin even though a previous task isn’t completed — often representing a start-to-start dependency.
Gantt charts are built to track the time-related dependencies between tasks. This way, no matter where you are in your project, you can see how your work affects what other collaborators are up to. Because they’re so simple, they can easily represent any kind of dependency visually, making them easier to recognize and understand. Many work management tools, like Basecamp, Jira, and Trello, have built-in Gantt chart features.
Want to learn more about Gantt charts? Check out our beginner’s guide here.
Can I depend on you?
Dependencies should rarely surprise you. By taking the time to brainstorm and discuss your project with stakeholders and collaborators, you should be able to identify most of them. There’s nothing worse than getting ready to start a task only to realize you need to wait on someone else’s work. But with a keen eye for these dependencies, and workflow management software to track them across tools, you can spend less time worrying about them and focus on getting things done.