A dependency describes the relationship among activities and specifies the particular order in which they need to be performed. Dependencies arise in every decision making, planning and developing process and are ideally predetermined. Tasks can be successors and predecessors to other tasks whereby the instant of each execution may be aligned accordingly.
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 clearly mapped out and planned for, to avoid any disruptions to overall product development.
To configure a dependency the type of reliance between a pair can be further defined by one of following relationship models:
The finish-to-start dependency is the most common relationship between two tasks. The predecessor task must be finished before another task, the successor, can start.
The predecessor must have started before the dependent task can start. The finish of either task is unaffiliated.
The successor can only finish after the predecessor has finished. The successor’s start is doesn’t rely on the predecessor and can begin before, after or at the same time.
The start-to-finish is the least common relationship between two tasks. The successor has already started and cannot finish until the predecessor has started as well.
Dependencies can occur between teams, initiatives, or deliverables.
One very common example of an internal dependency would be requiring another team to do something they own within their function, before developers are able to deploy a new feature. This could be needing your design team to finish creating Sketch files in order for your engineering team to implement them.
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 to identify dependencies in the first place. It is important to stay on top of them when a project gains traction and becomes more complex.
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 in doing so. Whether depicting dependencies in a Gantt-Chart, diagram, table or with other means, it will enable the team to reevaluate commitment and to object to impractical measures if necessary.
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 mock ups. 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 stakeholder, in real-time.