Dear Elizabeth: The project I am working on is quite complex. Our work overlaps with that of other teams, plus there are a few things in the business that might have an impact on what we are doing. Some of these dependencies might have significant impacts on the project. How do you recommend managing dependencies that put the project at risk?
First, have a virtual high five for identifying that you’ve got dependencies on your project that could cause a problem. Knowing they are there is the first step to being able to manage them!
For the benefit of readers who haven’t come across the term before, a dependency is the relationship that defines the order in which tasks are carried out. Task A is dependent on Task B if the start or finish date of Task B must be reached before Task A can be started.
It’s less complicated than it sounds!
There are a few things to do here to make sure that you can adequately manage the impact of dependencies.
1. Identify the Types of Dependencies.
Let’s start by identifying the types of dependencies you have on the project. That will give us a head start at looking at how they can be best managed.
There are several different ways of thinking about dependencies. The easiest way, and the way most scheduling software works, is to think of the impact on your timeline.
Tasks can link to each other in four common ways:
- Start to Start: The start of one task links to the start of another task; i.e., both tasks start at the same time.
- Finish to Finish: The end of one task links to the end of another task; i.e., both tasks finish at the same time.
- Finish to Start: The end of one task links to the start of another task; i.e., the tasks happen one after the other in a sequence.
- Start to Finish: The start of one task links to the end of another task; i.e., the first task must start before the other task can finish.
You can set these types of dependencies within your project management software.
However, these sequential, task-based types of dependencies are not the things that will derail your project. You can use the same types of dependencies on your schedule to record things that might influence the project from the outside.
For example, create a milestone for a task that has to be finished on another project and link it with the correct dependency type to the relevant task on your own schedule. You don’t want the other team’s complete plan in your plan, but dropping in a key milestone is enough to flag up that there is something external that has the possibility of affecting your timeline.
That brings us to the next way of categorizing dependencies, which is more useful for the kinds of things that could be risky for the project.
Dependencies can relate to the Project or the Company and can be “In” or “Out.” The table below explains more.
It’s the dependencies that are out of the project and fall into the Company category that have the greatest possibility of presenting a risk to your work. These are things that are not in your control and that you are unable to fully influence yourself.
2. Consider the Risks.
Now that you know what your dependencies are and the areas that they affect, you need to consider the risks they present to the project.
You already have tool to do that: your risks log.
Look at each dependency and work out what their risks would be.
For example, if you were building an app for a client, you might be reliant on another project’s completion in order to reuse the specialist code they were creating. In this situation, there is a risk that their work doesn’t finish on time or that the code isn’t reusable after all and you have to start from scratch (adding time and cost to your project).
Go through the risks assessment process like you would normally do. Add the risks to your risk management software. Allocate them an owner and choose what you are going to do to manage the risks.
This gives you transparency and a decent record of what you are going to do about the potential problems.
Personally, if the risks are things that relate to what another team is doing, I would want to keep an eye on them myself as the project manager, even if someone else was named as the risk owner. These kinds of dependency-driven risks are very important to manage.
So, how do you manage them?
3. Talk to Your Colleagues.
The biggest single thing you can do to help address the risks caused by dependencies is to talk to people.
When your project relies on someone outside the project doing something, or telling you something, go talk to them. Let them know that your project is dependent on something they are doing. They might not have a clue that their work is going to affect yours. Tell them what their actions mean to you and why you care about how their work is going.
As you all work in the same business, let’s hope that your strategic goals are all aligned. There is no reason why they shouldn’t want to help you out through good communication and collaboration. Keep them updated with what’s happening on your project and ask them to do the same for you. Together, you should be able to manage the flow of information back and forth to keep both projects working smoothly.
If the dependency relates to something a third party is doing for you, such as an agency delivering wireframes, then the talking principle still applies! Check in with them regularly. Talk to your counterpart in your company who works with the agency regularly, so they understand the impact of any delays.
When Risks Become Issues
The great thing about taking your dependencies and managing them as risks is that you are actively working to stop them becoming problems for your project. However, if they do become problems, you already have a way of dealing with them. They become project issues. You may need to change something to accommodate the new problems, but between your issue management and change management processes you’ll be able to come up with a new plan to address the situation.
You’ve taken all the right steps to raise awareness of the dependency and what needs to be done so it doesn’t become a problem, so fingers crossed that your project will proceed without a hitch.
Elizabeth Harrin is a project manager, author of several books, anda mentor. Find her online at her blog,A Girl’s Guide to Project Management
