Looking for project management templates?

The Ultimate Guide to Project Dependencies and Constraints

Dependencies and constraintsNo 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.

Tracking your project dependencies is easy with my free dependency log. Scroll to the bottom and pop your email in the box to download it today.

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 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 typeDescription
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.

The task that comes after is the Successor.

And yes, you can have multiple predecessors for one successor task and vice versa.

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.

RAID template
This is what a project workbook looks like (one tab, anyway). Other worksheets cover the full elements of the RAID template

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 categorise them this way, and some examples.

Different types of project dependencies
Different types of project dependencies

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.

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 programme, because the different projects will rely on each other for certain elements.

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.

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 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.

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.

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.

Discussions around dependencies and constraints form a key part of your stakeholder engagement plans. You can use these discussions to set expectations about what your project can realistically achieve.

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?

Identifying project dependencies and constraints

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.

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 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 standing agenda item 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? Don’t forget to download your free dependency log by entering your email in the box at the bottom of this article.

Pin it for later:

project dependencies and constraints

Get the Dependency Log

Manage your project dependencies with this template (Excel). You'll also get updates from

You can read my privacy policy here.

On the next screen you'll also have the option to subscribe to the newsletter with weekly(ish) project management tips. Unsubscribe at any time. Powered by ConvertKit

About Elizabeth Harrin

Elizabeth HarrinElizabeth Harrin FAPM is a professional project manager and award-winning blogger behind A Girl's Guide To Project Management. She's passionate about demystifying project management and making tools and techniques work in the real world. She's also the author of several books including the PMI bestseller, Collaboration Tools for Project Managers.
Elizabeth lives in the UK with her family. She uses her organisation and project management skills at home, and also to help other bloggers at Totally Organised Blogging.


  1. Confidence says

    12 April, 2017 at 12:16 pm

    If the question ask you to tabulate the various type of time dependencies that one may encounter when using the precedence diagramming techniques.
    are they referring to:
    1. Start – Start
    2. Finish to Finish
    3. Finish – Start
    4. Start – Finish

    • Elizabeth Harrin says

      23 August, 2016 at 4:10 pm

      It depends what you have in it. This template is versatile enough to log all dependencies. Generally I find most of my dependencies are schedule related on my projects, but sometimes they are scope-related. I wouldn’t use it to “control risks” as I’d have my risk management plan in my risk log, although a dependency could (would) create a risk. A dependency log is one of the tools you can use to control your project across all areas.

  2. Rene Hug says

    21 June, 2016 at 4:11 pm

    Like your visualization. I usually don’t list project inherent dependencies (sequential work) but rather those where I cannot take any influence myself. Depending on the nature of dependency it actually becomes as risk to the project.

    • Elizabeth Harrin says

      22 June, 2016 at 8:23 pm

      Rene, thanks for your comment. A lot of dependencies find themselves on the risk log – where you can’t control it, you’ve got to record it somewhere for transparency and monitoring.

  3. Praveen Malik says

    13 January, 2016 at 8:51 am

    Hi Elizabeth,

    I like the way you have written this article. Especially the In/Out table you have made – interesting and innovative. I like to add one point here. A dependency could be on FS relationship but it can also be on other relationships like SS, FF and SF.

    Praveen Malik

  4. Dave Gordon says

    17 October, 2014 at 9:09 pm

    Excellent explanation, Elizabeth. And I really like the new layout – I don’t know how you find the time to do all of this and still keep up with a toddler and a crawler!

    • Elizabeth says

      23 October, 2014 at 7:14 pm

      Thanks, Dave! I’m still tweaking the layout so right now we are back to the old layout. But I’ll get there eventually and get that new design out there! I have someone doing the coding for me – that’s the secret!


The Shop

Check out my ebooks, template packs and other resources to help you get started and keep going on your projects
Shop now