Useful tips for successful project dependency management

If you are a project manager responsible for a project, big or small, it is almost certain that you will you need to do some level of dependency management. You don't just need to do it, it is also one of the most important responsibilities of a project manager. Not handling dependencies properly can easily lead to problems that require urgent intervention close to delivery. In my experience, this is the number one cause of project failures related to execution.

Recently, I was responsible for a complex project that changed user accounts in a way that affected basically all products (12+) and their applications (100+) in the company. It was delivered without any issues coming from dependencies. At the same time, there were other projects running in the company that affected my team's applications where urgent intervention was necessary.

I thought it could be useful to share what I learned while managing my project, what worked for us.

But first of all, what is a dependency? I like to refer to the group of people who are full time assigned to my project as my "project team". This includes also the project sponsor and some stakeholders. Every other person and teams are dependencies. There are many type of dependencies (including ones that I just need to keep in the picture), but for the sake of simplicity, let's focus on dependencies that need to deliver something for your project at one point during execution. This can be implementation, testing, documents, etc.

Know your dependencies

I am likely stating the obvious, but I don't always see people treating this part seriously. You need to know who your dependencies are. I always create a confluence page with a table where I list

• The name of the dependency
• The point of contact (PoC) of the dependency
• The reasons why there are a dependency

I often follow up with the PoC and/or with their manager in advance to make sure I can rely on them.

It is important to create this page early in the project, review it with your project team, and adjust them during the project. In my case, PoC changed as they switched responsibilities, but the list was always up to date and something I could reach out to.

You are end-to-end responsible

Dependencies are abstractions. The good thing of this is that you don't need to know how they internally work (your cognitive load handler is happy), and the bad thing is that you often really don't know how they internally work.

The worst mistake you can make is to make assumptions ("this can be implemented fast", "they will release this change in 1 month, I am sure", etc.). If you can't help yourself, make pessimistic ones, a healthy pessimism can be actually helpful.

Make sure you don't "fire and forget" by making a request, and assuming that it will be done. Follow up on the completion, track the delivery. In my project, we actually installed applications and tested special accounts to make sure that we will not step into an issues during delivery.

It can feel overkill, but let's go back to project management basics: project managers are end-to-end responsible for their projects. It doesn't matter if a project fails because of a dependency (pointing fingers isn't a healthy attitude anyway), no project manager want to find themselves in an incident during delivery that needs to be solved by people outside of his direct influence.

The last thing I would like to mention is motivation. We project managers can think that our project is treated with the same priority in dependencies than it is treated by us. But that is not the case. Most dependencies have to deal with multiple projects and responsibilities, they might understaffed, and/or lack the context. When they don't deliver something properly it is not because they don't care.

Long story short, don't make assumptions and track end-to-end delivery.

Chose your communication properly

Efficient communication in projects can be a topic of its own, and I still don't know how to do it well.

First of all, find a good way to update your dependencies. Make sure you don't over-communicate otherwise they don't read. But also don't do radio silence otherwise they forget. Unfortunately, you also need to optimise your time, you cannot keep customise the connection for each dependency. The best is if you make dependency groups based on the audience, and write your update per group, but it is still an art.

Write a document that briefly describe your project. That helps people to come into context quickly. Remember, your project is just one of the many for your dependencies. Context switching overhead is real, so the easier you make your dependencies to pick up the thread, the more likely they will do it.

If you need something specific from a dependency, write a spec and share that. Your PoC might not the one who works on your request, and passing your request to someone else will happen much quicker if you make it easier for you PoC.

If you need a task to be done by multiple dependencies (e.g., testing a new account type in different applications), write a public document about the task and which dependencies need to complete it. It doesn't just help you to track the progress on high level, but it also helps your dependencies to communicate with each other, and it can create a tiny group pressure to finish their part.

Give heads about requests early weeks/months ahead. It doesn't always make a difference, but sometimes dependencies plan with it, and even if they don't, the fact that you started the communication early makes another tiny pressure on completing your request as it was not a last minute one.

Use email when you need trace, use chat/coffee talk to ping. When you get no answer or rejection, ask when can you follow up. If a delay is justified (priorities, etc.) it is not the end of the world. If the reason is clear and communicated, the delay in the project is not a problem.

Last but not least, communicate deadlines for your requests. Remember, project plans change all the time, your dependencies likely do not follow your project, so they postpone your request.

Give helping hand

One of the best way to ensure your dependencies deliver what you need is reduce the work they need to do.

Give them an implementation that they can review, write a draft document they can finalise, make screenshots. I personally wrote Knowledge Base articles that were heavily used to create the final one.

But remember, the accountability is still on their side, they have to approve the work, and deliver it. And your responsibility is to make sure the delivery arrives and it is what the project needs.

Vitamin B

Vitamin B is casually referred to as the power of connections in German-speaking regions (including Switzerland), where the "B" stands for Beziehungen (relationships, contacts, or networking).

I mentioned it late, but don't underestimate the power of the connection you build up with your dependencies before and during your project. Treat their needs in mind, be open to their situation goes long way making the magic happen at the end.

Delegate it

Regardless of Vitamin B, successful dependency management is ultimately about discipline. You need to setup your request for success that require preparation and disciplined follow ups.

Dependency management (among meeting moderation) can be the best task for delegation in a project. It doesn't just reduce the cognitive load on the project manager, it can also help a lot for others to grow.

I delegated the QA dependency management of the project to a test automation engineer that he delivered flawlessly.

Bonus: know when to escalate

Dependency management is by definition lateral management. You have direct control over your project team but you have requests for your dependencies.

When things don't move, inexperienced project managers feel the urge to escalate the request i.e. involve the mangers of the dependencies and/or theirs. It feels innocent (just a CC in an email), but I rarely saw it necessary or working. It is dangerous.

Unnecessary escalation doesn't only burn managers time, but also damages relationship and makes you look incompetent.

In almost all cases, things could be shorted out with in person talk, openness to understand each other problems, and working out the priorities.

Having said that there are a few cases when escalation is needed, and in those cases don't hesitate to escalate quickly.

Good reasons for escalation:

• Conflicting priorities without having the context to resolve them: If they are not clear, the only working way is to bring everyone into the same room and make a decision. This is the most common escalation, and it is not harmful at all.
• Uncooperative behaviour: Sometimes it happens, but make sure it it cannot be resolved on your level, i.e. it is not because lack of context or unclear communication. Talk in person before making this step.

Note: feedback to managers (positive or constructive) is not escalation.

This post is longer than I planned, but I hope it give some tips that you can use in your project dependency management. What worked for you?