Project Management Dependencies: Types, Examples, and Explanations

Today in this blog post, we will discuss project management dependencies.

Project management dependencies have a key role in developing the project schedule. You cannot develop your project network diagram before determining project management dependencies among the tasks.

If you are involved with project management and dealing with project planning and schedules, you must understand the dependencies in project management.

Project Management Dependencies

Dependencies in project management manage the task scheduling considering the activity and requirements. If task B cannot start until task A completes, you can say that task B is dependent on task A, and they have a finish-to-start relationship.

In project management, you have four activity dependencies:  

1. Mandatory Dependencies
2. Discretionary Dependencies
3. Internal Dependencies
4. External Dependencies

#1. Mandatory Dependency

Sometimes these project dependencies are known as hard logic. Mandatory dependencies are legally required or are inherent and cannot be ignored. For example, you cannot lay the ceiling until you construct the walls.

The activity cannot be performed in this dependency until another activity is completed.

Example of Mandatory Dependency

An example of mandatory dependency is described below.

Your organization has been awarded a project to construct a 200 km pipeline from one city to another. It will involve navigating several terrains such as rail lines, streams/rivers, and motor highways. 

Will you proceed without getting approvals from the relevant government authorities? 

You cannot, as you require approval from various government agencies to proceed.

Other examples of mandatory dependencies are:

• Parts sourcing before assembling.
• Hardware installation before software installation.

Mandatory dependency can be external or internal.

#2. Discretionary Dependency

Sometimes, discretionary dependency is known as preferred, preferential, or soft logic. This dependency is at the discretion of the project management team. 

You often have more than one way to accomplish a task, and the project management team decides if they want to follow a particular method or depend on the other. The decision is based on their experience, best practices, or lessons learned.

Example of Discretionary Dependency

For example, all electrical works must be completed before the painting starts.

Both activities can be performed independently in this dependency; however, the project team decides to do the electrical works first.

Another example is that plumbing work must be completed before electrical works start. 

Discretionary dependency should be decided as per the best practices. In the example above, electrical systems should succeed plumbing, although the project team can do otherwise. Factors like convenience, economy, safety, etc., affect how we sequence activities. 

Safety concerns influence the case above. Let all wet works such as plumbing be completed before we proceed to electrical wiring.

#3. External Dependency

External dependencies are external to the project, and the project team has no control over them. These activities are usually non-project activities—for example, relations with the vendor, client, or financial department of the organization, etc.

For example, you have a supply agreement with the supplier, and your activity depends on the materials supplied by the supplier who is external to your organization.

Example of External Dependency

Third parties impose external dependencies, such as the government or suppliers. 

An OEM (Original Equipment Manufacturer) tells you that it will take six months to deliver pipes on site. This dependency is not within your control or discretion and is like a schedule constraint.

#4. Internal Dependency

These dependencies in project management are internal to the project management team, and they have complete control over such activities. While developing the project management plan, the project management team decides on this dependency.

Internal dependencies can be mandatory or discretionary.

Activity Dependency Vs Activity Relationship

Many professionals consider activity relationship and dependency the same and use these terms interchangeably. However, they are wrong: although activity relationship and dependency are related, they are different.

A dependency lets you know if an activity relies on another but does not tell you how. It is possible that both activities can start together, or one after the other, or one of them must be completed for the other activity to start.

This is where the activity relationship comes into the picture. 

Like dependencies, activities can have four types of relationship:

1. Finish to Start
2. Finish to Finish
3. Start to Start
4. Start to Finish

Finish to Start

According to the PMBOK Guide, “Finish to Start is a logical relationship in which a successor activity cannot start until a predecessor activity has finished.”

This is the most commonly used activity relationship; it says activity B cannot start until activity A is finished. This is where the mandatory dependency comes in.

For example, you cannot start painting before you finish plastering the walls.

Finish to Finish

According to the PMBOK Guide, “Finish to Finish is a logical relationship in which a successor activity cannot finish until a predecessor activity has finished.”

Activity A must be finished simultaneously with activity B. These two activities may not start simultaneously, but one cannot finish until the other is completed. 

An example in the petroleum refining industry is HF (hydrofluoric acid) Alkylation, where isobutane and alkenes are converted to alkylate used to make gasoline. 

The reaction generates a large amount of heat, so there must be continuous cooling water circulation. The cooling water circulation cannot stop until the HF Alkylation process stops. Therefore, this is a finish-to-finish relationship.

Start to Start

According to the PMBOK Guide, “Start to Start is a logical relationship in which a successor activity cannot start until a predecessor activity has started.”

Activity A must start at the same time or shortly after activity B starts. 

An example is the conditioning of test equipment and the preparation of results recording tables: they occur simultaneously. A further example is the excavation of a trench and the laying of pipes a few days later.

Start to Finish

According to the PMBOK Guide, “Start to Finish is a logical relationship in which a successor activity cannot finish until a predecessor activity has started.”

According to the PMBOK Guide, “Start to Finish is a logical relationship in which a successor activity cannot finish until a predecessor activity has started.”

Activity A must start before we can finish activity B. 

For example, recipient labs must start their system conditioning before finishing distillation. Otherwise, distillates will be delayed before physical and chemical analysis takes place. This delay can result in product degradation.

Another example is when you cannot power off a standby generator until normal power is restored.

Dependencies in the Agile Team

Agile projects emphasize team collaboration, workflow, and productivity, as your work may have a finish-to-start dependency with other teams. These dependencies demand collaboration for a seamless workflow. 

The more dependencies, the less predictable the work; therefore, it becomes harder to organize. This is called the upstream-downstream relationship. The output of upstream is the input of downstream. These hand-offs result in delays if they are not proactively managed.

Small teams rely on external dependencies such as skills import, whereas a cross-functional team may not require this. Dependency creates risk; therefore, it should be considered during sprint planning to use collaboration to manage such risks proactively. 

A Gantt chart helps visualize these activities, their sequence, and dependencies.

Lessons learned register and expert judgment can also help detect delays due to external and internal dependencies in the past, forming a basis for decisions in the present.

Dependencies are documented as activity attributes because these play important roles during the sequence activities process. Agile uses Look Ahead modeling to identify dependencies on other teams. The team can address the dependency by re-prioritizing the work. This helps eliminate the waste of waiting. 

As shown below, waiting is one of the seven wastes in software projects:

1. Extra features
2. Extra processes
3. Partially done work
4. Motion
5. Waiting
6. Task switching
7. Defects

Dependencies can cause waiting.

How to Manage Dependencies in Project Management

The following guidelines can help you manage project management dependencies.

Identify and Map Dependencies

During the identify and sequence activity process, ensure you have identified all project activities, find the dependencies, and sequence them. Afterward, you can visually map these activities. Visualizing can help find more dependencies and ensure the identified dependencies are correct.

For this purpose, you can use a Gantt chart, Kanban board, and project network diagram.

Communicate with Stakeholders

After identifying dependencies and creating the sequence, you must communicate it to the project stakeholder to get their buy-in. They must understand the task dependencies and consequences of altering them in later stages of the project.

Update the Risk Register

Mandatory dependencies can cause risk. You must identify external and mandatory dependencies and ensure they don’t affect your project objective.

Keep monitoring the assumptions and constraints. While creating dependencies, you might have to consider many assumptions and be bounded by constraints. So these can also affect your project objectives. Keep watching project assumptions and constraints.

Develop Contingency and Fallback Plans

After identifying project dependencies-related risks, develop contingency and fallback plans to manage such risks. Fallback plans are used when contingency plans fail to contain the risk.

Conclusion

Project dependencies are risk factors, and you must mitigate them during planning, regardless of whether it is a traditional or Agile project management methodology. The earlier they are identified, the more likely the project will avoid delays and meet the project deadlines.

How do you deal with project management dependencies in your projects? Please share your experiences through the comments section.