Managing Dependencies is often made harder by poor documentation and representation approaches. This presentation proposes a simple network based representation that is directly driven by dependency data.

1. Identifying, documenting and analysing dependencies
John Phillips
DEPENDENCY MANAGEMENT

2. Managing dependencies is critical
In every organisation there are many activities happening at once. These
activities make contributions and demand resources, they interact with each
other in planned (and unplanned) ways, they share expectations and resources.
Understanding dependencies is critical when we are planning new activities.
Managing dependencies is essential in delivering existing activities.
Dependency management is critical for all endeavours, from strategic planning
to enterprise portfolio management, to program and project execution.

3. Managing dependencies not easy
There are many hurdles that get in the way of good dependency management:
● Thinking in blinkers: a lack of appreciation of the impact on other
projects and the vulnerability to other projects
● Poor Information: No clear documentation of the dependencies that do
exist and no easy way to assess the impact of change
● No process: the identification, documentation and resolution process is
not clear
● No decisions: Project autonomy with no alignment to a common
authority means decisions aren’t made or aren’t followed

4. A dependency is something that has the following attributes:
● Cannot be resolved by independent project action
● May have a material impact on project performance
Dependencies are either:
● Internal between a projects within an organisation, or
● External between internal projects and external entities
Dependencies are either:
● one direction one project depends on another, or
● mutual (projects depend on each other)
What dependencies are we interested in?

5. Identifying and resolving dependencies
Dependencies need to be managed at a level above their independent project
structure.
Enterprise portfolio management should include dependency management.
As a tactical solution in the absence of an enterprise portfolio management
capability, dependencies may be identified through coordinated project
mechanisms such as:
● Project communication updates broadcast across the organisation
● Project governance meetings (where several sponsors are present)
● Cross-project shared service capabilities such as enterprise architect
groups, HR and finance functions who can identify dependencies

6. Plan
Dependency Management Process
Dependency
Table
Dependency
Graph
Inter-Project
Program
Strategic
Portfolio
Project
Manage
Inter-Project
Program
Strategic
Portfolio
Project
Understand
Automated
representation

7. Creating a Dependency Table
Title Gives a simple one line description of the dependency
Description: Describes the background to the dependency in more detail
Project 1 Name: The name of the first project
Owner - Project 1: The nominated owner of this dependency for the first project
Project 2 Name: The name of the second project
Owner - Project 2: The nominated owner of this dependency for the second project
Direction Indicates whether 1 is dependent on 2, or 2 is dependent on 1, or that
they are mutually dependent
Criticality Indicates the level of criticality for the dependency
When required Date that a resolution will need to be agreed
Resolution Description of resolution (and updates to achieving resolution)
Status Current status (has a resolution been agreed, is one being defined…)
Modified System recorded date and time of when record is updated
Created System recorded date/time of when the field was created
Created By System recorded user who created the field
Modified By System recorded user who last modified the field
From a management perspective,
documenting, managing and
reporting the status of each
individual dependency is easiest in a
simple table where each row
represents a single instance of a
dependency.
This is an example of the
information that should be captured
for each dependency.

8. Why a table is the best way to capture
dependencies
1. Allows an “any project” to “any project” capability
2. Allows any number of dependencies to be captured (representation does
not get more complex as numbers increase)
3. Allows focus on one dependency at a time, there is no need to grapple with
the big picture every time you want to work on a dependency
4. Allows a view of the dependencies to be “filtered” to only show a specific
project’s dependencies
5. Allows ownership of the dependency to be documented for each project
enabling accountability
6. Allows other attributes of the dependency to be recorded, such as status (e.
g. no resolution, defining resolution, resolved), direction, and strength (a
scale from “high” to “low”)
Abstracts the data from the graphical representation

9. Graphing the dependency table
Good graphical representation brings out underlying meaning in data. It
maximises the information to ink ratio2
.
Project dependencies are often shown as Gantt or PERT charts, time based
diagrams where dependencies are on a common timescale.
These become complex when several dependencies occur at the same point in
time and have complex overlapping lines.
Matrix representations only show the existence of one or more dependencies
between two projects
The best representation is a network diagram derived directly from
dependency data, avoiding human interpretation and a creative process that
risks introducing error and bias.
2. Tufte, Edward R (2001) [1983], The Visual Display of Quantitative Information (2nd ed.), Cheshire, CT:
Graphics Press, ISBN 0-9613921-4-2.

10. The “best” graphical representation
Research shows that a network based graphical representation supports
communication and strategic portfolio decision making1
.
This means that decisions such as “which project do we postpone?” (if overall funding
is reduced), or “what happens if we add another project?”, are better informed.
The representation chosen by CharterMason uses a network representation ensuring:
1) Node “importance” (determined by factors such as investment level, NPV, and
Strategic Fit), is represented by size and colour
2) Dependency criticality is indicated through width and colour of edges
3) Graphical representation is automated by direct representation of the table using
open-source products, removing the risk of unintended artistic bias or error
4) Nodes (projects) and edges (dependencies) are labelled
5) Graphical format is tool independent using “GraphML”
1
Killen, C. P., Krumbeck, B., & Kjaer, C. (2010) “Visualising project interdependencies for enhanced project portfolio decision-making” published in the International Journal of Project
Management (2012) - The University of Technology Sydney

11. The graphical representation
needs to draw attention and
convey meaning to the viewer.
Defining the ratio of edge width
to node size, of label size to
objects, of border width to node
size, is important. Colour should
amplify the meaning but the
diagram must be understandable
without colour
To maximise attention and
information transfer, the graph
should transparently present the
data and be pleasing to the eye.
Dependency Chart Elements
Projects with low investment commitment
Projects with medium investment commitment
Projects with high investment commitment
Project 1 is dependent on project 2
Project 1 and project 2 are mutually dependent
Low criticality dependency
Medium criticality dependency
High criticality dependency
1 2
1 2
These colours chosen for display on a black background

12. Note: Simplified table representation used in example. Description, Required Date, Resolution fields normally complete
Example Dependency Table
Title Description Project 1 Name
Owner -
Project
1
Project 2 Name
Owner -
Project
2
Direction
When
required
Resolution Criticality Status
Enquiries from prospectives New ERP John Query Engine Peter Projects are mutually dependent High Agreed Resolution
FAQ New ERP John Query Engine Peter Projects are mutually dependent High Defining Resolution
Acceptance Rules Application New ERP John Acceptance Rules Simon Projects are mutually dependent Medium Agreed Resolution
Acceptance Rule Management Acceptance Rules Simon New ERP John Project 1 is dependent on Project 2 High Agreed Resolution
Enquiries management for marketing Website Redesign Sarah New ERP John Projects are mutually dependent Extreme Defining Resolution
User Flow Web content Steve New ERP John Projects are mutually dependent High Defining Resolution
FInance Information New ERP John Finance Upgrade Peter Projects are mutually dependent Low Defining Resolution
HR Information New ERP John HR Replacement Lisa Projects are mutually dependent Medium Defining Resolution
New-Legacy integration New ERP John Old ERP Anna Projects are mutually dependent Extreme Defining Resolution
Access to current web content Web content Steve Website Redesign Sarah Project 2 is dependent on Project 1 High Defining Resolution
Available product structure Query Engine Karen Product Management Chris Project 1 is dependent on Project 2 High Defining Resolution
Product design and management New ERP John Product Management Carol Projects are mutually dependent Extreme Defining Resolution
Information Architecture Website Redesign Sarah Query Engine Jane Project 2 is dependent on Project 1 High Defining Resolution
Product information Website Redesign Sarah Product Information Chris Project 1 is dependent on Project 2 High Defining Resolution

13. Example Dependency Graph
Example of an organisation
with a phased ERP
replacement, produced
directly from table data
using an orthogonal layout