Sunday, August 17, 2008

Stages of maturity in communications - strategy, architect and governannce functions

(to communicate a simple organisational problem with a few simple pictures)

Overview
When large enterprises are going through transformation (new products, mergers etc.) documents are ineffective in communicating the complex issues (and document and content management systems can exacerbate problems). As a result people involved in transitions spend time much time in meeting, in emailing and on the phone.

Strategy, architecture and governance are roles are established, but they can't manage the knowledge explicitly, don't scale and the reliance on individuals represents a risk to the business. Modelling manages the semantics, and provide powerful analysis and visualisation capabilities, and provides a source of record (reduce the risk) - but they don't scale and most models don't suit most audiences most of the time - so as communications mechanism they fail.

A knowledge repository is required which allows information to be captured as a by-product of day to day work, analysed and presented in the way that suits each audience and allows internal people to focus on actual strategy, architecture and governance while minimising the need for external consulting services.

Documents are ineffective in communicating complex issues in large enterprises Documents which encapsulate business concepts e.g. strategies, plans, initiatives, programmes , designs etc. are ineffective in communicating to most of the people most of the time. Many people create documents that communicate things to them, and their peers i.e. from their perspective and oriented at their interests. They make documents available to others in the expectation that they will effectively communicate to different people, with different interests and different perspectives. Most people if they looked at the evidence would realise this doesn't work (i.e. it demonstrably fails).



The set of all documents contains sets of related concepts (constrains, goals etc.). The set of concepts may relate to any aspect of the business (product, organisation, location, behaviour, risk, projects, technologies etc.). In the documents, usually most of the relationships between concepts are implied and unweighted (semantics are inexplicit) - because the author or original audience would be expected to know these relationship implicitly.


In the real world people need answers to questions quickly (without lots of reading)
When any issue arises or any decision needs to be made what people want is to understand an issue, or set of issues that is currently of interest to them i.e. How the concepts are related.

If one read, understood and internalised all the related documents (assuming they can be located - and were all consistent) one may perhaps get the understanding required. Unfortunately few have the time and capacity to do this.

Document and content management systems can exacerbate the problem
Document and content management systems, or content may help maintain the set of documents - but they don't address the issue knowledge held within the documents it is not explicitly related (often it is not even very explicitly defined) i.e. the semantic is not explicitly recorded (within documents, or across sets of documents), consequentially they can't address the issue that the set of documents are inconsistent. So in a sense these systems exacerbate the problem by facilitating the publication of even more documents, and maintaining the illusion that if the documents can be located people will understand all that they contain.

Meeting mayhem follows
As the business people need to know the answers, and don't have the capacity to read all the documents - what they do is communicate amongst themselves to get a handle on the issue of interest (workshops, meetings, emails, phone calls etc.). They work out what they need to do (though it takes time) and move on - only to repeat the exercise with next issue (or on the same issue sometime latter).


Strategy, architecture and governance functions are implemented
In most organisations eventually people realise that there is an issue and they put in place people (strategy, architect, governance) who aim to consolidate this knowledge. These people may even create their own documents - that aim to consolidate information around different perspectives (there are of course an uncountable number of different perspectives that occur over time in an complex enterprise). They become someone you can ask questions of. Unfortunately their capacity is usually fairly quickly exceeded - so they become people who know a lot (but seldom enough on any topic), but produce little of value.



Strategy, architecture and governance models eventuate
Some organisations realise that implementing this knowledge management function in a person or team (and their documents) doesn't address the issue of the semantics not be explicitly understood so they move to putting models in place. Models can explicitly manage the semantics and aggregate knowledge from all the sources. The models can, in theory, now answer all the questions. However there are two problems.




Models don't suit most people most of the time
The 1st problem is that while the models may be able to answer all the questions most people don't want to deal with these complex models (i.e. so for many they don't act as an effective communciation mechanism).

Models are time consuming to maintain
The 2nd problem is that one creates a bottle neck i.e. in the effort involved in maintaining the models. Usually people start by aggregating a small subset of the knowledge in the enterprise (i.e. the inputs and outputs that relate to a small set of people and issues). People quickly realise that the more knowledge that is in the model the more powerful the models can be a relating information and answering questions. Unfortunately this increases the load of model maintenance and modelling function become a bottleneck. There are bottlenecks on both the input side (maintaining models) and the output side (explaining how to use the models to answer questions).



A knowledge repository is required
Eventually people realise what is required is a knowledge repository - which contains the information held in the models (all the models) . This allows the strategy, architect and governance functions to be effective i.e. they are no longer bottlenecks and can add much more value. The repository can be used by all parties to record information, answer questions and produce the documents that each requires.



Why consulting firms don't get this
Well they do get. It just doesn't suit them. Smart consulting firms know that if models are not used at all then the knowledge and expertise they offer will always be required (an almost endless demand for their services). If models are used - and they provide the modellers - they will likewise ensure lots of modelling work. Similarly some of internal the people tasked with peforming these functions may fear that if they used such a solution - their work would evaporate. Ironically what actually happens is that they no longer have to act as typing pool (transcribing information) and actually do what most of them are most interested in doing i.e. doing actual strategy, architecture and governance thinking.

No comments: