6 August 2015
In a world without dependencies, projects would exist in isolation, wouldn’t need help from an internal/external teams or vendors, wouldn’t be affected by business changes, and requirements would remain constant. If this were true, project and program managers could just skip managing dependencies.
In reality, this isn’t true and it’s why PMs must spend more time and energy than they’d like dealing with complex dependencies. In real world projects—especially software projects—teams usually rely on other pieces of work being finished/started before they can do their own work. So even if you’re lucky enough to be a part of a project with no dependencies, chances are some other project will depend on your team’s work to achieve their goals.
So since dependencies are a fact of life for program managers, you might as well be aware of the many ways they can cause trouble for your program. Here are a few of the core problems we’ve noticed with dependencies.
Making dependencies visible (and then managing them across projects) is probably the most important problem(s) we’ve encountered.
Traditionally, people have tried to identify dependencies beforehand using help from the most knowledgeable and experienced software professionals on their project. But no matter how hard they try, with software projects there’s always something that’s missed. Due to the ever-changing nature of software products, the majority of dependencies are identified during implementation. With the current state of tools, these dependencies are too-often made visible via some kind of half-baked solution (Excel sheet, stickies on a card wall, emails, blocked stories in the backlog, etc).
The current state of tools results in managers spending a lot of time doing things manually, whether it’s making a list of a projects’ dependencies, info-gathering to understand a dependency’s effects on the program, or even just trying to grok the resolving teams’ methodology. Each manager may use a different solution, which only compounds the difficulty of managing the dependency efficiently.
The dependency management process may drag on for days and necessitate help from various sets of people. This results in delays that can adversely affect the people, projects and programs involved. A real solution to this problem requires end-to-end visibility on a dependency from when it’s raised until it’s resolved. This visibility should be not only for an individual project, but also across projects and across different roles so that all can help in the identification, scheduling, tracking and resolution of the dependencies.
Often, just because a cross-project or cross-program dependency has been raised does not mean the resolving team is blocked from doing their piece of work. Also, the resolving team may not fully understand a dependency’s importance to the team raising it, or why it should be prioritised higher than another dependency. Teams are limited by their own unique priorities: they’re following their own mandates and tracking toward their own milestones, which certainly are high-priority for them. Usually, teams on the same dependency resolve their competing priorities through either yielding to the team with biggest voice or influence or utilizing good relationships with coworkers to work things out directly.
For those favoring resolution, having a list of all the dependencies raised for a team, all in one place, would be very helpful. This would facilitate a meaningful conversations between project/program managers of different projects so they can prioritise work in a meaningful way. It would also help program managers prioritize if they could filter dependencies based on criteria they choose (e.g. highest scope blocked, feature release date, request completion date, or any other custom filter).
When it comes to resolving dependencies, what works for one team does not always work for others. Teams are structured differently and many times follow different project management methods and principles. If separate teams try to follow prescribed schedules or cadences, they will find themselves quickly drowning in a barrage of meetings in an attempt to coordinate their schedules and cadences. No one enjoys having meetings all day, and it hampers actual production and adversely affects delivery. Mandating process may work for smaller projects but it often fails (or consumes a lot of time) in software projects that are larger, more complex, or have a lot of moving parts. Hence for bigger initiatives, teams trying to reduce or remove dependency-related problems should pursue a process-agnostic solution or integrate structures followed by the component teams/projects.
While these are a few of the core problems with managing dependencies, in the next blog post I will talk about concrete steps a team can take to minimise dependencies and better manage them.