Friday, 17 April 2015

What's different about facilitation?

Facilitation is one of the Key skills of the Knowledge Manager. The vast majority of organisational knowledge is carried in people's heads, and the most effective way to transfer knowledge is through human interaction.  A good facilitator can help remove many of the cultural and personal barriers to this interaction.

Effectively identifying and exchanging knowledge in a meeting requires high quality interactions between people.

It needs open behaviours (listening, exploring, not criticising) and it needs dialogue rather than argument or debate.

It requires balanced input from many people - not a few people talking, and the others listening - and it requires process to be followed, within a given time frame.

Without facilitation, none of these are easy to achieve!

So what exactly is facilitation, and how does it work?

A good illustration of facilitation, and how it differs from teaching and coaching,  is the "facilitraining rainbow".  I am not sure who first drew this diagram, but I include my version here.  It shows different types of interaction between and individual and a group, with "teaching-style interactions on the right, and facilitator-style interactions on the left. Basically:

  • A teacher "owns the content" of the interaction. They own the knowledge and pass it on to someone else;
  • A facilitator owns the process, and the participants in the interaction own the knowledge.

To facilitate is therefore to impartially support the interaction between the participants in order to optimise knowledge discovery, creation or transfer. To facilitate is to serve the group by encouraging, aiding, and leading the dialogue.

The zone of the Knowledge Management facilitator is therefore definitely on the left hand side of the rainbow.  The KM facilitator has low ownership of the knowledge content, and a variable level of interaction with the group in question.

In Retrospect meetings, After Action reviews or other lessons capture meetings, the level of facilitator interaction with the discussion is relatively high, and considerable discussion facilitation may be needed. In a Retrospect, the facilitators role is to ensure the team reach ground truth, and deliver valuable lessons.

Similarly in ideation or innovation processes the facilitator may be more interactive as they strive to ensure a high level of open thinking.

In other KM processes such as Peer Assist, Knowledge Exchange, Knowledge Markets, Knowledge handovers and so on the facilitator is less active, and often acts more as a process and behaviour monitor.

Wednesday, 15 April 2015

The role of the Knowledge Engineer

The Knowledge Engineer is the key role in any Knowledge Management program that focuses on analysing complex decision making applied by experts, and turning this into rules and guidance that less experienced people can use. It can therefore be a crucial role in Knowledge not an easy role, and needs a set of unique skills.

The Knowledge Engineer role was first introduced in the era of Expert Systems, when the vision was to take expertise out of the human domain and incorporate it into machine logic. Although the promise of expert systems has never really taken off, this is still an area of development in the legal profession with the trend towards automated document production.

Even without developing an expert system, the Knowledge Engineer role is an important one in creating Knowledge Assets and Knowledge Bases from the knowledge of experts.

The focus of the Knowledge Engineer was historically on the creation of the knowledge system, but in reality the major challenge for the knowledge engineer is in eliciting the knowledge in the first place. It is in the elicitation and analysis that the skill lies, rather than in creating the expert system.

The task of the Knowledge Engineer 

Assess the problem. The step that initiates the process of knowledge engineering is the assessment of the problem for which the knowledge needs to be acquired and packaged.

Elicit the knowledge. This is the most difficult step, and where the skills of the knowledge engineer are most important. There is a range of techniques for Knowledge Elicitation, from the structured and unstructured interview, through analysed problem solving, to card sorting and the creation of concept maps.

Structure the knowledge. Once the knowledge has been elicited it needs to be structured into an expert system, a database, a knowledge base or a knowledge asset. The knowledge engineer creates the structure and format for the knowledge, and populates it with the knowledge which has been elicited.

Validate the knowledge
The knowledge engineer needs to verify the final system, database or asset, by asking the experts to review it, and by validating the knowledge against known outcomes. The objective is to produce knowledge of high integrity.

What it's like being a knowledge engineer.

This is a really interesting piece about the experience of being a knowledge engineer, from the viewpoint of Maurice King; an editor creating medical manuals. He describes the perceptions of the KM role as a somewhere between "all you do is listen and write things down" and "you become an expert in everything".

Here is how he describes some of the challenges of the Knowledge Engineer role;

Like other knowledge engineers, I have had great problems in getting knowledge out of experts. Real ones are hard to find, and when you have found them, they may only be master of a small field, and be so busy that they can spare you little time....
An expert often forgets what he does, and may not know what he does. Even when an expert can describe what he does, he can be wrong. He is more likely to be able to remember actions given conditions, than conditions given actions... expert surgeons know when to operate, but have difficulty listing the indications for doing so. They need cues which a knowledge engineer has to supply. 
An expert is often better at criticizing someone else's ideas than explaining his own, and may only express his knowledge in response to something he disagrees with. Knowledge engineers have to learn the expert's language: in doing so I became a particular kind of ''theoretical' surgeon, anaesthetist, and obstetrician. 
I worked mostly by asking experts to comment on innumerable drafts assembled from tiny fragments of knowledge. As one expert said when I began, ''You will have to build it up comma by comma''. Looking back, it is remarkable that the task was accomplished at all. Only by combing the earth was it possible to find just enough appropriate experts. 
Paradoxically, any merit in these manuals lies with the experts, and any faults with the knowledge engineer ... it is his job to spot the fault and patch it with another expert's knowledge. The sixth sense that he needs to develop is to know what knowledge is useful, and when it is likely to be faulty.

How KM links with corporate universities

Traditionally, Knowledge Management and Learning and Development have trodden parallel but separate paths - KM dealing with unstructured on-the-job peer learning, and L&D dealing with structured, off-the-job top-down training.  However some organisations are smart enough to blend the two.

Image copied from Corporate University done right by Annie Mustain
This blending becomes easier for organisations with a corporate University, as this is a body tasked with the overall development of organisational competence.

So we see the ENI university with one of its objectives to "contribute to the enhancement and development of knowledge through the promotion of knowledge management systems", the Mars University "serves as the global center of expertise for talent development and knowledge management, fostering a culture of learning, collaboration and knowledge sharing" and the DaimlerChrysler University in the early 2000s being responsible for organising global KM initiatives.

Example from Caterpillar

This story below from Vicki Powers describes how KM and the corporate university are linked at Caterpillar.

In 2001, Caterpillar discovered a number of relevant issues that would affect its business: new technology, a changing marketplace, and changing demographics of an older workforce that would begin retiring in the next few years, often with more than 30 years of service. 
A team within Caterpillar examined how the organization could remain competitive in the future. It recommended that Caterpillar make the transition to a continual, learning organization, of which knowledge sharing is a key element. In response to that need, the organization formed Caterpillar University in 2001. Its learning philosophy centers around a triangle-shaped learning model with "Build People" as the center. Three elements make up the sides of the triangle: Leadership, Knowledge Sharing, and Learning Culture. 
The Knowledge Network moved under Caterpillar University and out of the Technical Center at that time because the organization viewed it more as a knowledge-sharing tool than as technology. Through this relationship, Caterpillar University has supported the organization's business objectives of knowledge management that focus on supporting a learning culture, delivering bottom-line results, and improving performance. 
Mark Shipley, global learning project manager at Caterpillar, believes that the Knowledge Network's reporting relationship to Caterpillar University — rather than to a corporate-level executive—definitely made a positive impact on its success. Managers within each community facilitate the 3000 communities of practice. The corporate staff for the Knowledge Network is a small team of six, including positions in marketing, information services, technical support, and a knowledge-sharing manager. Shipley manages several communities of practice, including the Global Learning community. He especially appreciates how easy it is to get the word out quickly within a community. 
"If anyone has a question [around learning], there are upwards to 400 people who have part of their job responsibility for learning," Shipley relates. "There's a wealth of knowledge out there to tap into quickly."

Monday, 13 April 2015

The "working team" dimension in KM

We hear a lot about communities of practice and social networks in Knowledge Management, but we should not lose sight of the other dimension of the knowledge equation - the work teams.

Work teams are often the way work gets done in organizations, and a team of knowledge workers is effectively a knowledge team. Any complete knowledge management framework needs to cover the team dimension, because teams create knowledge, and teams use knowledge.

Teams create knowledge

Knowledge comes from activity—you learn from experience, from ‘doing things’. In most of the companies to which Knoco consults, ‘things are done’ by teams. In the oil industry, construction industry, engineering, mining, television, etc, most of the big work is done by multidisciplinary teams, and therefore, the organisational unit for reviewing that work is the team.

Some of the more familiar methods for Knowledge creation and capture within a team/activity/project environment are the after action review and the retrospect. These are processes for structured discussions between the team members to identify any new lessons and new knowledge which has been created during the activity or the project.

Teams apply knowledge

Teams create knowledge, but they also consume knowledge. They need to learn from others in order to perform their tasks effectively. Team learning can be organised through the use of a Knowledge Management plan, and will involve processes such as Peer Assist where the team talks with other experienced practitioners to draw on their lessons.

Communities of practice share knowledge

If the work teams create and apply knowledge, then the role of the communities of practice and the social media is to provide a mechanism to transfer this knowledge from one work team to another.

Balancing short term and long term in KM

The short-term/long-term balance is critical in KM. The business of KM is long term culture and behaviour change, but the company will have no patience for the long term, if you do not deliver benefits in the short term. 

The balance between short term and long term is tied to the balance between Push and Pull (where Push is the publication of knowledge, or knowledge sharing, while Pull is seeking for knowledge).

Many companies seem to start instinctively with Push. "Let's share our Best Practices" they think. "Let's find what we are doing well, and then look for opportunities to replicate this elsewhere in the company". Knowledge push is "a solution looking for a problem".

Seductive though this idea is, it is a long-term game and won't deliver the quick wins,.

Let's imagine you capture some best practices on mergers, or on outsourcing, or on implementing ISO. It may be a long time before another merger, or another outsourcing, or another ISO implementation. Maybe nobody is ready to adopt these Best Practices right now. The gains will come at some point in the future, when the next merger or the next acquisition or next ISO implementation is on the cards.

Pull, on the other had, delivers quick wins. Knowledge Pull is "a problem seeking a solution".
Start with a problem, and seek for the knowledge to solve the problem.

Take, for example, Peer Assist; a meeting held by a project team with a problem, who are seeking knowledge from others to solve the problem. The knowledge shared through the Peer Assist will find an instant application and a willing audience. There should be little or no "Not Invented Here".

Knowledge Pull delivers the short term wins, Knowledge Push delivers the longer term.

Some time in the future, there WILL be another merger, or another outsourcing, or another ISO implementation, and then the knowledge will come in really handy. And then later there may be another another merger, outsourcing, ISO implementation. Then another. Push reaps benefits over the long term. Capture knowledge once, re-use it twenty times. Pull reaps instant benefit, but maybe only once. It solves an instant problem, but leaves no trace.

Any well-balanced KM strategy requires Push and Pull, but don't count on Push for quick wins, or Pull for long term benefit.

Friday, 10 April 2015

Knowledge Management in mergers and acquisitions.

Knowledge management delivers maximum value when applied to high value knowledge, to support high value decisions, and in areas where that knowledge is otherwise at risk of being lost. A typical high value area where major decisions will be made is Mergers and Acquisitions. 

KCR/MTR merger (photo from wikimedia commons)

Mergers and Acquisitions are high cost, complex operations, where crucial decisions need to be made very well, and yet which happen relatively rarely, so it is easy for tacit knowledge to be lost. People caught up in the high pressure activity can easily forget the detail of how the decisions were made, and fail to pass the knowledge on to future mergers and acquisitions teams.

This combination of high value decisions made relatively infrequently, so that human memory alone cannot be relied on as a knowledge store, means that there is great value on documenting the learning for use in future mergers and acquisitions.

In addition, many mergers and acquisitions are conducted for knowledge reasons, in order to acquire competence and capability.

 The approach to KM for Mergers, Acquisitions and Divestments would be as follows; 

  • Learning Before. Through Peer assists and other knowledge-seeking activities, the M&A team would seek to acquire lessons, guidance, success factors and pitfalls from previous Mergers, Acquisitions and Divestments. 
  • Learning During. If possible, and for high value Mergers, Acquisitions and Divestments only, a Learning Historian would be seconded to the M&A team to capture lessons, practices and key documents as the exercise progressed, perhaps through a series of After Action Reviews
  • Learning After. Interviews and Retrospects of the key players would be held to determine the success factors to repeat, and the pitfalls to avoid. The focus will be on capturing tacit knowledge and experience; the 'golden rules', 'top tips', recommendations and advice that will allow success to be repeated routinely. This might include interviewing any external consultants who had been an integral part of the team. 
  • Knowledge Asset. Output from the interviews and the Retrospect will be packaged into a knowledge asset; a web-based package or secure wiki that provides helpful accessible advice for future re-use. This advice will be at varying levels of detail; from the managerial overview of the "top 10" bullet points, down to operational advice. 
  • Post-merger KM framework. If we assume that each of the two merged companies had an approach to Knowledge Management, in other words their own Knowledge Management Frameworks, then after the merger these two frameworks will need to be merged. This would be done through a combination of an external assessment to look for the strengths and weaknesses in each approach, and a set of Knowledge Exchange meetings to decide on a best combined approach. This would be piloted and rolled out like a conventional knowledge management implementation.
  • Post-merger Knowledge Mapping. In a knowledge-based acquisition, where one company acquires another in order to gain access to their knowledge, there will have been some pre-acquisition work done to ensure that the knowledge gain is worth the expense of acquisition. However once the deal is done, there needs to be detailed knowledge mapping to identify the critical knowledge areas, to determine how well managed each of these are, and to put in place actions to improve the management of critical topics. After all, if you spent the money to acquire the competence, you would want to make sure this new asset was well managed.

Case History 1

The learning approach outlined above was applied by Company A to their merger with Company B, and again with Company C two years later.

In the latter case, 14 of the core acquisition team were interviewed, and lessons were derived on leadership, the team and team processes, the role of the investment bank, the transaction process, communication, and staff issues. One year after acquisition, 31 staff were interviewed to gather lessons on the Integration process. Interviewees included the Chief Counsel, one of the Country unit Presidents, and several other very senior staff. Learnings were captured on topics such as managing the Integration project, dealing with delay, and getting ready for Day 1 of the integrated company.

Lessons from the first merger were used to guide the process for for the second, and lessons from the second acquisition and integration were used to guide the process for several further acquisitions. The value of the knowledge management approach was seen in the reduced involvement of external consultants in successive mergers. Initially the bill to Big 5 consultants had been very high, but this reduced from one acquisition to the next as Company A internalized the knowledge.

Saturday, 28 March 2015

Holiday Hiatus

There will be a two-week hiatus while this blog takes a holiday.
Normal service will be resumed later in April

(mouseover photo for attribution)

Blog Archive