Dependency: A Necessary Concept in Project Management

Dependency: A Necessary Concept in Project Management

Let’s face it, we are dependent. We are dependent on the air we breathe, the food we eat and the water we drink. Without these necessities, we wouldn’t exist.

In our projects, we have tasks dependent on other tasks. In our article, “Four Logical Relationships of Project Management: What They Are and How To Use Them,” we described the four relationships between tasks. The relationship describes how tasks relate, i.e., how the predecessor determines the start or finish of the successor.

Dependency determines the order of sequence or an activity’s placement within the project schedule. I know, it’s subtly different than relationships, but it is important to understand the subtly. In fact, many books and people interchange relationship and dependency – even the PMBOK® Guide does – but there is a difference.

Four Dependency Types

Four types of dependencies define the order or sequence of activities in the project schedule. They are

  • Mandatory dependency,
  • Discretionary dependency,
  • Internal dependency, and
  • External dependency.

Let’s define each and understand when they are used.

Mandatory Dependency

Mandatory dependencies are those that are contractually required or determined by the nature of the tasks themselves. The order in which they are performed flows from the activities’ definitions.

For example, when building a three-story building, the foundation and first floor infrastructure must be built before the second and third floors can be added. The activities dictate the order of implementation.

Mandatory dependency is also called hard logic.

Discretionary Dependency

Discretionary dependencies are defined by the project manager or team. These are the types of dependencies we like because it gives us the ability to move tasks or schedule activities based on our discretion – thus the name. It lets us decide the order or timing of task implementation.

For example, we can shift workloads by moving tasks to periods in the schedule when a particular resource is less utilized, i.e., not overworked. Using our construction example, we need to have the plumbing and electrical work finished before the dry wall is installed (a mandatory dependency between the first two activities and the dry wall installation). But, it is not necessary to do the plumbing first and the electrical second, or at the same time. They can be done in any order as long as they are completed before the dry wall installation. The project team decides the order while developing the schedule.

Discretionary dependency is also known as preferred logic, preferential logic, or soft logic.

Discretionary dependencies should be fully documented so the logic is known in future reviews. While it might be obvious during the planning sessions why the tasks were ordered or scheduled the way they were, this logic is sometimes forgotten over time and will be questioned by the reviewers or anyone not initially involved in the decisions.

Additionally, these dependencies can artificially affect total float time. Documenting, as stated above, will help future decisions and understanding.

Internal Dependency

Internal Dependency are those tasks dependent upon another group inside our company but outside the jurisdiction of our project (or even business unit). For example, we might be a pharmaceutical company manufacturing a particular pill. The pill needs to be packaged in a small bottle, also manufactured by our company. The bottle manufacturing is outside our ability to change the schedule or impact its construction. We are dependent on that part of our company to produce the bottles within a time frame and specifications we need.

Typically, we have no contract with our internal counterparts, no leverage other than escalation of problems, and no ability penalize low quality, late deliveries, insufficient supplies, etc. Working through a company’s political environment can be tedious and draining. As a result, when scheduling internally dependent tasks, add buffers of time to reduce the risk of non-performance. These types of task dependency represent areas of risk for the project.

External Dependency

External dependencies describe those tasks dependent on outside influences such as vendors, parties outside of the company supplying information or parts necessary for the project work, etc. These dependencies are outside of the project team’s control. They represent risk to the project schedule.

For example, let’s say the project must take delivery of 1000 widgets from supplier XYZ. Normally, XYZ delivers on-time and to specification. Recently, XYZ acquired a new customer that orders 10,000 widgets, wants them immediately and XYZ wants to impress this new customer. Your order may be put on hold while they pump out the 10,000 widgets for the new customers. Delivery to you, in this case, is late and in order to make the delay as minimal as possible, XYZ trimmed some corners and delivered less-than-expected quality widgets. As a consequence, your schedule is late and using inferior parts.

Even though you complained to your management, called Purchasing to push XYZ and re-arranged your resources as best you could, the schedule suffered.

In the event of these dependencies, the project team should plan accordingly. Buffers can be placed after these activities to account for slippage. Contractual agreements should have damage clauses to help eliminate these occurrences or at least pay for damages incurred, such as having to crash a schedule at extra expense to bring the schedule back in line, etc.

External dependencies involve relationships between project activities and non-project activities.

Combo-Dependencies

Tasks may have more than one dependency type. For example, the project may have an internal dependency within a series of mandatory-dependent tasks. The tasks must be performed in the order specified within the date schedule defined. While conducting risk analysis, this type of situation should set off alarms and raise red flags. Contingency plans should be prepared in order to recover if risks occur and negatively impact the schedule, budget and/or resources.

Of course, we could have external dependencies tied to task exhibiting discretionary dependencies. Hew, we can move tasks so delays caused by the external dependency have limited impact on the project.

Conclusion

We use dependencies to order the activities in our schedule. The majority of the times, the tasks themselves dictate the order of implementation – mandatory dependency.

The favorite dependency for project teams is the discretionary dependency since we can move the work load to suit the availability of the resources. In the event we have some unexpected down time (yeah, like that happens all the time in my projects), we can move activities in real-time to fill the void.

External dependencies are tough to work, represent risk areas in our schedule and require additional analysis to mitigate the consequences.

Because of the lack of leverage on other internal organizations, internal dependencies represent the toughest dependency to manage.

PMBOK® Guide is a registered trademark of the Project Management Institute. All materials are copyright © American Eagle Group. All rights reserved worldwide. Linking to posts is permitted. Copying posts is not.




January 22, 2011