Playbook: How to manage dependencies
On the benefits of visualising dependencies
Dependency management, despite its importance, does not get the attention it deserves and is often a bit haphazard and less structured than it could be. In this playbook suggest a lightweight way to identify and manage dependencies.
Tl;Dr?
Check our podcast out:
Podcast | Beautiful Abstraction
Digital consulting We help design and deliver better digital products and services, help work in better ways, and…beautifulabstraction.com
Why to do it
When delivering an outcome I want to know what other ‘factors’ affect the outcomes I need to deliver (or are affected by my actions).
Identifying dependencies is important, as ultimately, a dependency will impact, possibly block, the delivery of outcomes we want to achieve.
Really, dependency manage is about alignment of the various building blocks that impact an initiative.
What good looks like
We will want to identify all internal and external dependencies (i.e. those we control and those outside of our direct control). We will also want to identify direct and indirect dependencies: the former being those that have concretely reduce our block the delivery of our outcomes; the latter being those are impacted by our activities but do not directly affect our outcomes. This holistic view is important as ultimately even the most indirect impact can be detrimental, be it from ethical or reputational perspective.
We also want to understand the type of or reason for the dependency, whether it is under controlled or unmanaged, and who is the owner of this dependency. There are dependencies we want to actively manage, and others (especially the indirect ones) which we may leave to others to primarily own.
In my opinion good dependency management is supported by a visualised dependency map, which aids identification, management and communication of dependencies.
How to do it
1. Agree scope of the dependency model
You will want to define the boundary of your sphere of activity (and within that map internal dependencies) and the wider domain (and within that external dependencies).
2. Identify dependent objects or entities
Identify all ‘entities’ that pose a dependency. Consider systems, people, process, events, projects, initiatives. Identify the relationship between the various objects and entities.
3. Detail dependencies
For each dependency determine
Dependency type: Are we impacted by this dependency or do we impact it? On the dependency model this can be represented via directional arrows.
Reason: Annotate arrows with the reason for why this dependency exists.
Owner: Define who owns the item under discussion, i.e. who unblocks you, provides information, who you need to inform and align with.
State: Identify whether the dependency is in relation to an existing item, an item that is about to change or something that is required but does not exist.
Status: Identify whether the dependency is blocking (we are waiting for something and can’t proceed until this is addressed), aligned (the dependency exists but is aligned with our activities so does not impede), has been removed (the dependency is irrelevant until something changes on either end).
4. Manage dependencies
Continuously monitor dependencies to ensure overall alignment, impediments get avoided and unblocked. Identify new dependencies as they come to light. Track dependency state as it changes and make sure this happens in-line with your plan and requirements. Stay on top of dependency status: track (and nudge) blockers, closely monitor those that are aligned and loosely monitor removed dependencies.
Tips
Do
Be clear about the scope of your model and what dependencies it tracks
Work inwards out, i.e. start with your core object and ask, what does this depend on / what does it impact and then repeat with the new objects until you have reached domain boundaries, i.e. dependencies are so far out that they become irrelevant. In other words word outwards: start with the core domain, then work outwards (upstream and downstream) along the value chain
Use cross-disciplinary workshops and models such as service blueprints, architecture diagrams and experience maps or project plans as input
Track external and internal dependencies individually: The former are relevant to your stakeholders, the internal ones mostly to ‘your team only’.
Review dependencies frequently
Consider context modelling and risk management in conjunction with dependency management
Don’t
Keep the dependency map comprehensive but as clean and small as possible. Focus on the things that ‘really trip you up’
Don’t make this into a bureaucratic tracker. Instead use them as tool to create actionable insights
Do not assume that owners automatically manage the dependencies own on your behalf, they may limited interest in doing so.
Avoid the temptation to focus only on incoming / upstream dependencies, downstream dependencies are just as important to provide a narrative complete system.
Example Map
Original Google Drawing:
Google Drawings - create diagrams and charts, for free.
Choose from a wide variety of shapes to create diagrams and charts. Free from Google.docs.google.com