A Guide to Dependencies, Constraints and Assumptions (Part 1): Project Dependencies

In this blog series, we’ll take a closer look at the three factors that are the keys to a successful and timely project delivery. Projects are a risky business because their successful implementation depends on so many internal and external factors. Planning a project is challenging, because you have to consider project dependencies, constraints and assumptions. In this first part of the series, we’ll concentrate on explaining the different types of project dependencies and their relationships to each other.

What are project dependencies?

(Source: InLoox Project Management Glossary)

So in short, dependencies define in which order project tasks and activities should be carried out. Why is this so important? Let’s use a simple example to illustrate it: Imagine you’re building a house and start with building the roof, then you build the walls, and only then you start with the foundation. That doesn’t sound logical, does it? The same goes for projects, as every project has a logical sequence of tasks. Some of these tasks can be done simultaneously, while others depend on predecessor tasks to finish before you can start them. The difficulty of accurately determining dependencies is that they could occur between tasks of the same projects, but a task of one project could also be dependent on a task of another project. Furthermore, a task can be preceded or succeeded by multiple tasks. 

Mandatory vs. discretionary dependencies

Project dependencies can be mandatory or discretionary. Mandatory dependencies are activities that must be carried out at a specific time, either because the client requires it, legal regulations, or because it would make no sense to carry them out at any other time (see the house example).

Discretionary dependencies are not defined by these requirements and are more of a recommendation. The project team can decide themselves on when they would like to finish the task or the activity, based on their experience and best practice. Discretionary allow the team much more flexibility to plan the schedule according to their needs and capacity.

Internal vs. external dependencies

Internal dependencies exist between two activities within the project, thus the project team can control the dependency completely and is not dependent on any outside sources.

External dependencies are relationships between project activities and activities outside of the project, i.e. activities over which the project team has no control over, but which still have to be considered in the project schedule.  

How to plan and manage dependencies?

1. Determine whether the dependency is between tasks within the project or outside of it.
2. List and sort all tasks and activities and determine their dependency to each other.
3. Determine the critical path, i.e. the sequence of tasks that has to be completed before the project can be finished.
4. Visualize dependencies and the critical path in a network diagram such as a Gantt chart.
5. Regularly review your project schedule and make adjustments when necessary. 

Gantt chart with dependencies in InLoox 9 for Outlook 

The 4 dependency relationships 

End-to-Start

The most common type of dependency, the End-to-Start relationship is saying that the predecessor task must finish before the successor task can start. So if we take the home building example, this means that you will need to buy land first, before you can start building a house. 

Start-to-Start

Start-to-Start dependencies state that the predecessor task must start before successor can start. The tasks don’t have to start simultaneously, the successor task can start any time after the predecessor has started. An example would be: The moment you start cooking the rice, you can start preparing the vegetables.   

End-to-End

End-to-End dependencies say that the predecessor must finish before the successor can finish. The tasks don’t have to finish at the same time, the successor can finish any time after the predecessor has ended. For example, if you didn’t build your house from scratch, but ordered a prefabricated house, some tasks can only be finished after the house was “delivered” (e.g. adding the patio). 

Start-to-End

This scenario almost never happens, but for the sake of completeness, should also be mentioned here. The Start-to-End is saying that the successor task can’t finish before the predecessor task has started. The easiest example here is billing, you can only finish the billing process, after you have started the delivery of your product or service. 

 

What are your tips for managing project dependencies?  Share your experiences with other readers in the comment section.  

 

Coming up: In part 2, we’re going to take a closer look at project constraints and their impact on the project’s implementation, as well as how they differentiate from dependencies.