Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Managing Dependencies

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.

  • Login to see the comments

Managing Dependencies

  1. 1. Identifying, documenting and analysing dependencies John Phillips DEPENDENCY MANAGEMENT
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 13. Example Dependency Graph Example of an organisation with a phased ERP replacement, produced directly from table data using an orthogonal layout