The team is ready to work but cannot proceed. Something is standing in their way: a security review, an architecture decision, information from another team, or an answer from someone out of the office. The answer might only take an hour. Getting to it might take several days. I’ve seen this happen often enough that I no longer believe that waiting is just incidental to the work. The time spent waiting on the dependency is part of the cost of delivering the project.

That cost is often larger than the activity itself. There is coordination involved. Context has to be explained. Calendars have to align. All while the project waits. The team may move on to other work which costs time in context switching. They may proceed based on an assumption and then find out that their assumption was wrong. I’m not arguing that all dependencies are wrong. Most were created for good reasons. Risk management and regulatory oversight are two. Specialized skills are another. We know that we cannot replicate these skills within the development teams, and we shouldn’t assume that they could handle all of them without help.

I recall a time I rejected a dev team’s architecture when they wanted to directly connect their system to the billing system. I required that they build an abstraction layer so that we could change either system independently in the future. Since they assumed I would approve, they built the interface while waiting for the architecture review. My decision created roughly two weeks of rework. I had information that the team didn’t have which made it easier for me to justify the cost of the rework.

The more subtle version of this occurs when several dependencies start to stack. At a different organization I encountered a situation where a team had a complete solution for a small operational problem. They were simply automating the manual transfer of a report from one system to another. No governance function had expressed a particular concern with the project. However, the process required it to pass sequentially through six different teams. Each queue took one to two days to pass through and two even required waiting for a weekly scheduled meeting. A small piece of low-risk work ended up taking weeks longer than the work itself.

Project teams can see these delays. They live through them all the time. The supporting functions rarely see the accumulated costs of all of their processes. Does the dependency still need to exist? How much involvement is really necessary? Is the cost justified by what the dependency provides? These decisions belong at the organizational level. We may not require the same depth of involvement depending on risk, timing, or impact. Removing a dependency may reduce delivery time and at the same time increase risk. Keeping it may continue to impose a cost that the organization doesn’t even know it is paying.

Dependencies are a normal part of organizational design. The cost of a dependency isn’t necessarily waste, but it isn’t free either. It may be worth asking ourselves:

Does the dependency still provide the organization enough value to justify its cost?