The many layers of dependencies in today’s complex projects create plenty of opportunities for collaboration. Unfortunately, there are often no guidelines in place for facilitating this cross-group collaborative work. Dependency management, in which one group provides a software component to be utilized by others, is one key area where collaboration skills play an important role. Some simple rules can facilitate effective dependency management skills.

The concept of dependencies is controversial among developers. Development teams are often reluctant to take on dependencies because they feel they will lose control of their projects. No one wants to partner with a team that won’t listen, has produced poor quality in the past, or is constantly delivering late.

Another roadblock is the "not invented here" syndrome. This happens when individual developers think that only they are capable of writing exactly the code that suits their needs. They believe they can duplicate any code that a dependency might create, and do it fairly quickly.

Despite these concerns, dependency management can have enormous benefits if handled properly and integrated wisely into your project. Consider the following scenarios: there may be more than one group within your company duplicating certain functionality. Thus, consolidating duplicate efforts frees up your resources to work on higher-level features. Moreover, a focused and dedicated dependency team can produce a component superior in quality and functionality because it has the time to do a complete review of security, reliability, internationalization, and performance. Don’t forget that the support and maintenance of shipped code can be a greater cost than the initial development. Happily, your dependency can take all that off your hands.

I recently participated in a project where one of the features required files to be downloaded across the Internet in the background so as to not disrupt ongoing critical processes. We needed to throttle the network bandwidth usage and also withstand intermittent connections. After some investigation, we found another group producing such a component, so we took that on as a dependency, saving ourselves a great deal of time and cost.

Dependency-taking requires clear communication, however. When you first set up a dependency, all teams involved have to decide how they will balance the governing of the joint venture. This will reduce the cost of that interaction and help things proceed in an organized way. The following are some guidelines that can help in creating effective dependency management:

Authority Who makes what decisions? Does anyone have the final say? What is the escalation process?

Roles Clarify the expectations and determine who is responsible for what.

Goals/Value Define what success looks like. Drive for alignment. Enumerate and explain the risks.

Communication How and what will be communicated? Establish meeting schedules, e-mail protocols, and Web site access.

Accountability How will you track progress? What is the process for fixing mistakes?

Engineering System Create an issue database, source code control, build, setup, drop points, and quality measures.

One of the biggest problems with dependencies is making sure that you get what you really need, when you need it, and at the level of quality you expect. If you are on the client side of the dependency, you should make sure to get your requests (features, bugs, issues) placed at a priority you are comfortable with and that both sides agree upon. Get a commitment of support and maintenance from your dependency’s management. You should also participate in their internal reviews and status meetings so you can track their quality.

Then once the dependency gets started, be careful not to incorporate any aspect into your build until it has reached an acceptable level of maturity and stability. Nothing is worse than constant change underneath you. Supplying your own test suite helps your dependency verify it is not breaking your code. In fact, the ideal situation is when dependencies are more stable than your code. If a problem arises with your dependency, make clear to them the impact it is having on your schedule.

You can make dependencies work for your organization by practicing proper management of the process. Never assume that the dependency can read your mind. Keep things transparent throughout the process.