The fate of your company lies in dependencies in project management. We're not dramatic. It's true.
By not understanding project dependencies for everyday tasks and assignments, you're putting your company at risk for failure.
But, you shouldn't worry. You're here, and we've got everything you need to know to keep your business running in spite of these dependencies.
So, keep reading to learn more about dependencies in project management. We'll cover everything you need to know to keep your project team afloat.
Below is everything we will cover. Feel free to skip ahead.
- What is a dependency?
- What are dependencies in project management?
- Terms related to project dependencies
- The types of dependencies in project management
- The outside-inside dependency grid
What is a dependency?
A dependency is a kind of relationship between two people, things, or actions. With dependencies, the existence of one person, thing, or action determines the stability of the other person, thing, or action.
This means that one person, thing, or action can only exist or happen because of another person, thing, or action stabilizing it.
One of the most popular everyday examples of this is children. Children are dependent on their parents to care for them.
What are dependencies in project management?
A project dependency refers to a relationship between two activities or tasks. The completion or initiation of one task or activity depends on completing or initiating another task or activity. This relationship between the two tasks or activities may also depend on time or logistical factors.
For example, let's say that a client has sent an order to your company. You're to fulfill this order, charge the client for the order, and send the order off.
But, you can't fulfill the order until you have the product. You can't charge the client until you know you can fulfill the order. You can't send the order off until you've packed the products.
All of these relationships are dependencies. You can't complete one task without beginning or completing another.
Terms related to project dependencies
Before we get into the intricacies of project dependencies, there are some terms that you should know first:
- Lead vs. lag
- Critical path
A constraint is a restriction that exists on a task. A constraint may prevent your team from completing or executing a task. Here are some examples of constraints:
- A lack of resources
- A shortage of available time
- An insufficiency in experience/expertise
Constraints are notable because they may cause project dependencies.
For example, let's say that you have three people working this Friday. But, you have five tasks due on that day. You have a human resource constraint that has caused a project dependency.
The employees must complete one task at a time. Therefore, the ability of the employees to complete one task depends on their ability to complete the previous task.
Traditional project management recognizes three main types of constraints:
Most professionals view these constraints as a triangle, with each constraint representing a side of the triangle. The area of the triangle represents the quality of the product that you're making.
If something alters any of the constraints, it will change the quality of the product.
By reallocating resources, the project manager can use their project management skills to help ensure that the final product will be of high quality.
Lead vs. lag
Lead and lag are both terms that are related to dependencies. They sound similar, but they are different. In fact, they're opposites of one another.
A lead is the duration of time that you can advance or accelerate a successor activity as related to a predecessor activity.
For example, let's say that you have task A and task B. Naturally, task B has a dependency on task A. More specifically, the two tasks have a discretionary dependency, meaning that starting B after completing task A is not required, but it is best practice.
Because of this dependency, let's say that you schedule task B to start when you've completed task A. For the sake of this example, your first day working on task A is today, and you'll be done in ten days.
If you start task B five days from now, task B has a 'lead' of five days.
On the other hand, lag refers to the time you can delay a successor task compared to a predecessor task. This makes tasks and projects draw out longer than they should.
Since many projects are on tight time constraints, professionals do not generally consider lag to be a good thing.
Regardless, it's crucial to note lag so that your team can fight against it and recover from it.
A critical path is the longest chain of dependent tasks that exist within a project timeline. Because this chain is unbroken and sequential, altering one thing within this chain could directly impact the project's deadline.
In other words, the critical path is a chain of tasks that could negatively impact the rest of the project.
Before starting a project, you should take the time to identify that project's critical path. Identifying it ahead of time makes it easier for you and your team to face it head-on later.
The more intentional you are with completing the tasks along the critical path, the better your team's outcomes will be.
The types of dependencies in project management
To adequately approach project dependencies, you need to understand the kind of dependency you're facing. Each type of dependency has its own needs. Therefore, you'll need different strategies for those needs.
Let's look at each type of project dependency in-depth and talk about how you can approach each one.
For each example, we're going to look at imaginary tasks: Task A and Task B. For the sake of these examples, task A is the predecessor task, and task B is the successor task. This means that task B would typically come after task A.
The end goal is to be able to run down your project management checklist smoothly.
Causal/logical dependencies are one kind of project dependency that you can't avoid. These relationships come with the project that you're completing. Therefore, there is no way around them.
With these dependencies, Task B must come after Task A logically.
Therefore, you must plan for and expect these dependencies. Planning for them can help projects run smoother. Just make sure that you stick to your plan as closely as possible to prevent any lags.
As you may be able to tell by the name, resource-based dependencies run on resource constraints. These may include not having enough people, time, knowledge, and more.
While there are ways to get around resource-based dependencies, it can be challenging to do so. In order to battle these dependencies, you need to address the lack of resources that is causing the dependency.
This may mean that you need to hire outside help or consult an expert.
When it comes to battling resources like time, you can use one resource to remedy another. For example, you may not have enough time to finish Task A by this Friday. But, if you assign two more people to the project, you'll have plenty of manpower to overcome and solve the time constraint.
Then, you can move onto Task B.
Preferential dependencies are those project dependencies that you make yourself. Yes, we make our own dependencies. But, this isn't necessarily a bad thing.
Preferential dependencies are those relationships that we create among tasks. We decide that one task comes after another because that relationship makes sense in our minds. For example, you may prefer to complete Task B after completing Task A, but you don't have to do it in this order.
You can ignore these preferential dependencies, but it will likely cause harm to the project. Sometimes, waiting is a good thing. It may completely change the outcome of a project.
So, the bottom line is that you don't want to ignore preferential dependencies simply because they're optional. You should see them as necessary dependencies to assure the quality of your final product.
A finish-to-start dependency is the most common project dependency. In fact, it's the most common dependency in all fields.
You may refer to a finish to start dependency as an FS dependency. These kinds of relationships are logical. With this dependency, task B cannot begin until you're finished with task A.
There is no overlap.
You will start task B after you finish task A. Therefore, the timeliness of task B depends on the timeliness of task A.
You may also refer to a start-to-finish dependency as an SF dependency. These dependencies say that Task B cannot finish until Task A has started. Once you start Task A, then you may finish Task B at any time.
You may see this kind of relationship with deliveries. You cannot bill the customer (Task B) without initiating the creation and packing process of the product that they ordered (Task A).
The start-to-start dependency, or SS dependency, says that you cannot start Task B until you've started Task A. Once you've started both, they can exist in parallel, and either can finish at any time.
The completion of one task does not depend on the completion of another.
SS dependencies usually come about as a result of resource-based constraints. Let's say that Task A is a Task that requires monitoring rather than active doing. Once you start Task A, you can then move on to Task B.
If you hadn't started Task A, you wouldn't be available to help with Task B. Therefore, you are the human resource constraining one task from completion.
Finish to finish dependencies (FF dependencies) refers to instances in which you cannot finish Task B until you've finished Task A. You do not need to finish them simultaneously, but you cannot finish the successor without finishing the predecessor.
The outside-inside dependency grid
The outside-inside dependency grid lays out the relationships between internal and external forces by both the company and the project itself.
Let's look at the different kinds of task dependencies that come about with each scenario.
Company in-project in dependencies
Company in-project in dependencies refer to sequential project tasks. These are the linear tasks that come one after another.
In these situations, task B comes after task A. There is no overlap.
Company in-project out dependencies
These dependencies refer to links that tasks may have to other projects. In other words, the task of one project depends on the task of another.
For example, you may need to complete a task in Project A before you can start Project B.
Company out-project in dependencies
Company out-project in dependencies refer to tasks that third parties need to complete. You may hire a contractor or a computer software developer. You depend on whatever product or service you're hiring these professionals to do.
Even though the third party isn't a part of the official project team, their work still affects the project's final outcome.
Company out-project out dependencies
Company out-project out dependencies refer to health and safety standards that your company must meet. These are important to your team finishing the project, even if you may not think about this dependency often.
It would be best if you had a sturdy building to work in. If something were to happen to the company building, you might need to suspend the project.
Even if all of your project management tools are online, you will have an adjustment period if the team isn't working together at the office like they usually do.
Hopefully, you've taken the time to track down some of the dependencies in your projects. Once you've done that, you can get to work managing these dependencies and bettering your projects overall.
Engage with stakeholders and brainstorm some of the risks that you may encounter if a dependency were to go off course. The more you understand dependencies in project management, the better fit your team will be to address them.
So, what are you waiting for? Get started today and leverage TrueNxus, the best online project management software.
Try a free two-week trial today!