Dependency matrix

One of the key things in understanding and managing a complex adaptive system is getting the granularity right.   Things that are too chunked are too big to change, to allow combination and recombination; too small and any such combination is not going to be visible or significant.  Granularity is one of the key factors in scaling success and one of the easiest to manage.  For example using smaller organisation units rather than a structured hierarchy or worst still a matrix structure with its two competing hierarchies.  The same applies to knowledge strategy and mapping; we simply can't afford to start with a high level what things should be approach as the risk of missing how things are around here is too high.   Now the decision mapping I talked about yesterday is one way to get to that and it has high impact, but it's not the whole story.

Showing the gap between how things are on the ground and contrasting it with executive perception is one thing. Once the gap is visible then we can start to create projects to close the gap, something which is a two way process.   But that is in a sense a corrective action, we also need to be more proactive in addressing current problems not past process engineering mistakes. That is where the dependency matrix creeps in.  Again it is something I started to use and refined over three decades ago before I had any inkling of the importance of complexity theory, with that understanding it has more significance and applicability.  In the context of knowledge management it requires two inputs:

1. We need to understand what are the current issues and opportunities faced by decision makers with the organisation and we need this understanding at multiple levels from the board room to operational managers.  Yes they will have long term goals but maximum impact comes from solving intractable problems in the present.  That is also the best way to manage a CAS anyway; dealing the evolutionary potential of the present.  So to do this we simply ask the decision makers what is keeping them away at nights (or some more tactful variation thereof).  Ideally you do this using a journaling application of SenseMaker® so that they can record them as they occur, but it can also be done by more conventional interviewing.  You really don't want to do this in a workshop as power and precedence will determine actions.   Captured individually we keep things open, and we also ask people to rank the issues in order of importance.   We can then look across the reports of multiple decision makers and see what is in common, look at the relative ranking and differences.  Once that is done you get people together to resolve conflicts and talk about differences.   At the end of that we have ranked problems that form one part of the dependency matrix show here, marked as P1 etc.
2. In parallel with this we will have been working with our decision clusters to identify the various knowledge assets in use.   Ideally this is done by asking the ASHEN question which forces different perspectives and reveals more than direct questioning.  Once that is complete the various ASHEN elements are clustered and grouped into knowledge objects which I define as things that combine together in coherence ways where we can manage them.   This may seem a little abstract but in the context of a real project people readily get it.  That gives us a list of knowledge objects that can be ranked based on their vulnerability to loss.  Probably the key priority measure for knowledge.

That complete we can issue the grid to a representative group of employees (at all levels) and ask them to mark each box where there is a high dependency between  problem and a knowledge object.  The results can then be combined to identify common agreement and also maverick scores.  Both are useful. By now it should be evident that the method of creating the data is part of the process of getting buy in to the results.

Once we have the combination we can now look for two patterns.  Those in blue show where a single problem can be addressed only if we effectively manage multiple knowledge objects; easy to sell more difficult to implement.   Those in red show where managing a single knowledge object could have an impact on many problems; more difficult to sell easy to implement.   This process which takes place in a workshop creates a portfolio of projects that work with the reality of both what we know (or don't know) and what is concerning decision makers.

That complete we can move to the overall process; I will summarise that tomorrow.