project management dependencies

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

Dependencies in project management play an important role in developing the project schedule. You cannot develop your project network diagram before determining dependencies among the project tasks.

So, if you are into project management and dealing with schedules or planning, you must understand the dependencies in project management.

Let’s get started.

Project Management Dependencies

In project management, you have four activity dependencies:  

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

Mandatory Dependency

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

In this dependency, the activity cannot be performed until the other activity is completed.

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 through several terrains such as rail lines, streams/rivers, motor highways. How will you proceed without getting approvals from concerned 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 before software installation

Mandatory dependency can be external or internal.

Discretionary Dependency

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

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

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

In this dependency, both activities can be performed independently—however, the project management team decides to go for the electrical works first.

Another example can be, plumbing work must be completed before electrical works start. 

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

The above case is influenced by safety concerns. Let all wet works such as plumbing be completed before we proceed to electrical wiring.

External Dependency

These dependencies are external to the project team, and they have 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 supply of the material by the supplier who is external to your project.

External dependencies are imposed by third parties, such as the government or suppliers. An OEM (Original Equipment Manufacturer) can tell 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.

Internal Dependency

These are dependencies in project management that 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 this dependency.

Internal dependencies can be mandatory or discretionary.

Activity Dependency Vs Activity Relationship

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

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

This is where activity relation 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

Finish To Start (FS) Relationship

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 simply says activity B cannot start until activity A is finished. This is where the subject of mandatory dependency comes in.

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

Finish to Finish

Finish To Finish (FF) Relationship

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, and therefore there must be continuous circulation of cooling water. The cooling water circulation cannot stop until the HF Alkylation process stops. Therefore this is a finish-to-finish relationship.

Start to Start

Start To Start (SS) Relationship

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

Start To Finish (SF) Relationship

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 distillation is finished. Otherwise, distillates will be delayed before physical and chemical analysis takes place. Such delay can result in product degradation.

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

Dependencies in Team Activities

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, and therefore it becomes harder to organize the work. This is called the upstream-downstream relationship. The output of upstream is the input of downstream. These hands-off, if not proactively managed, result in delays.

Small teams tend to rely on external dependencies such as skills import, whereas a cross-functional team may not require this. Dependency creates risk, and therefore, it should be considered during sprint planning to use collaboration to manage such risk proactively. A Gantt chart helps visualize these activities, their sequence, and dependencies.

dependencies in team activities

Lessons learned register; 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 sequencing activities. 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. 

Note that, waiting is one of the seven wastes in software projects, as shown below. 

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

Dependencies can cause waiting.

Conclusion

Project dependencies are risk factors, and you must mitigate them during planning, regardless of whether it is 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 project? Please share it through the comments section.