Project dependencies are nothing but Schedule dependencies.
I have written this article to discuss different aspects of dependencies in project management. You will find the definition, meaning, and description of dependencies in this post. You will also see explanatory diagrams and small examples of schedule dependencies.
Project dependencies are often misconstrued as assumptions or constraints in project management. But there is a difference between project dependencies, assumptions, constraints, and risks. You will be able to distinguish between these terms by the end of this post.
What Are Project Dependencies – Definition & Meaning
A project dependency is better characterized as schedule or task dependency. It simply means that one task or activity is reliant on another one. Sometime these are (incorrectly) referred to inter-dependencies. Inter-dependencies are between two different projects.
A dependency can be defined between two activities, or between a milestone and an activity.
Project Dependencies Example
What does it mean?
It simply means that B is dependent on A and it would start as soon as A finishes.
I have used Finish to Start relationship in the above example without any lead or lag. But dependencies can be expressed for other project relationships as well – Finish to Finish, Start to Start and Start to Finish.
The above example can be depicted in any one of the following ways.
Bar charts are popularly known as Gantt Charts.
The above figure shows the same dependency as a Project Network Diagram.
You can also represent the above example mathematically.
B(S) = A(F)
The above equation suggests that start of B is equals to finish of A.
Project Management Dependencies Example – A Real Life Scenario
Let’s understand the concept through the same example that I used in both Assumptions and Constraints posts.
Situation – PM requires an Approval of Design Artifacts from the Customer during the course of the project. Project cannot move ahead without this Approval.
PM may “Assume” that the Approval may come within 2 weeks and may plan accordingly.
The team cannot do anything but wait till the Design Approval comes. Project Team is “Constrained”.
There is a “Risk” of that the project might get delayed if the design is not approved as per the schedule.
Project Dependency – The activities of project team can start only after customer’s activity (Design Approval) is complete. The subsequent activity of project team is “Dependent” on customer’s activity (Design Approval).
Difference Between Project Dependencies, Assumptions and Constraints
You would have noticed that the same situation (Design Approval) can be written in different ways. It can written as a Dependency, Assumption, constraint, or Risk.
So what is the difference?
Dependencies vs Assumptions
Project Assumption can be defined as a statement that is generally considered to be a true without any proof or evidence. It is one of the major factors in planning process.
Project Dependencies & Assumptions are very different from each other.
Like in previous example, you can identify an assumption when there is a task dependency. But you can also identify a project assumptions even when there is no dependency. e.g. resource cost is unlikely to go above $100 per hour.
Similarly there could be pure task dependencies without any identified assumptions. e.g. you can ride a bus only after buying a ticket.
Dependencies vs Constraints
A constraint simply means limitation. A project could have constraints due to many factors. Task dependency is just one of them.
In the above example, the project team was “Constrained” due to customer’s activity (Design Approval). They could not do anything till customer’s approval (limitation).
In many other cases the project constraints may not come because of a dependency. e.g. constraints could be due to unavailability of resources, shortage of budget, external environment etc.
Dependencies vs Risks
A risk is an event or condition that is likely to happen, which can impact at least one of the project objectives.
Just like a constraint, risk can happen due to many factors. Schedule dependency is just one of them.
In the above example, the project is likely to get delayed if the approval does not come as per the schedule.
In many other cases the project risk may not be due to a dependency. e.g. risk could be due to incorrect estimates, poor quality, natural calamities etc.
Project Dependencies are considered solely between two Activities.
- They are also called Schedule/Task Dependencies.
- They could be either Mandatory or Discretionary. At the same time, they could also be External or Internal.
- Identification/determination of Project Dependencies is important part of scheduling.
- Discovery of new project activities or dependencies can lead to modification of the project schedule.
- They need not be separately documented. They should, rather, be depicted in the project schedule through Bar Charts and Project Network Diagrams.
Over To You
How do you use the term ‘Project Dependency’ in your projects? Do you use Assumptions, Constraints and Dependencies interchangeably?
Do you document dependencies separately?
Please leave a comment below.