Which dependency requires that one activity be finished before a second activity can begin?

Posted by SkillMaker in Jan, 2017

What are Project Management Task dependencies?

Task dependencies (sometimes called logical relationships) are the interrelationships between tasks on a project. These dependencies fix the order in which activities are carried out.

For ease of explanation, the dependencies that exist between tasks will be described in terms of just two: the predecessor task (the one before) and the successor task (the one with which the predecessor has a relationship). They are typically shown in a GANNT Chart.

Four types of task dependencies

1. Finish to Start: a predecessor task must be completed before a successor task can begin. This is the most common task dependency.
2. Start to Start: a predecessor task must begin before the successor task can start, or, said another way, the successor task can start only after the predecessor task has started. Sometimes this dependency is further modified by stating a fixed time after task A starts before which task B must start.
3. Finish to Finish: a predecessor task must finish before the successor task can finish.
4.  Start to Finish: a predecessor task must start before the successor task can finish.

What causes Project Management Task dependencies?

Dependencies are created for different reasons. The constraints may be:

• logical (or causal) (e.g. a report cannot be proofread until it is written)
• resource-based (e.g. if there is only one editor, four books cannot be edited simultaneously)
• discretionary (e.g. a Project Manager prefers to do task A before task B, but could just as easily do the reverse).

Parent–child relationships

Another type of task relationship is the parent–child relationship. This relationship is not a dependency, though there may be dependencies between the various child tasks. It exists when a large task (the parent) is broken down into its various smaller (child) tasks.

Displaying task dependencies

The dependencies between tasks, as represented on a GANTT Chart, will show some activities following one another, others occurring in parallel, and others starting or finishing within a time range set by another activity. This means there are often gaps of time between tasks. Sometimes, these time gaps are set delays— for example, lag time, whereby a certain amount of time, say 2 days, has to elapse after Task A starts (say, allowing a first coat of paint to dry) before Task B (applying a second coat of paint) can start. Other time gaps, such as lead time and float, allow the Project Manager to exercise flexibility in determining when they will be scheduled.

Identifying the critical path

Once a project schedule is developed, showing all task dependencies, resources can be meaningfully appointed to particular tasks, and the critical path for the project can be identified, using tools such as Critical Path Method, PERT or the Critical Chain Method.

Additional resources

To see an explanation of task dependencies and lag time, view:

https://www.youtube.com/watch?v=moKzeG42Dpw

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.

What are the 4 types of dependencies?

Which is a dependency relationship in which one activity must finish before another activity can finish?

Which is the most common type of task dependency Finish to Finish Start to start start to finish finish to start?

What is a finish to start dependency?