Fundamentals of Project Management: Understanding Dependencies

Nothing in the world works in isolation. To meet your needs, you have to depend on other people around you. If your need bread, you have to buy it from someone else.

If you feel lonely, you have to connect with another person. If your car is faulty, you need a mechanic to repair it for you.

If one country produces one thing, it needs another country to buy what it has produced.

This shows that in the world, everything and everyone is dependent on something or someone else.

The same is true when it comes to project management.  Successful implementation of projects relies on interrelationships between people, your use of project management software or task management software, other projects, project resources, sub-projects, and so on. Changes in one of these factors affects other factors and the completion of the whole project.

For instance, if you are building a mobile app, you will need programmers to write the code for the app, UX designers to design the interface, copywriters to create the copy for the app, and so on.

If one of these teams fails or is late in delivering their bit, then they affect the completion of the whole project.

These interrelations of different project variables are known as dependencies.

The more dependencies a project has, the more complex it is. In some cases, the project might even have dependencies from external factors such as the project sponsor, regulatory bodies, suppliers, and so on.

Clearly, for the project to be implemented effectively and efficiently, the project manager needs a thorough understanding the dependencies affecting the project and take appropriate action to manage these dependencies and ensure everything runs smoothly.

For instance, when different teams share dependencies, it is necessary that the teams open lines of communication with each other.

This helps minimize the occurrence of conflicts and ensures efficiency is not compromised.

In today’s article, you are going to learn everything you need to know about project dependencies.

WHAT ARE DEPENDENCIES?

A dependency is a logical relationship which exists between two activities/tasks in a project or between an activity and a milestone.

Put simply, a dependency is a relationship which defines the order of carrying out tasks. If you have two related tasks A and B, dependencies will define which of the order in which you are going to carry out the tasks.

This relates to either starting or finishing the tasks.

For instance, you might find that task B cannot be started until task A is completed, or Task B cannot be completed until task A gets completed.

To make this easier to understand, let’s use the example of a meeting. You can’t send out the meeting’s minutes until you have first had the meeting. Having the meeting is Task A and sending out the minutes is Task B.

Sending out the minutes is dependent on having the meeting.

Another good example is house construction. You can only put the roof on after you have built the walls.

Therefore, roof installation is dependent on the walls being built first.

TYPES OF DEPENDENCIES

Dependencies for Scheduling

A project manager must have a thorough understanding of the dependencies between tasks. Only then can he or she prepare a project schedule.

Understanding scheduling dependencies will enable the project manager to work out the order in which the tasks should take place. This will prevent confusion and increase efficiency, ensuring the project is implemented smoothly.

In project management, there exists 4 types of scheduling dependencies:

Source: ProjectManager.com

• Finish to start (FS): This refers to situations where one task has to finish before the other task can start. For instance, A FS B means that an activity/task named A must finish before the activity named B can begin. In other words, B cannot start until A has finished. For example, you must finalize land purchase (A) before you can start building a house (B) on the land.
• Finish to finish (FF): This refers to situations where one task cannot be finished until another task is finished. For instance, A FF B means that for activity B to finish, A must first finish. For example, if you are baking a cake, you need to bake the cake (A) before you can put icing on it (B). Sure, you can start preparing the icing even before the cake is completely baked, but you can only put the icing on the cake once baling is complete.
• Start to start (SS): This refers to situations where one task has to start for the other one to start. For instance, A SS B means that activity B cannot start until activity A has started. For example, if you are building a road, you cannot start leveling the road (B) before the asphalt is poured (A). However, once the pouring of asphalt has started, leveling can also start, even if pouring of asphalt is not complete yet.
• Start to finish (SF): This refers to a situation where one task has to start in order for another one to finish. For instance, A SF B means that for activity B to finish, activity A must have started. For example, in a situation where two security guards work in shifts, guard A has to arrive at work and start his shift before guard B can finish his shift.

When talking about dependencies, the task that comes before is known as the predecessor and the task that comes after is referred to as the successor.

One successor task can have multiple predecessors, and one predecessor can have multiple successors.

Dependences In or Out of the Company, In or Out of the Project

Dependencies happen not just within the project but also outside the project’s sphere of influence, both inside and outside the organization.

Dependencies that occur within the company are of two types: in-project or out of the project.

Dependencies that occur in-company and in-project include project tasks that take place in sequence (for instance, before you can train users, you have to prepare the training material).

Dependencies within the company but out of the project are the links formed with other projects (for instance, for Project B to begin, Phase 1 of Project A must first complete).

Dependencies that occur out of the company are also of two types: in-project or out of the project.

An example of dependencies that occur out of the company but within the project are when certain tasks have to be completed by third party supplier (for instance, provision of software).

An example of dependencies that occur out of the company as well as out of the project is the health and safety standards that have to be approved (for instance, in a construction project, building plans have to be signed off by an external agency).

OTHER TYPES OF DEPENDENCIES

In addition to the four types of dependencies discussed above, there are other types of dependency categories, such as:

1. Causal Dependencies

These dependencies occur in the natural flow of a project’s tasks. Each subsequent task is dependent on the completion of a previous task.

For instance, when baking a cake, you must first buy ingredients, mix them together, and then put the mixture in the oven for it to bake. If you avoid any step or task within this given process, the project will fail.

2. Resource-based Dependencies

These dependencies are caused by project constraints. They do not have any causal dependency.

In other words, if all resources were available, all the tasks would be worked on simultaneously.

For instance, where the number of skilled professionals working on the project is limited, the tasks will have to proceed sequentially because the project doesn’t have enough manpower for everything to be completed sequentially.

3. Preferential Dependencies

These are determined by protocols, best practices, or preferred processes. In other words, the order of tasks is determined by the order preferred by the project manager.

4. Cross-Team Dependencies

These occur in larger organizations where multiple project teams are working hand-in-hand.

Cross-team dependencies exist where the two or more project teams need deliverables from each other.

TYPES OF CROSS-TEAM DEPENDENCIES

The various types of cross-team dependencies include:

1. Technical Dependency

A technical dependency is when two projects have a relationship that has an effect on the technical outcome of deliverables.

This happens when team B is incapable of moving forward (easily) without a particular deliverable produced by team A.

This is exactly like the finish-to-start dependency that is very common in project schedule, the only difference being that in this case it is happening between two teams.

A good example is in IT projects where marketing team can’t start working on their marketing campaign until they get details like design specifications and the product’s functionality from the design team.

The engineering team also has to wait for the design team before they can start working on developing the hardware.

2. Schedule Dependency

Another name for this is synchronization dependency. This is a dependency that occurs between two projects where Project A’s timing will impact the outcome of Project B.

This usually happens when two deliverables are needed at the same time for both projects to complete. This type of dependency is similar to the finish-to-finish dependency that occurs between tasks in the same project.

3. Resource Dependency

This type of dependency exists when two projects share critical resources. This dependency is managed at the project portfolio level in the organization or at the resource manager level.

For harmony and efficiency to prevail, the project teams must be aware that they share critical resources.

The two teams must come to an understanding on how they are to use these resources harmoniously.

When one project is using the critical resources, the other projects may either use fewer of the resources or have to wait until the first project is done.

That means when the first project goes off-track and puts in extra, unplanned time using the critical resources, the other projects waiting to use the resources will be impacted.

Resource dependency can lead to a lot of confusion or conflict in the project environment. This can become toxic and unproductive, if allowed to fester.

Resource dependency can be reduced by allocating money to acquire more of the critical resources to ensure different projects aren’t in conflict over the same resources. However, this is not always feasible.

The best way to deal with such conflicts before they occur is to foster communication and a level of collaboration (where possible) between the different projects using the same critical resources.

This will ensure the different project teams don’t start seeing themselves as different turfs, leading to a lot of unproductive conflict that ends up derailing the projects or causing delays and massive inefficiencies.

The team leaders should understand their mutual resource dependency and open lines of dialogue with each other, treat each other with respect and find ways to make things run smoothly.

4. Information Dependency

This dependency concerns communication between projects. Information shared by Project A might be useful in impacting the scope of Project B or the approach it takes to complete the project.

An information dependency typically exists when the two projects have a known touch point between them. For instance, if Team A is working on changes in the engineering standards, architecture, operational procedures or security, this may have an impact on what team B does, going forward.

Team B may even have to revise what it had already done to fit the new knowledge framework that Team A has provided.

For that reason, the two project teams must maintain close communication to ensure smooth operation and avoid inefficiencies such as having to rework certain sections of a project.

The information dependency could also be in terms of new knowledge and capabilities developed by one project team which will benefit another project team. This is common in tech projects.

DEPENDENCIES AND CONSTRAINTS

Dependencies have a cause and effect relationship with constraints. A constraint is a restriction which defines the boundaries within which a task has to be completed or executed.

Put simply, constraints define the boundaries of the project.

Some of the most common constraints are budget, resources and schedule.

The project must be executed within the limitations of resources, money and time.

If it has 5 people working on it, the project can only manage what 5 people can do, not what 10 people can do. Manpower is a resource constraint.

Constraints like manpower, money, lack of expertise, and shortage of available time can cause dependencies to emerge. For instance, let’s say there are four cakes to be creamed, but there is only one baker who has enough skill to do this.

In this case, dependencies automatically develop between the cakes, because the creaming of the next cake depends on the preceding cake first being creamed.

As you cans see the constraint (only one skilled baker available) has created dependencies between the cakes.

In a different setting, the dependency might itself be the cause of the constraint.

For instance, a tailor won’t start actual sewing until he or she has first taken the measurements.

If taking measurements requires 10 minutes, but the tailor has only one hour to work on the dress, he or she has only 50 minutes to complete the work within deadline.

The 10 minutes the tailor spent taking measurements are non-negotiable, and that’s why they create a constraint of 50 minutes instead of the original 1 hour. If there are more non-negotiable activities that take up time, the time constraint will shrink even further.

The three key project constraints. Source: ProjectManager.com

Project management is typically defined according to three key constraints: cost, time, and scope. They are often represented as the three sides of a triangle.

This triangle’s area is equivalent to the project deliverables. If you alter the triangle’s sides (constraint) in any way, this affects the area, which means changes in constraints lead to a change in the overall quality of the project.

The project manager should keep track of all dependencies and constraints in the project and reallocate resources in a way that ensures efficiency, effectiveness, and a quality product when the project is completed.

HANDLING DEPENDENCIES IN PROJECT MANAGEMENT

Dependency management is crucial for portfolio planning and project execution.

Unknown dependencies are a major risk and when working in a complex project environment, not identifying project dependencies early enough may lead to derailment of projects.

To effectively manage dependencies, follow these steps:

1. Brainstorming

Spend time brainstorming all the possible dependencies contained in the project and their associated constraints. This will help you determine or identify the critical path.

As a result of these deep prior understanding of the project’s dependencies, you will be able to implement the project with efficiency and effectiveness.

2. Stakeholder Engagement

Engage with relevant stakeholders to ensure they understand what the most critical constraints and dependencies of the project are. This is especially necessary if some of the stakeholders are involved.

For instance, if a certain task will only happen after the project sponsor has released certain funds or signed a certain document, it’s important to make the sponsor understand this dependency and how it impacts on the rest of the project.

3. Brainstorm Risks and Challenges

The project team should brainstorm together the risks and challenges that may arise as a result of the dependencies and constraints of the project.

For instance, if task B cannot start until task A has completed, the project team must be vigilant to ensure Task A completes in good time. This will eliminate the risk of late delivery and the consequences.

4. Prioritization

Determine how you will prioritize the dependencies and their associated timeframes. The level of priority of a dependency will depend on its impact on the project.

When prioritizing dependencies, consider the following:

• How relevant is the dependency to the fulfillment of project objectives or to the realization of a specific project task?
• What impact does the dependency have on the project’s milestones, scope, benefits, budget, quality, timing, or third party/contractual agreements?
• What impact will the dependency have on the current status of project activities?
• How significant is this dependency to regulatory, legal, or policy compliance?
• What impact will the dependency have on planned project analyses?
• If the dependency is not immediately resolved, what are the schedule issues that are most likely to result?

5. Categorization

It is important, especially for a large project, to determine how the dependencies will be categorized. This aids in easier reference and thinking about the project.

You can categorize them according to:

• Where multiple projects are intersecting, categorize according to the project from which each dependency originated.
• The project work streams impacted by each dependency.
• The owner of each dependency.

6. Define Dependency Ownership

In most cases, but not all, each dependency has an owner – that is the project or the person who is responsible for or most invested in its successful delivery.

Determining the dependency owner enables efficiency/speed in communication and in delivery.

7. Determine Methods of Recording, Storage, Distribution, or Tracking

It’s important to determine in advance which methods you will use to record, store, distribute, or track the project’s dependencies.

You could use:

• Word processing files
• Simple database systems such as Microsoft Access
• Sophisticated database systems such as ORACLE.
• Spreadsheets
• Dependency tracking software packages
• Intranet or web-based storage and retrieval systems

8. Communication with Project Team

The project manager should ensure that all project team members are fully aware of their given responsibilities and how these align with the dependencies.

Ensuring the team members understand the dependencies will ensure that the project is implemented smoothly and effectively.

When project team members don’t understand the project dependencies, they are liable to get into disagreements with each other.

For instance, if Team B needs Team A to provide a certain deliverable before they can go ahead, late delivery by Team A will impact on Team B. This can lead to quarrels and strife between the two teams.

Other than meeting with the team members and talking it out, another way to ensure team members are aware of dependencies is to structure the project work space in such a way that team members have day-to-day interactions.

When the team members interact often, organic unity will develop and conversations which will help them understand how much they need each other. It will help the team members to start seeing the project as one organic entity rather than splintered factions.

For instance, if team members in a software development project don’t interact, each of them will feel that the task they are working on is superior to what the others are working on.

When they do interact, they begin to realize that their individual tasks are worth nothing if the entire project does not succeed.

They will then start to be proactive in helping each other to ensure the project is completed within deadline and at a high level of quality.

WRAPPING UP

It is clear that understanding and properly managing dependencies is very crucial for the success of a project, especially when working on a large, complex project with many components and which intersects with other projects within the ecosystem of a large organization.

In such a case, knowing and understanding all the dependencies in the project will help minimize conflict, increase efficiency, and ensure the project is completed within the set deadline.

If a project is not running smoothly, the project manager should take a look at the dependencies and see if they are impacting the delivery of the project.

For instance, is the project getting delayed because one team has not delivered something that another team is dependent on?

The project manager should also make sure that all the personnel and teams involve in the project understand the project dependencies and their specific roles in ensuring the successful completion of the project.