Today, we define what a project management dependency is, and how you manage it properly. This is probably one of the top three project management skills: managing dependencies properly can make or break your projects. We will see some traditional properties of dependencies, but most importantly see how you can manage dependencies concretely.
Hello! At the time of writing this article in 2023, I am a Senior Technical Program Manager for Amazon Web Services. I base this article on my experience and on public material from the Project Management Institute. However, what you see here are exclusively my opinions and not Amazon’s.
Project Management Dependency: Formal Definition
Let’s start with a formal, traditional, and PMI-approved definition of project management dependency:
A project management dependency is a resource that must be available or a task that must be done to unblock other activities. In its simplest form, it is a task that needs to be completed before another task can start.
For example, if you are building a skyscraper, you need to build the foundations before you can start building the various floors. Building the floors thus depends on creating the foundations, or has a dependency on the foundations. It is dependent on them.
The term “project management dependency” can be used fluidly to define the items at both sides of the dependent relationship. You can say “building the floors has a dependency on the foundations”, which means the floors needs the foundations to be completed first. You can also say “building the foundations is a dependency for the foundations”, where you mean the same thing. The “dependency” refers to the interconnected relationship, but not necessarily to the direction of that dependency.
A project management dependency is not only a task that needs to be competed before another. You may need a specialist to do some particular work: if that specialist is hard to find or hire, then the work to be done will depend on finding the specialist first.
Types of Project Management Dependencies – according to PMI
The Project Management Body of Knowledge (PMBOK) guide, curated by the PMI, defines four different flavors of project management dependencies.
A Finish-to-Start (FS) project management dependency is the most common and classic. The first task needs to be finished before the second can start. This is what you see in most cases, and it is our previous example “building the foundations must finish before building the floors can start”. Even dependency on a resource, like finding and hiring the specialist, is this type of relationship. You can manage even large projects, and encounter only this type of dependency.
The second type is Start-to-Start (SS), where the second task cannot start until the first has started, even if it has not finished yet. In the case of your building, imagine you can paint only after the doors are installed. You don’t need to wait for all the doors in the building to be installed before you can start painting, but only the doors in the area you want to paint. Therefore, painting can start when doors installation start, maybe with a few days of lag (if they are two days, you would mark it with “SS+2”).
The Finish-to-Finish (FF) dependency is somewhat tricky, the second task cannot finish until the first one has finished, but can start before that. Let’s say you have a software to install on a server, and that requires some network connectivity and cables to be prepared. You can start to configure your software, but in order to finish the configuration you will need the cabling to be completed. Therefore, while you can start the configuration, you need to wait for the cabling to be finished in order to finish the configuration as well.
Start-to-Finish (SF) project management dependency is the trickiest one, even counterintuitive at first. Here, the first task cannot finish until the second one starts. It is thus the predecessor to have a dependency on the successor. How is this possible? Think about the shift of security guards. When a guard finishes the shift, he should leave, but cannot leave the guardhouse unattended. So, he needs to wait for the next guard on-shift to come and start his shift. Only when the second guard starts the shift, the first can leave.
Definition are great, but what is a project management dependency in the real world? Keep reading to find it out.
Project Management Dependency in the Real World
All you read from the PMBOK guide or PMI.org is technically correct and literally by-the-book. However, the reality of a project management dependency is often nastier. PMI is approaching dependencies purely with a task-oriented mindset: “activity A has a FS dependency on activity B”. Who owns those activities will change the nature of the dependency. Let me explain with two examples.
Imagine you are an IT technician and needs to configure server A and B. Since server B communicates with server A, you need to configure server A first. Technically, configuring server B has a dependency on configuring server A. Now, imagine you want to build a house on a new plot of land, but before you can start you need to get permits from the government. Starting to build the house has a dependency on obtaining the permits.
Which kind of dependency has the higher risk of jeopardizing your plans? I think we can all imagine it is getting the permits. This is because in the first case it is the same person to do both tasks, and since she cares to succeed she will configure server A to unblock server B. In the second case, permits are produced by a third party. Even worse, the government is not likely to care much if you build that house or not. If they delay the decision, there is probably nothing you can do to put pressure on them.
So, do not focus only on the project management dependency that you have. Consider who owns delivering on those dependencies. To bring more clarity, we introduce the concept of external dependency (short for external project management dependency).
An external dependency is everything that is outside the control of the person who has the resources to fund the project. We call this person the sponsor. If the sponsor needs a software team to create some business logic, but hires that software team with the project’s money, then he is owning the team. That is not an external dependency. If instead they need input from teams outside of the project, or not funded by the project, then it is an external dependency.
As you can see, an external dependency is not necessarily coming from a third-party or external entity. In large companies, most of external dependencies are still within the company, but outside project’s funding.
How to Manage a Project Management Dependency
Best Strategy: Have No Dependency
The best approach is to have no project management dependency in the first place. Of course, tasks will always depend on one another, but you should strive to remove external dependencies altogether. Doing that simply means bringing the control of all the work needed to accomplish the project under the control of the sponsor.
Try to fund everything from the project, and account for that when doing the budgeting. For smaller projects, this is often possible and desirable. The more the project spans across different parts of the company and involves various stakeholders, the harder it gets.
Even for larger projects where you will need to have some dependencies, make a conscious effort to review all the dependencies you have on other teams and remove most. In most projects, you can remove most of the dependencies and bring most of the project under a single accountability bucket.
Once you have done this, you will have a project that has only the minimum amount of project management dependencies. In this state, you can move to the next strategy.
Find a Common Ground with the Owners of the Project Management Dependency
By definition, a project management dependency (when external) is something that is owned by another team, over which you have no direct control over, but that you still need to get done. The challenge is, the other team will have its own priorities, and your initiative may not be part of them.
What I find effective here is to find common ground, a shared system of beliefs and understanding. Ideally, a common North Star goal. You are doing this project because you want to increase customer engagement for the company, they are working on other initiatives to increase profitability and reduce lead time. Maybe, the company prioritizes profitability, then customer engagement, and then lead time. So, your initiative may sit between the two other priorities of the external team.
The idea here is simple: you won’t get it your way all the time. Sometimes, external teams will not deliver on your project management dependency because they need to do something else. That is okay, as long as the true objectives and values of the company are prioritized.
This is why it is important to have a shared understanding of what the company stands for, what are the priorities, and how they rank between each other. If you have this, you will be able to make the best tradeoffs even with other teams.
Escalate the Project Management Dependency to a Decision Maker
A project management dependency can see in different ways at different levels. At team level, rely on an another team is an external dependency. However, if both teams are under the same director, for that director it is not an external dependency: he owns both sides. To make this to the extreme, all the dependencies that do not rely on government are not external in the eyes of the CEO, that runs the entire company.
This is even true with external suppliers, because you pay them and thus you can control them and put pressure on them.
When managing a project management dependency, the first step should always be to see if it can be eliminated. If it cannot, spend some time to identify the shared system of beliefs between you and your external dependency. This will help you to manage most dependencies, but there will still be times when you cannot agree on a path forward on the other team.
If you can’t find agreement, then escalate, quickly. Escalation, raising the issue to management, should be done on both ends, providing the case “why are disagreeing because of this and that”. If managers can’t solve that either, the issue is escalated again, until it reaches a single decision maker that makes the call. Plain and simple.
Project Management Dependency in Summary
Let’s wrap things up with a TL;DR. A project management dependency is a task depending on another task to be done. Dependencies are normal in all projects, but you should be especially careful when you have tasks that depend on people or teams you have no control over. When this happens, try to find a way to restructure the project so you own most of the tasks.
When this is not possible, ensure you share the same beliefs and ultimately want the same thing for the company as your external dependencies. If this is not possible, escalate so that a decision maker owning both sides can make the call. Escalation can be challenging and burn bridges if not done properly, this is why I recommend using referent power to make your point. But in general, escalation is a soft skill to learn.
