There are basic reasons for creating dependencies among project activities

Every project has dependencies, which Max Wideman’s Glossary defines as the “relationships between products or tasks”, i.e. tasks that require input from other tasks to be completed, or activities that can’t start until a previous activity is done. There are often several sequences to a task, and they’re all dependent on each other. The scope of a project requires these tasks to be completed in order.

Why do we need project dependencies?

Setting out the project’s dependencies is crucial to its overall success. A project manager needs to:

• Lay out the sequences of tasks within the project plan.
• Calculate the tasks’ critical paths, i.e. how long each one is going to take.
• Identify the necessary resources to complete the tasks, as well as potential scheduling issues.
• Monitor and manage tasks as part of the overall project plan.
• Identify and action any opportunities to accelerate the project’s task schedule.

Examples of dependencies in project management

Let’s say you’re doing a construction project and have to build, plaster and paint a wall. The plastering can’t start until the wall has been built, and the necessary pipes and wiring have been fitted. The wall can’t be decorated until the plastering has been done, including around the pipes and wiring.

Some dependencies are external, rather than internal. In the previous example, the construction company building a wall may rely on third-party suppliers for building materials. Before they can even start building, they’ll also need licenses and planning permission.

Project dependency types

There are four types of dependencies in project management which define the relationships between tasks:

Finish-to-Start

– the first task needs to be completed before the second task can start, as per the example above.

Finish-to-Finish

– the second task can’t be completed until the first task has been done. For example, wires can’t be fitted into the wall until they’ve been inspected.

Start-to-Start

– the following task can’t commence until the first task has started. For example, a concrete floor can’t start to be levelled until the concrete has started pouring into the designated space.

Start-to-Finish

– the first task has to start before the second task can be completed. For example, a new software installation has to start before the old installation can be stopped.

Project dependency categories

As well as the types of dependencies, there are also dependency categories. These are logical, preference and resource-based:

Logical

dependencies, which are fundamental requirements.

Preference

dependencies, which have several schedule options but are based on the preferred path.

Resource-based

dependencies, which could be completed more quickly if additional resources were available.

Hard Logic vs Discretionary dependencies

Some project dependencies are mandatory, also known as Hard Logic dependencies, i.e. they‘re contractually or legally required as part of the project plan. Discretionary dependencies show there’s more than one path in a task or activity’s sequence. In that case, the team chooses their preferred order, usually based on experience.

How to manage project dependencies

Dependencies are often shown as Gantt charts, which can help:

• Track the time a project is taking to complete
• Decide and allocate resources
• Order the tasks
• Aid the management of dependencies between tasks.

Other tools include a Logic Network that shows the sequence of tasks or activities that logically come before or after a different activity or task. A PERT chart – the Program Evaluation and Review Technique – is useful for analysing tasks involved in a project. It lays out the minimum time needed to complete the project, showing a hierarchical breakdown of the project requirements.

Other diagrams that are particularly useful within the project plan for easy referencing by team members are:

• Cause and Effect diagrams
• Flow and control charts
• Histograms
• Scatter diagrams
• Pareto Charts and Pareto Analysis.

Managing dependencies within a project will help both the project manager and team work and manage tasks in their best possible order. This helps ensure a project is completed on time, if not ahead of time.

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.

In this article:

• Project Dependency: A Definition
  • What is a project dependency?
• Dependencies for Scheduling
• Project Dependencies Matrix
• Upstream and Downstream Dependencies
• Project Constraints
  • What is a project constraint?
• Types of Project Constraint
• 5 Steps for Identifying Project Dependencies and Constraints
  • Step 1: Create a Log of All the Project Dependencies
  • Step 2: Create a Log of All the Project Constraints
  • Step 3: Ensure the Major Dependencies and Constraints are in Your Project Initiation Document
  • Step 4: Ensure the Major Dependencies and Constraints are in Your Risk Log
  • Step 5: Agree How You Are Going to Monitor the Dependencies and Constraints
• What next?

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 typeDescriptionFinish to Start (FS)The most common type of dependency. Task A finishes, then Task B can startStart to Start (SS)Both tasks have to start at the same timeFinish to Finish (FF)Both tasks have to finish at the same timeStart 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.

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

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

Four typical elements of project constraints in the iron triangle. You can include more constraints than fit into these categories, but this is a good starting model.

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.

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?

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.

Tip: Sometimes meetings aren’t practical. Find out how to communicate with your team and colleagues when you don’t have time for meetings.

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.

What are the 4 types of dependencies?

Why are dependencies important in project management?

What are the dependency relationships between project activities?

What are the dependencies of a project?