No man is an island.
We are all dependent on each other and society as a collective to serve our needs and generate momentum as a race.
The same scenario and logic are reflected in the domain of project management.
No activity or task exists in isolation.
Each item relies on the output of another activity in some way and contributes to the end result of the project.
The relationship between the two tasks is defined as the dependency between them.
In this article, we will elaborate on the meaning of dependency, find out how it is related to constraints, talk about the different types of dependencies and then look at a quick three-step process to effectively tackle dependencies in a project.
If you are a project manager, treat this information as a refresher. If you are gathering knowledge, the blog is all you need to master dependencies in an operational environment.
What is a Dependency?
In the world around you, a dependency is the state of existence of an entity or an item such that its stability is dictated by another entity or resource.
For example, children are dependent on their parents for care and sustenance. The elderly are often dependent on their progeny for the same. And workers are largely dependent on corporations for money and income.
In the setting of a project, the definition of dependency shifts somewhat.
A project dependency is a logical, constraint-based or preferential relationship between two activities or tasks such that the completion or the initiation of one is reliant on the completion or initiation of the other.
If you are painting a canvas, the application of the oil paint is one activity. And preparing the canvas is another. You can’t use the paint unless the surface has been brushed with the primer.
Thus one activity is dependent on the other.
If the primer is not available for 3 days because of a supplies strike, the painting completion will be delayed by 3 days because you won’t be able to start your work.
Some Dependency Related Terms:
The following are some common terms that are always associated with project dependencies.
Dependencies and constraints have a cause and effect relationship. In its simplest form, a constraint is a restriction within the boundaries of which the task has to be completed or executed. A constraint may be driven by a lack of resources like money and man-power, shortage of available time and even dearth of expertise. Sometimes constraints can give rise to dependencies.
If there are four cakes to be creamed and only one baker skilled enough to do it, then the creaming of one cake is automatically dependent on the completion of creaming of another. Here a constraint has produced a dependency.
In other settings, a dependency might be the reason behind a constraint. In a tailoring shop, the actual sewing can’t proceed unless the measurements are taken first. This is a bona fide logical dependency. If the measurement takes 20 minutes and the seamstress only has two hours to complete the dress, then under the circumstances, she will get just 100 minutes to meet the deadline. This is because the 20 minutes spent in the measurement room are non-negotiable and there is no way around the dependency.
Classic project management defines three constraints of cost-time-scope which can be considered as the three sides of a triangle. The area of the triangle is the quality of the deliverables. Any changes introduced to the constraints alter the triangle’s area and thus the overall quality of the project.
A good project manager is someone who can keep track of all the constraints and dependencies and re-allocate resources in a way that ensures final project quality.
Lead and Lag
Lead and Lag are both related to dependencies.
Lead is defined as the duration of time by which a successor activity can be advanced or accelerated with respect to the predecessor task. Let us assume that an activity B is scheduled to start when activity A completes, which is in 10 days. However, if B is started just 5 days after A, then under the circumstances, B has a lead of 5 whole days.
This can be done only when the dependency between A and B is discretionary – that is starting B upon A’s completion is a best practice or convenience and not dictated by logic and constraints.
Lag, on the other hand, is the duration of time by which a successor task has to be delayed with respect to the predecessor activity. It is generally not desirable in the project management domain.
We have already covered Critical Path in great detail. But just to recap, a Critical Path is the longest unbroken chain of sequential activities or dependent tasks such that altering the duration of completion of the items in any way directly impacts the deadline of the project, leading to possible violations.
While making a cake, baking of the batter and decoration of the sponge are part of the Critical Path chain. Any delays in these tasks will delay the presentation of the cake at the guest table.
Different Types of Dependencies That You Should Know About:
Dependencies can be categorized in a number of ways based on conditions like completion and initiation of tasks, the relationship of tasks to the project and the company and the reason for the existence of the dependency.
Causal, Resource & Preferential Dependencies
Causal or logical dependencies are those dependencies that can’t be avoided. They are intrinsic to the nature of the project and the nature of the tasks involved.
Your stomach can’t digest food unless you eat it first. This is a causal or logical dependency. Without completion of one step, the next can’t be initiated in any way.
Resource based dependencies are driven by constraints. As we have already discussed, if there are only a limited number of skilled professionals available to work on a project, there is often a need to proceed sequentially simply because there aren’t enough hands (or manpower) to complete everything simultaneously.
Where resource-based constraints and thus dependencies are present, generally there is no causal dependency – that is all the activities can be tackled together if the needed facilitators are present.
Preferential dependencies are dependencies that are guided by best practice or convenience. They are generally introduced in projects to focus on the quality of deliverables. Builders like to soak the foundation of the roof for at least 5 to 7 days before laying the tiles.
They can go ahead and do it immediately without bothering about the “settling and soaking”. But this is supposed to compromise the structure’s integrity. And so a preferential dependency springs up.
FS, SF, FF & SS Dependencies
A FS or Finish to Start dependency is the most common and logical dependency both in project management and the real world. A particular task B can’t start unless task A is completed satisfactorily. In this case, task B generally needs to utilize or build on the output of task A in some way.
A SF or Start to Finish dependency is tricky. It says that the successor task (let’s call it task B) can’t finish unless the predecessor task (let’s call it task A) has started. However, once A is initiated, B can be closed at any time.
The best example is that of billing a customer (task B). It generally signals the completion of a project. Imagine that you need to deliver 5 bouquets to a party. You ‘run the clock’ on the customer as soon as you receive the order because you start working on the assembly and in effect, the buyer has started paying for your time. But you can’t actually invoice the client unless the delivery of the bouquets (task A) is done.
Start to Finish dependencies are common in Just in Time employee schedules where workers do not get set slots. They are asked to come to the office as and when projects crop up.
A SS or Start to Start dependency says that the successor activity can’t start unless the predecessor activity has initiated. But after this initial constraint, the two activities can proceed in parallel. For example baking the cake and making the icing are an example of a start to start dependency. As soon as you put the batter in the oven (task A) you can start making the icing (task B).
SS dependencies generally exist because of resource-based constraints. Let’s imagine that a helper materializes and assists you in baking the dessert. The icing then is no longer dependent on when you put the batter in the oven. The SS dependency only applies if you are preparing the cake all by yourself.
A FF or Finish to Finish dependency says that the successor task can’t finish unless the predecessor task is also finished. They don’t need to complete together.
The hair and make-up woman who accompanies a movie star to a red carpet unveiling can’t put the finishing touches unless the actress reaches the venue. Otherwise, the freshness of the look doesn’t hold up.
This is how a Finish to Finish dependency works.
The Outside – Inside Dependency Grid
Often certain task dependencies are internal to a project and external to the company or internal to the company but outside the direct circle of influence of the project manager. The various combinations are discussed below.
Company In – Project In Dependencies: These apply to sequential tasks – the ones that have to be tackled according to a pre-defined logic flow.
Company In – Project Out Dependencies: These apply to tasks that are taken care of by other departments. Certain in-department project related activities may rely on their outputs but they are not under the direct control of the project manager.
Company Out – Project In Dependencies: Activities commissioned to third-party suppliers are an ideal example of this category. The output has a direct bearing on the project but the vendors are not employed by the company.
Company Out – Project Out Dependencies: For a project to reach completion, the company building must be sturdy and accessible. If for some reason the construction is found to be faulty, then resumption of work will depend on the verdict of the municipality. This is a factor outside the company and the project but can adversely affect the deliverables.
How to Effectively Tackle Dependencies in Project Management:
If you use a robust project management software solution, task dependencies and related views are always an important part of the dashboard.
- Brainstorm all possible project dependencies and associated constraints keeping in mind the triple constraints model. If there are many dependencies and constraints, you can go ahead and identify the Critical Path as well. This will ensure your focus and attention are on the tasks that can impact the bottom line.
- Engage with stakeholders and ensure that they understand what the most important dependencies and constraints are. If the components of the Critical Path are included in the project charter, then the stakeholders are automatically intimated of them.
- Brainstorm risks and challenges associated with these dependencies and constraints. You might want to have a cross-functional meeting to have multiple perspectives onboard. Once you feel you have covered most of the foreseeable disruptive circumstances, then go ahead and find solutions or pre-emptive actions to manage the impact of disturbances on the dependencies and constraints.
The result of the third step will be added to the change and risk management documents.
Dependencies are inevitable in a project. You will rarely come across one in which all the tasks and activities are independent of each other.
But fear not, dependencies can be leveraged to your advantage if you can find legitimate ways to accelerate the execution time of critical path activities.
Think about it.