When it comes to managing dependencies, there is no work you can do without having to interact with someone or needing something that others have built … or even worse, that others are building … or even worse, that others are planning to build … or even worse, that others are not even planning to build … or even worse, that others do not want to build. Managing dependencies is anticipating external needs and to have them readily available to do your job. Having said this, we all have heard that it\’s not just someone\’s genius that matters, it\’s also their preparation, know-how, experience, contacts, communication, teamwork, and timing.

Every software project has dependencies, which could exist on many different levels. Not identifying them, or not managing them properly, would most likely result in the root cause of a project delay, program failure, or loss of business.

Dependencies should be:

1. Owned: the main responsibility is with the manager of the project. However, it works best if every person in their role within the team understands the importance of raising and managing project dependencies. It should be an integral part of the team discussions.
2. Identified: they can easily go unnoticed if there is no specific task or sufficient time set aside in the plan to identify them. You should never identify dependencies alone, it\’s a team effort! Referring to other projects\’ experiences from the past and the industry is always good practice too.
3. Communicated: the team should have a tool for communicating dependencies. Ideally, the tool will be shared across the organisation. This is really useful for aligning different roadmaps, work streams, or project plans in real time. This would lower the effort, cost, and time needed for managing dependencies.
4. Negotiated and agreed: as we have already mentioned, this could be as simple as buying something that someone else is eager to sell. Alternatively, this could be having to convince other teams, Product Managers or Directors, to incorporate something that is not in their roadmaps.
5. Managed to closure: the team could be great at identifying what is needed and who should provide what by when, but if we do not follow-up, all the effort is lost. The responsibility of tracking a dependency always resides in the team that is expecting something from others. 

Dependencies should be managed at every level of the organisation:

As a Developer, you may have experienced a situation of starting your work for a given iteration knowing that something is not quite right with your assignment. If you had asked yourself questions like the following, then your team may have failed at dependency identification or tracking.

• Should I contact the person from the team who manages another microservice to tell him that I need a change in his API behaviour to have some working code on my end?
• I was asked to create this button but I am not able to find the backend functionality which does the work …
• Hmm… I thought we had a license for this … or, I\’ve got a license expiration notice!
• Should I use this library from an in-house platform team, or another nice open source 3rd party vendor to do my work?

You may be tempted to say it\’s someone else\’s responsibility and that conditions are not met to do your job. You are right on the second statement. However, you are also part of a team and, as a developer, you have to help your leads and participate actively on early dependencies/risk identification/planning sessions and continue with a \’dependencies identification\’ mindset throughout the project.  

As a Team Leader or Engineering Manager, you need to have sessions early on with your team to identify dependencies and risks (which would in turn help identifying dependencies). Always keep the iteration work limited to what you already have available. Dependencies for work items assigned to an iteration should be closed beforehand. In case they are not, it is better to move them to a later iteration. You will be saving time and resources. The use of spikes and enablers to get dependencies resolved in advance by research, design or prototyping is also useful.

Using SW tracking tools with add-ons assisting on dependencies management is always a plus. Knowing in real time that a dependency on another team has been shifted to the next sprint (or release) is invaluable!

Contract testing is another way of managing dependencies among microservices. It will not resolve all of your problems from day one, but it will help out fostering communication between teams and foster team building.

As a Program Manager or Director, you may have experienced having to incorporate new functionalities in a component from another product in your company. As we mentioned earlier, this could be a piece of functionality they do not even have in their roadmap. And it would be even more complicated if the product at hand is not part of the portfolio your product is part of. 

How do you achieve that? By dusting off all of your negotiating skills to reach an agreement knowing that something greater could be built that would benefit both teams and the organisation. And also, if at all possible, by the next quarter! 

It will not just be negotiation skills that you need here, it is knowledge about the business you are at and some very good communication skills, some skills that as Program Managers, we must be trained on.
The good thing is that you do not need to master all of these skills alone. Remember, managing dependencies is a team responsibility. Program managers must be assisted on these discussions by Product Managers and Engineering Managers/Directors. When working on a different portfolio, it would be more beneficial that the Product Manager brings this up in his portfolio discussions with other products, and the Engineering Manager prepares all of the technical backup information required. Sometimes, the architecture team\’s blessing and assistance is required. The ideal situation would be one where periodic roadmap discussions take place with all of the relevant stakeholders present to align portfolios and dependencies. The issue of this however is that even in these situations, presentations and discussions can be long, bore most of the audience, and actions are poorly tracked without follow ups. 

As the head of a PMO, you would come into the picture to help in these periodic roadmap discussions given your PMO has, or should have at least, the view of the whole organisation and what is going on across each program and strategic initiative, as well as the overall objectives. This begins by organising the arrangements for the meeting, and then hosting and moderating it. The takeaways from the sessions should include listing all of the cross-dependencies (before and after the meeting) to help align the timelines of the different roadmaps and programs. This does not end here. It\’s the starting point of a train of releases from multiple programs and products hopefully sharing non-conflicting objectives. They should be prioritised, planned and executed, where things will change, dependencies would slip, and new dependencies will be found.

Complexity is such that the most common situation is failing at dependency management at any given time. That\’s why we need to give it the time and consideration that it demands, considering that working in individual silos is great for getting your job done, but it would affect the performance as a whole.

After all, who is managing dependencies here? 

Like many other things in life … the big three … “Me”, “Us” and “It”.

1. It is our own responsibility at whatever level we are in the organisation to go beyond our immediate needs, empathy to take time to interpret others needs, dedication to follow the processes in place with the proper use of organisational tools.
2. It is an organisational culture to embrace dependencies in a mutual understanding that there is a greater shared goal than the individual program/product objectives alone by organising teams and prioritising towards objectives.
3. It is also a systemic approach to be followed with the help of processes and tools.