Dependencies Matrix

Problem Addressed

Libraries, perhaps more than most HE services, involve a variety of systems, some under the control of the library team, some managed elsewhere in the university, in the wider community or by vendors and other distant parties. This suggests that identifying and assessing dependencies will almost certainly be a significant part of any change to systems or to workflows. That will likely still be the case even where core systems are ‘unified’ by a single vendor or supply chain partner.

Regardless of this particular challenge relating to the library services ecosystem, it is essential to assess dependencies in any change process, even when wholly within the bounds of the service. This assessment will benefit from a method of analysis and documentation that enables assumptions to be easily reviewed and challenged – and a simple ‘linear’ list will typically fail to convey the critical bottlenecks, challenges and risks.

Method Proposed

Recording dependencies as a matrix allows relationships between functions or ‘working parts’  (whether whole systems or much more granular processes) to be more precisely identified. The recommended format captures

  • The working parts as rows
  • The same list of working parts as columns
  • The nature of the dependency in cells, which may be recorded in a range of ways:
    • A simple scale of  ‘High’, ‘Medium’, ‘Low’ or ‘None’
    • Alternatively as 3, 2, 1, 0
    • Or perhaps a description of the dependency

A cell therefore reads

‘This’ (Row) has a ‘Scale’ dependency on ‘That’ (Column).

Experience suggests that it is conducive to better understanding both to ‘score’ and to describe dependencies. The descriptions can take the form of separate notes, but the Cambridge discovery infrastructure example (below) records both in the cells. Here is the ‘reading on one of the cells from the illustration:

The global index in Summon has a high (score 3) dependency on the local indexes harvested by Aquabrowser

Whilst this infrastructure example is complex (necessarily so), the immediate observation upon completion is that there is a high and repeated dependency on one working part – the local indexes represented in Column 3.

Here is how the Cambridge team recorded dependencies between the components making up the library’s discovery services:

Dependencies Matrix example

The method is as follows:

  • Step 1 – Draw up a list of the working parts in the functional area under consideration; the order does not matter, though it is easier to consider the issues in such as workflows or data exchange with logical sequencing
  • Step 2 – Populate the rows and columns with the list in the same order, and shade the ‘same’ row/column intersections as they are not relevant
  • Step 3 – Work through the matrix row by row, filling the cells using one of the methods described above; remember each cell can be read as illustrated above
  • Step 4 – Consider the broad implications, which include high level observations such as:
    • Everything hangs on one or two working parts – so we need to understand those really well
    • The major dependencies are on working parts that are out of our control – so we need to treat them as black boxes / fixed pieces or undertake some critical discussions with the owners
    • The dependencies suggest a phased implementation of the planned changes
  • Step 5 – Agree how to develop the findings in the matrix in to actionable tasks, which might include verification, negotiation, review of alternatives, etc

The objective of the method is therefore to identify and rationalize dependencies between the working parts in a problem space.  This will be helpful when considering change at systems or at workflow / process level and will generate findings and challenges that may require detailed testing, sometimes in consultation with external players such as IT services or vendors.

Even though our focus here has been on IT systems and computer mediated processes, the method can equally take account of organisational factors such as role descriptions and skills requirements.

Examples of Use

This method is used or referenced in the following LMS Change Case Studies

Other References

Whilst dependencies are a key consideration in change management, we are not aware of a particular method that assists in initiating the task in this way.