Dependency Management

What is dependency management?

Dependency management involves identifying and managing the dependencies that exist between different components or systems within a project or program. It also helps minimize the risk of delays or disruptions caused by dependencies and improves the overall reliability and maintainability of the project. Dependencies can be internal, such as dependencies between different modules or components within a system, or external, such as dependencies on third-party libraries or services.

The initial discovery of these dependent complexities should be done in the planning phase of a program. However, if you jump into a struggling program midflight, then be aware that poor dependency management practices are often a culprit for low-performing programs.

Note: Managing complexity is really at the heart of what you do as a technical program manager.

Complexity invites risk, and one of your major jobs is to reduce or eliminate risk. One major contributor to increased complexity is dependencies across many teams, systems, and services.

The value of being a technical program manager

You are not just any program manager. You are a technical program manager.

Every TPgM should have some level of domain expertise within the realm of software engineering. This is critical so that you know how to effectively partner with your engineering counterparts by getting into detailed architectural reviews, getting involved with code reviews, and knowing what type of analytics to look for or ask about.

You should feel comfortable diving into an architectural diagram and examining the potential impacts on other systems and services. If you're not there quite yet, that's okay. Take time to build that skill.

Without some level of domain expertise, you will lack the ability to map dependencies across systems and services. Major risks you must ensure are taken care of may go unnoticed. Your ability to climb the learning curve of new technologies might be more difficult because your software engineering fundamentals aren't solid.

We'll explore the expectations of technical depth and how it relates to technical breadth in "Foundation III: Technical Breadth."

Dependency management process

• Discover dependencies early: The earlier you can identify dependencies between tasks and projects, the easier it will be to manage them. Make sure to involve all relevant stakeholders in the process of identifying dependencies, as they may have valuable insights.

• Document dependencies: Keep a clear and up-to-date record of all dependencies between tasks and projects. This will help you stay organized and ensure that you don't overlook any important dependencies.

• Prioritize dependencies: Some dependencies are more critical than others. Prioritize the most important dependencies to resolve them as quickly as possible.

• Establish dependency ownership: Each dependent system or service should have a dedicated ownership team or individual. Now is your time to identify those teams and proactively contact them. You need to drive buy-ins from those teams for changes to happen later in the program.

• Communicate dependencies: Keep all relevant stakeholders informed about dependencies that may affect their work. This will help prevent delays and ensure that everyone is aware of the impact of any changes.

Dependency discovery

There are two pragmatic methods to discover complex dependencies:

• Automated discovery

• Manual discovery

The best place to start is using any type of automation to discover system or service-level dependencies. The most common type of automated discovery is the use of analytics.

Identify an initial critical system that will be changing the program. Any healthy system implementation will have some type of analytics or logging associated with it. With the initial system identified, look at the access analytics or logs to discover immediate connections. Doing this will help you understand the number of dependent systems and the scale of change.

Once you have an initial understanding of automated methods, following it up with manual discovery is always a good idea. Why? Because in any analytics pipeline or logging system, errors are possible.

What does manual discovery look like? It's quite straightforward:

• Validate what you learned from automated discovery. Reach out to the teams that own the services identified to make sure they really own them and are aware of the impact.

• Talk directly with domain experts who are familiar with the common and nuanced dependencies.

Documenting dependencies

Initially, mapping dependencies may occur in a loosely structured document, such as a Word or Google doc.

However, as your program matures, you'll want to mature your dependency management by visualizing them. There are three key best practices you should explore:

• Architectural diagram: This helps clarify relationships and ownership.

• A comprehensive Gantt chart: This helps clarify the sequencing of complex dependencies.

• Linking within a live tracking system like Jira: This helps clarify on-going progress.

Regardless of where these dependencies are tracked, be aware that it should be a living document. You should check in regularly with your dependency artifact to ensure you're working with all the right people and the document is still accurate based on what you've learned through program progress.

Prioritizing dependencies

Not all dependencies should be treated equally.

You will quickly notice which dependencies matter most. When you prioritize dependencies, you also prioritize which relationships to spend time building first.

For example, your program may impact an API layer somewhere in the tech stack. If those changes to the API layer impact all the other API clients, then you'll see how quickly dependency management can sprawl to potentially dozens of other teams.

You should prioritize dependencies by looking at:

• Their impact to other teams, services, or customers.

• Whether or not this dependency is on the critical path for the program.

You may not know the critical path right now, but identifying dependencies is all part of uncovering the critical path.

It is common for major dependencies to potentially become their own workstream since a significant amount of project or change management will be needed.

Establish dependency ownership

For any dependencies that exist, you should at least know the team and a point of contact on that team.

As you establish ownership, help them understand the program's purpose, how this dependency was identified, and what is expected from this person or team.

You can go back and reference the "Assembling the Core Program Team" lesson for tips to onboard new stakeholders. We will also cover this topic more in the lesson titled "Stakeholder Management" within the program execution phase.

Communicate dependencies

Each dependent team you identify becomes a stakeholder.

But remember: not all stakeholders are equal.

Some of these stakeholders will be 1st-degree stakeholders. You'll need continuous contributions from them.

Others will be 2nd-degree stakeholders who only contribute intermittently.

Lastly, 3rd-degree stakeholders only need to be informed. Perhaps you need their partnership to monitor for any unexpected impacts.

Make sure each stakeholder in the dependency groups know which category they fall into. This will help them gauge their commitment and align their staffing as needed.

Example of system-level dependencies

Let's say you're running a program where you need to drive a migration for a major data storage system. You're changing not only where the data is stored but also some of the data types as well.

In this example, the data is written from the first service, through the API layer, into data storage, read from an API layer, and utilized in another service.

At a high level, you should eventually get to a point where you visually understand all these relationships, as depicted below.

Build partnerships with each team that owns a dependent system or service. To identify the scope, impact, and scale of the changes that your program requires, partner with these teams and utilize their built-in analytics to automatically get a baseline for how much the dependencies sprawl.