The Ultimate Guide to Project Dependencies and Constraints
No project happens in a vacuum.
Projects are constrained by and are dependent on the environment in which they are taking place – both the corporate environment and the wider environment outside the company.
In this article we’ll look at everything you need to know about project dependencies and constraints.
Project Dependency: A Definition
Let’s start with a definition.
What is a project dependency?
Dependency: The relationship that defines the order in which tasks are carried out. Task B is dependent on Task A if the start or finish date of Task A must be reached before Task B can be started.
Here are some examples:
- If you are hosting a meeting, you have to have the meeting before you can send out the minutes. Sending out the minutes has a dependency on having the meeting.
- If you are building a house, you have to build the walls before you can put the roof on. Installing the roof is dependent on the walls being built.
Dependencies should be listed in your project management documentation so they are transparent and everyone has the same information.
Dependencies for Scheduling
You need to understand the dependencies between tasks before you can prepare a project schedule. The dependencies help you work out the order of the tasks.
In most project management software, there are four ways to link tasks together to build a schedule. These are:
| Dependency type | Description |
| Finish to Start (FS) | The most common type of dependency. Task A finishes, then Task B can start |
| Start to Start (SS) | Both tasks have to start at the same time |
| Finish to Finish (FF) | Both tasks have to finish at the same time |
| Start to Finish (SF) | The most uncommon type of scheduling dependency. Task B cannot finish until Task A has started |
The task that comes before is the Predecessor task.
The task that comes after is the Successor task.
And yes, you can have multiple predecessors for one successor task and vice versa.
Enter the dependent tasks on your Gantt chart. Depending on the software you are using, they’ll normally show up as lines between the task bars so you can visually see which tasks link to others. If you use a Kanban board or similar for scheduling, you’ll be able to enter dependency dates instead.
Once you’ve entered all the tasks and the dependencies that link them, you’ll be able to see the project’s critical path (the longest chain of sequential activities i.e. the shortest possible path through the entire project getting all the work done). This determines the end date of the project if you are using predictive methods.
Looking for a robust way to track project dependencies and everything else that goes on during a project? Get the project workbook I use on my projects. It includes a dependency log as well as ways to track risks, issues, actions and more.
Project Dependencies Matrix
Dependencies can occur inside and outside the project’s sphere of influence, and inside and outside the company.
The following table shows the four different types of dependency when you categorize them this way, and some examples.
In-Company, In-Project: These relate to sequential project tasks. They happen within the ‘walls’ of the company, and within the framework of the project. There’s a logical relationship to these.
In-Company, Out-of-Project: These are dependencies that affect things within your company but outside of your project, such as tasks being done by other departments as part of other projects. You get a lot of these within a program, because the different projects will rely on each other for certain elements. They could also be external events, such as the release of the annual report, if that has an impact on your project. For example, on one project I worked on, the annual report production was a dependency as it affected how much resource time we could get from the PR and Internal Comms teams.
Out-of-Company, In-Project: Tasks that are carried out for your project but by resources that are outside of your company. That could be work done by a supplier.
Out-of-Company, Out-of-Project: You don’t often get these dependencies on projects as if it’s outside the scope of your project you wouldn’t normally have to deal with it. However, having them on the dependency matrix finishes it off nicely!
An example would be activities carried out by a third party that need to be reviewed by someone outside the project before you could carry on with whatever it is you are doing.
Upstream and Downstream Dependencies
Dependencies can also be ‘upstream’ or ‘downstream’. These terms are used often when describing other projects.
An upstream dependency is one where something must happen before your project can start something else i.e. you are waiting for a task to complete before starting work.
Example: “We have an upstream dependency on Claire’s project to complete the infrastructure before our project can use it.”
A downstream dependency is something your project must deliver before something else can start i.e. someone else is waiting for you to complete tasks before they can begin work.
Example: “Claire has a downstream dependency on your work, so let her know when it will be finished as she needs to plan her project.”
Project Constraints
Constraints are related to dependencies in that project managers often talk about them together because they both affect how we schedule work and plan resources. You’ll often hear about the triple constraint (time, cost and scope), but there are more things that constrain your project such as quality, environmental issues, regulation and more.
What is a project constraint?
Here’s the definition I use of a project constraint:
Constraint: Something that limits your options.
Here are some examples of constraints:
- You have to complete the project within 6 weeks. You have a time constraint of 6 weeks.
- You have to develop the software within brand guidelines. The brand guidelines are a constraint on the creativity of the development team.
- You have access to only three team leaders to help with the project. That’s a constraint on the availability of resources.
- You have to fix a nuclear reactor with only a hairpin and a roll of duct tape. You have a constraint on the available materials.
Constraints are similar to dependencies: they also impact how you can deliver the project. However, constraints are restrictions. They may revolve around a specific date, such as something being delivered at a certain time, but they may not.
Types of Project Constraint
Project constraints could be factors that limit the time, resources or budget available to the project. Despite these, you still have to get the job done. Your challenge as a project manager is to find ways to deliver the project successfully within the constraints of your environment.
Constraints can be anything that affects your ability to have free reign over what you want to do. Technical constraints, for example, will force you to choose certain platforms or tools for the solution instead of having your pick of anything out there. Where there is a ‘constraint date’ (e.g. you have to get something done by a certain time) then make sure that is recorded in your schedule as a fixed milestone. You can add these to your software as ‘must finish by’ dates.
Identifying and assessing dependencies and constraints is a useful activity because many of your project decisions will be based on this information. If a dependency cannot be met, or if a constraint turns out to be too restrictive, this impacts your ability to deliver the project to the original plan.
As project managers it’s often tempting to spend a lot more time on managing risks and issues than dependencies and constraints, but they are just as important and can have a massive impact on your project if you don’t manage them effectively.
So how do you identify the dependencies and constraints for your project?
5 Steps for Identifying Project Dependencies and Constraints
Here is a 5-step approach to identifying and reviewing all the dependencies and constraints on your project. If that sounds daunting, don’t worry. It’s a much faster task than you think.
Step 1: Create a Log of All the Project Dependencies
Now you understand what a dependency is, you can brainstorm and document all the dependencies that have an impact on your project. Set up a dependency/constraint log using an existing template from your PMO or by designing your own.
Remember to include who is responsible for managing the dependency and all the other pertinent information including whether it is an internal or external dependency. If it is an external dependency, you can add a link to where you can find out more information.
This is particularly relevant if the external dependency is another project and you need to remember to regularly catch up with the other project manager to assess the impact on your project.
Note: I wouldn’t add task dependencies to this log. It’s just for stuff happening outside of the project schedule. If your tasks link together, that’s reflected on your schedule so you don’t need to note it down anywhere else.f
Step 2: Create a Log of All the Project Constraints
Brainstorm and document all the constraints that have an impact on your project.
You can use the same document as you used to record the dependencies, although if you feel it is more appropriate to create a separate log – for example, if you have a lot of constraints – then feel free to create another document.
Step 3: Ensure the Major Dependencies and Constraints are in Your Project Initiation Document
Transfer the major dependencies and constraints to your Project Initiation Document (PID). The purpose of doing this is to have all the key information about the project in one place – the PID (or Project Charter).
If you don’t have very many dependencies or constraints you could include them all in the PID. If your log has lots of entries, consider which ones are the highest priority and only include them.
The audience for your PID is your Project Sponsor, and it is unlikely that he or she would want to read every single low-level dependency. However, this does not excuse you, as the project manager, from monitoring them all.
Have a discussion with your Sponsor and ensure that they understand the dependencies and constraints and what could happen if a dependency cannot be met or a constraint turns out to be too restrictive.
You need to ensure they have a full understanding of the project environment, and dependencies and constraints are two key elements of that.
Step 4: Ensure the Major Dependencies and Constraints are in Your Risk Log
Read through your lists. Do any of these dependencies sound like project risks to you? Outside-the-project dependencies are often contenders for being transferred to the project risk log, especially if you are reliant on third parties to deliver certain items.
Constraints such as limited access to people for user testing are also potential risks, so make sure they are recorded as well. In fact, if you know already that the constraint is going to be a problem, record it on your issue log.
Read next: Tips for Risk and Issue Reporting
Step 5: Agree How You Are Going to Monitor the Dependencies and Constraints
Having a log and an up-to-date PID or Project Charter is great, but your project will not be better just through doing that. You have to work out a way to regularly assess the dependencies and constraints so that you can manage their impact on the successful delivery of your project.
If you have external dependencies on other projects, talk to the project managers concerned and agree how to let each other know when things change.
Reporting by exception is a solid principle that you can use here: only report to the other person when something is not going to plan. If your project is reliant on another project to complete a certain task by a certain date and it looks as if that will be achieved, the other project manager will only report to you if it now looks like it will not be achieved.
For extra comfort, you may want to schedule regular meetings with the project managers concerned to ensure that you understand how their projects are progressing and any changes this has for the way in which your project will be delivered.
A simple way to manage internal dependencies is to remember to discuss them in your project team meetings. The more aware the project team members are about the impact of their tasks on other people’s work, the more likely they are to flag when there is going to be a problem. But if in doubt, ask them, and make this is part of your standing agenda template in your regular meetings. During these meetings you can also update the log to include any new dependencies or constraints that emerge as the project progresses.
Of course, for those dependencies and constraints that have made it on to the risk log, your risk management processes from the basis of how you will review and manage them.
This short video provides some more context for project dependencies:
Easy enough, isn’t it?
What next?
Once you’ve mastered dependencies and constraints, it’s time to polish up how you manage project actions.
You’ll also want to look at project assumptions because they will have an impact on your project plan and schedule.
Pin for later reading:
