What is a dependency?

Dependencies have a direct impact on the progress of product development and arise frequently in cross-functional product teams. That’s why it’s so important that dependencies are mapped out and planned for, to avoid any disruptions to overall product development.

eBook

Roadmapping From A to Z

Read now

Examples of dependencies

There are four standard types of dependencies in product management. We classify them based on the relationship between the start and finish conditions of the two elements being compared. 

Finish-to-start dependency

For this type of dependency, one element requires the completion of another before you can begin it. This is common in iterative frameworks like DevOps, where the previous iteration needs to be completed before building the next.

Say you’re building a portfolio application. You’ll need to create some way of displaying photographs, but first, you need to make a process that allows the users to upload the pictures. You need to finish the upload function before you can start building the display. 

Finish-to-finish dependency

A finish-to-finish dependency requires both elements to be complete. The second element does not rely on completing the first, so you can work on both simultaneously. This dependency arises when the second element requires the first later in development. 

You’ll often find this dependency in physical products. For example, a computer will require memory chips and motherboards to be created. However, you can build each element without needing the other to be completed first. 

Start-to-start dependency

With start-to-start dependencies, you can build two elements concurrently, but you need to start one of those elements first. This happens when both elements require substantial work, but the second element requires parts of the first. 

For application development, this could include basic functionality and UI. The UI team can get started without waiting for the basic functionality to be completed, but they need at least one completed page to get started. 

Start-to-finish dependency

Start-to-finish dependencies are similar to finish-to-start in that one element must be completed before the other can be finished. This can be two concurrently running processes, but it requires the first element to be finished before the second can finish. 

For example, if you’re building user profiles and log-in functions, you’ll need to complete the log-in functions before linking user profiles to the correct account.

Challenges

Common challenges appear when dependencies are connected to external contributors. These so-called risky dependencies may occur e.g. when software from a third party represents a key component to your product or a task dependency has a constraint and its completion process cannot be forecasted. Another difficulty may be identifying dependencies in the first place. It is important to stay on top of them when a project gains traction and becomes more complex. 

Advantages of mapping dependencies

Visualizing dependencies asserts the task management and timeline of any project schedule. Especially when managing a cross-functional team it is crucial to substantiate the level of awareness by including dependencies and status reports into e.g. the product’s roadmap. However, there are multiple approaches to doing so. Whether depicting dependencies in a Gantt Chart, diagram, table, or with other means, it will enable the team to reevaluate commitment and object to impractical measures if necessary.

How to define a dependency in product management: a step-by-step guide

Defining dependencies is crucial to ensure your product development cycle runs smoothly. Follow these simple steps to ensure you manage your dependencies correctly.

Standardize the procedure

Dependencies can span different projects, so you need a standardized definition process to ensure clarity throughout development.

Define a plan and scope

Before we can look at dependencies, we need to ensure a clear, agreed definition of a dependency. Once everyone is on the same page, we can create a plan with clearly defined milestones linked to dependencies. 

Identify dependencies

The project manager now needs to identify the project’s dependencies based on the defined process. Dependencies should be captured for future reference and need to include who is responsible for delivery.

Collect data

Once dependencies are identified, they need to be validated. You can do this by collecting data from conversations with relevant parties.

Track and report the dependency

Continuous management is essential to ensure dependencies are delivered upon. Identification and validation should occur regularly to ensure they are still relevant. 

How to manage a dependency

Dependencies aren’t inherently problematic, but they do require a focused approach to product planning to reduce the risk of any issues. 

As products grow in features and functions, they naturally grow in complexity. This increased complexity means that knowing where dependencies exist well ahead of time is critical to successful product development — regardless of whether a development team works in a startup environment or inside an established organization.

Effective roadmapping is one of the most effective ways to reduce any potential risks of dependencies. 

For example: say your design team has an unexpected delay and they need a few more days to complete some mockups. Development, QA, marketing, and sales will need to know about it well ahead of time to minimize disruption. This can be effectively handled with a dedicated product management tool — this will enable you to communicate the progress of all dependencies across key stakeholders, in real-time.

Product Dependency Mapping

What is product dependency mapping?

While dependencies in project management usually refer to project tasks, product dependencies, and product dependency mapping relates to anything that a product or any part of a product relies on.

Product dependency mapping typically includes identifying product dependencies and documenting critical information such as who controls the dependency, the likelihood of disruption to the dependency, the impact of any disruption, and alternatives should the dependency become unavailable.

Mapping these dependencies helps product managers identify and mitigate risks by defining priority dependencies, putting backup solutions in place, and opening lines of communication with owners of dependencies.

Various aspects of product dependency mapping can be automated to identify third-party components, plug-ins, and hardware that are dependencies. These are often called application dependencies, and existing application dependency mapping tools are available. Other types of dependency, such as critical team members or data, need a more manual approach.

What are products dependent on?

Products can depend on various things, some of which are in your control and others that are not. Common among these are:

• Shared software libraries or components that are integrated into your product

• Special hardware needed to run your product

• Staff with specialist knowledge that you can’t do without

• Third-party data feeds or databases that your product uses

• Third-party software such as add-ins or plug-ins that your product incorporates

Depending on your product and organization, there may be others. When performing product dependency mapping, it is important to review all the possible dependency types.

An example of product dependency mapping

If a module of your product requires access to a third-party data feed to function, it is dependent on that third party continuing to provide the feed through the same channel and in the same format. Having identified this dependency during their product dependency mapping process, a product manager would realize that this poses a risk.

The product manager has multiple options to mitigate this risk. They could reach out to the third party and get assurance that the feed will continue, or if there will be changes, agree that they will notify the project manager well in advance.

Alternatively, they could seek a way for the product to function without the need for the third-party data feed, perhaps by developing an in-house solution.

At the very least, they could identify potential backup solutions so that if there is a disruption to the third-party data feed, they have another data source to fall back on.

Top tips for product dependency mapping

1.       When performing product dependency mapping, consider distinct types of dependency independently to ensure you don’t miss any. Feel free to start with our list, and add any other types that apply to your product:

• Hardware

•  Common software libraries

• Third-party software (i.e., plug-ins, apps, etc.)

• Staff

• Data sources

 2.       Include everyone in the product dependency mapping process. Software dependencies are often well hidden and hard to identify without a deep knowledge of how the product works. Engaging the whole team means you are more likely to find these deep dependencies.

 3.       Don’t stop at mapping the dependencies. The value of product dependency mapping is helping teams avoid problems before they arise and identifying the cause of unexpected issues more quickly. Take the time to understand and record who controls dependencies, how your product interacts with dependencies, whether the dependency is necessary, and what impact a disruption to a dependency will have.

eBook

Roadmapping From A to Z

Read now