I have written this article to provide complete details of project dependencies. It discusses all aspects of dependencies in project management including definition, meaning, and description. It also includes explanatory diagrams and small examples. You will also find difference between project dependencies, assumptions, constraints, and risks in this article.
Table of Contents
Project Dependencies – Definition & Meaning
A project dependency can defined as an association between two activities, in which one activity requires input from the other. It simply means that one activity is reliant on the other for its start or completion.
A dependency in project management can be characterized as a schedule dependency. It can be defined between any two tasks like activities, or work packages. It can also be defined between milestones
Sometime dependencies are (incorrectly) referred to inter-dependencies. Inter-dependencies are between two different projects.
You can also look at Max Wideman’s Glossary for some other definitions.
A project dependency is loosely referred to as activity relationship. However, these two are different. A relationship between two activities can be established only if one activity is dependent on the other.
Project Dependencies Example
Let us consider two activities A and B. Let us assume B is dependent on A through FS relationship without any lead or lag.
This simply means that B is dependent on A and B would start as soon as A finishes.
I have used Finish to Start relationship in the above example but dependencies exist for other project relationships as well – Finish to Finish, Start to Start and Start to Finish. They exist with lead or lag also.
The above example can be depicted in any one of the following ways by using Gantt Charts or 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. It uses 0 method for calculating start and finish dates.
Difference Between Project Dependencies, Assumptions and Constraints
Let’s understand the concept through the same example.
Situation – A PM requires an ‘Approval’ of Design Artifacts from the Customer during the course of the project. Project cannot move ahead without this ‘Approval’.
Assumption: PM may “Assume” that the ‘Approval’ may come within 2 weeks and may plan accordingly.
Constraint: The team cannot do anything but wait till the ‘Design Approval’ comes. Project Team is “Constrained”.
Risk: There is a “Risk” that the project might get delayed if the design is not approved as per the schedule.
Dependency: The activities of project team can start only after customer’s activity (‘Design Approval’) is complete. The subsequent activities of project team are “Dependent” on customer’s activity (‘Design Approval’).
You would have noticed that the same situation can be written in different ways. It can written as a Dependency, Assumption, constraint, or Risk. So, let us understand the difference between these terms.
Dependencies vs Assumptions
Project Dependencies & Assumptions are very different from each other.
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.
In the above example, we identified an assumption because of a dependency. However, you can also identify 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.
You should read my article on Project Assumptions to get a deeper understanding of the topic.
Dependencies vs Constraints
Project Dependencies & Constraints are also very different from each other.
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, we identified a constraint because of a dependency. The project team was “Constrained” due to customer’s activity (‘Design Approval’). They could not do anything till customer’s approval.
However, you can also identify project constraints even when there is no dependency. e.g. constraints could be due to unavailability of resources, shortage of budget, external environment etc.
You should read my article on Project Constraints to get a deeper understanding of the topic.
Dependencies vs Risks
Project Dependencies & Risk are also very different from each other.
A risk is an event or condition that is likely to happen, which can impact at least one of the project objectives.
Just like assumptions and constraints, risk can happen due to many factors. Schedule dependency is just one of them.
In the above example, we identified a risk because of a dependency. The project is likely to get delayed if the approval does not happen as per the defined schedule.
However, you can also identify project risk even when there is no dependency. e.g. there could be risks due to incorrect estimates, poor quality, natural calamities etc.
You should read my article on Project Risks to get a deeper understanding of the topic.
Final Thoughts
Project Dependencies are considered solely between two tasks.
- They are also called Schedule/Task Dependencies.
- There are four types of dependencies four types of dependencies viz. Mandatory, Discretionary, External and 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?
I would love to hear from you.
PMP Exam Formulas
I have also compiled a PMP Formulas Cheat Sheet. It contains 45 formulas and 57 abbrviations. It will help you in your exam prep. It is the best and most comprehensive cheat sheet based on the PMBOK Guide 6th edition. You can download it free of cost for your studies.
If you are looking beyond a cheat sheet, then I would suggest you to buy detailed PMP Exam Formula Study Guide by Cornelius Fichtner. It contains detailed explanations of all the formulas along with examples and 105 practice questions.
Disclosure: This article contains affiliate links - it means that, if you buy from any of these links, then I will receive a small commission that would help me in maintaining this blog for free. However, for you, there is no extra cost. I recommend only those products that I believe will definitely help the certification aspirants.
As an expert in project management with demonstrable expertise and a deep understanding of the subject, I appreciate the thoroughness of your article on project dependencies. Your detailed exploration covers various aspects, from the definition and meaning of dependencies to practical examples, and even a clear distinction between dependencies, assumptions, constraints, and risks.
Let's delve into each concept you've covered in your article:
Project Dependencies – Definition & Meaning:
Your explanation of project dependencies is accurate and comprehensive. You highlight that a project dependency is an association between two activities, where one activity relies on the other for its start or completion. Moreover, you rightly emphasize that dependencies can be categorized as schedule dependencies and can exist between tasks, activities, work packages, or milestones.
Project Dependencies Example:
The example you provide, involving activities A and B with a Finish to Start relationship, effectively illustrates how dependencies can be represented mathematically and visually through Gantt Charts or Project Network Diagrams. This practical application enhances the reader's understanding.
Difference Between Project Dependencies, Assumptions, and Constraints:
Your article effectively distinguishes between project dependencies, assumptions, constraints, and risks using a scenario involving the approval of design artifacts. This real-world situation makes the concepts more tangible for readers.
-
Dependencies vs Assumptions:
- Dependencies represent relationships between activities, while assumptions are statements considered true without proof. Your example of resource cost assumptions without direct dependencies adds depth to this comparison.
-
Dependencies vs Constraints:
- Dependencies involve reliance between activities, whereas constraints are limitations. The example of the project team being constrained by the customer's design approval effectively differentiates these concepts.
-
Dependencies vs Risks:
- Dependencies, such as the approval schedule in your example, can introduce risks. This distinction helps readers understand that risks can arise independently of dependencies.
Final Thoughts:
Your final thoughts encapsulate the essence of project dependencies, emphasizing their importance in scheduling and the potential impact on project schedules. The mention of four types of dependencies (Mandatory, Discretionary, External, and Internal) further enriches the reader's understanding.
Over To You:
Engaging with readers, you encourage them to share their experiences and practices regarding project dependencies, assumptions, constraints, and risks. This interaction fosters a sense of community and allows for the exchange of valuable insights among project management professionals.
In conclusion, your article is a valuable resource for anyone seeking a comprehensive understanding of project dependencies and related concepts. The inclusion of practical examples, visual representations, and the clear differentiation between terms contributes to the article's effectiveness in conveying complex project management principles.
