Why Early Dependency Mapping is a Must

Does your product have a dependency map? What about your team? You should. Whether you’re at a startup or part of an established organization, understanding where business, project, and application dependencies lie is critical, especially to those of us who build product roadmaps and are tasked with making (hopefully wise) product decisions.In the early days of a product’s lifecycle, teams often beg, borrow, and steal whatever they need to ship; documentation is light, things are hard-coded when they shouldn’t be, and not everything is packaged up in clean, independent containers before it ships. For a short period, this is perfectly fine, but if left unchecked can be a recipe for disaster. Every organization, team, and product has multiple components and often those components rely on others to function.As products gain traction, they tend to get more complex; a feature here, a functionality there, and a few integrations sprinkled in. These more complex products require more ingredients than earlier versions of themselves. Over time, the number of cooks in the kitchen also increases, and many newcomers start off unfamiliar with how things got to their current state.Eventually, smaller specialized teams may form around specific features or aspects of the product, and additional products may be launched or spun off. Common services and components may get their own teams (or be forgotten about in the rush to keep shipping).At this stage in a product (and organization’s) development, it’s unlikely that any single individual can reasonably keep track of everything in their head. No whiteboard is big enough for every component and data flow in a well-established, sophisticated product, and at most organizations there is likely no single person responsible for the whole thing that doesn’t have a “VP” or “CXO” in their title.[Tweet "Tribal knowledge may be enough at first, but mature products need more to avoid potential disasters."]Despite growth, nothing operates in a vacuum. Requirements that need features that need requirements that need features… you get the idea. You want to build a new form that autopopulates data fields from a database that requires a new third-party data feed to be integrated with your platform, or something along those lines.This kind of go-forward dependency may be challenging for your project manager to schedule and your engineering team to implement, but it shouldn't be hard for you as the product manager to figure out. Once you know the three things need to happen before the feature is ready to roll, you can fit the new feature into your roadmap and your project teams can choose a path to develop, test, and deliver appropriately.

What is a Dependency?

A dependency is anything that a product, part of a product, project, user, partner, or a staff member relies on. This is a pretty big bucket, so here are some example categories:

• A common software component that multiple features rely on
• A piece of hardware that your software runs on
• A business function that the product relies on
• A data feed that is used by the product
• Third-party software (from operating systems to WordPress plug-ins) that your solution relies on
• Network connectivity and bandwidth
• Databases and storage capacity
• Any use case for the product

Depending on your product and your organization’s business environment, there may be some others that come to mind. Each of these areas must be investigated before new features are added, architectural changes are made, or environments are updated. Often, your findings will not only dictate schedules but also how your teams decide to build and test the components for the next release.“Discussions about what teams are impacted and what dependencies it creates should be discussed in the defining phase of product development,” says Michael Rutlege, a product manager at Audible.com, “At this stage architects need to be involved to understand the full product requirements and part of this requires them to look through what teams are impacted, but just as importantly how does the new enhancement create dependency. The impact and dependency maps need clearly codify these and track them for the teams so that they know where these dependencies are, who they are dependent on, and whether it’s a parallel or sequential dependency.”Unfortunately, not everyone may be as invested in identifying dependencies as you are, particularly if you are trying to unpack the implications of relying on components, systems, and functionality from a different part of the organization.“There may be a disconnect between your group and theirs,” write Adam Kerrison and Simon Woodward of BMC Software in an article on application dependency mapping, “Your group needs the information that the application experts have, so you are highly motivated to obtain this information. The application experts, on the other hand, already have the data they need (often in their heads) to do their jobs, so they may not be highly motivated to expend the time and effort required to help you. As a result, getting their attention might be difficult.”

Dependency Mapping at Salesforce

The larger your teams and products get, the more dependencies come into play. Salesforce, for example, is a huge software organization and as such they’ve made dependency identification a key part of each release cycle.“It is difficult to identify dependencies or negotiate commitments with other teams if those teams don’t yet know what they’re doing in the release. The Release Kickoff meeting acts as an important synchronization point for teams,” write Eric Babinet and Rajani Ramanathan of Salesforce in Dependency Mapping in a Large Agile Environment, “Our goal is to generate a high level of awareness of what teams are doing in the release, as we believe that this visibility will naturally cause people to think about and discuss dependencies.”After the Release Kickoff meeting, a representative from each Scrum team participates in a Dependency Identification exercise where they each go to the whiteboard and simultaneously draw two diagrams; one that shows what other teams need to do for them and one that shows which teams are doing something that will impact other teams.This leads to a discussion and further revisions of the diagrams on the whiteboard before each team representative gets a chance to discuss their dependencies with the rest of the group.

Use Case Investigation

While technical teams will do the bulk of the work when it comes to identifying how specific components and systems and hardware might be impacted by changes to a particular item, there are other areas where a product manager is far better suited to unearth some less obvious dependencies.Maintaining a dependency map is about more than just making sure things will keep working on the technical side, it is also about ensuring your business will continue functioning properly. This means identifying all of the scenarios that a product or system will be utilized, even if it is “off-label.”For example, a salesperson asks an engineer to create a dummy account on a staging server for a demo. Six months later, that salesperson is still using that dummy account during their presentations. If someone pulls the plug on that server or wipes out the dummy account data, you now have an unhappy salesperson who might not discover this until they’re floundering in front of a customer.There are also many process dependencies that are often not on the radar. Engineering teams, and product managers are ideally suited to identify these, document how they are interacting with the system, and ensure that there will not be disruptions to these non-customer users.Business processes that may rely on data coming from the product could include:

• Order processing
• Billing
• Order fulfillment
• Supply chain
• Manufacturing
• Operations
• Customer support

If a new development project is going to change those data outputs (providing more, less, different, or no data at all), other teams need to be informed and their corresponding systems might need some development of their own, or you might have to ensure that the old data formats are still being provided to these “legacy” systems.Product changes can also impact your sales team, channel partners, and distributors in unforeseen ways, including anyone performing integration or installation services for customers. Interviewing and documenting how these individuals are using your products in their everyday practice is one way to identify potential dependencies, which you can then surface to your R&D organization during planning.However, it’s unlikely that will uncover every potential pitfall, so another method you can use is proactively communicating out to the field what changes will be made, seeing if they are going to cause any downstream problems. This gives everyone the opportunity to raise their hand and say “Hey, that’s actually going to create some issues for me or my customer!” and you will have time to come up with a workaround before your next release ships and evolves into a crisis.

Risky Dependencies

Any time you rely on something that is not made within your organization’s “four walls,” you put your product at risk. Usually, these risks are small, but technology evolves, business models change, and company fortunes wax and wane.For example, many companies rely on the APIs of Twitter, Facebook, LinkedIn, and Google for specific functionalities, if not their entire product. All of these companies have repeatedly updated their APIs over the years, changing how much data is available or how it can be accessed.Hardware can also be an unreliable link in the chain. Models can be discontinued, firmware and drivers can be updated, prices can shift--leaving your company vulnerable if it has hard-and-fast system requirements, particularly for solutions that have customers installing and maintaining your system on their own hardware.

Should Dependencies be Avoided at all Costs?

Dependencies are not necessarily a bad thing and are many times unavoidable; relying on common software components is an integral pillar of effective scaling.However, relying on changes to the capabilities of common components can be treacherous waters for independently operating teams promising new functionalities to customers or stakeholders. Mike Cottmeyer, CEO of LeadingAgile, recommends the following rules for minimizing these situations:

1. Never commit to a feature the depends on a component capability that does not exist
2. Sometimes commit to a component capability on the near term roadmap
3. Rarely commit to a component capability with a hard date driven dependency.

Remember, it is not your job to solve every dependency issue, but as the person responsible for the products that ship (and the person telling executives and the market when they’re going to ship), it does lie with you to make sure these dependencies are identified early and often.

The TL;DR: Archive for the Future

If you have fully mapped your product’s dependencies, you have done a lot of work! Chances are, you will need to do it again in the future, plus other teams might also benefit from what you have discovered.Creating a knowledge base that includes everything you have found is a great way to ensure people aren’t reinventing the wheel the next time around. Now, instead of having to start from scratch, the next release can just check in with each stakeholder to see what (if anything) has changed since last time.