Why KM fails

---

Oops!
Originally uploaded by bobster855

The list below (from this blog post) was created by Dion Hinchcliffe as a list of "reasons why Enterprise 2.0 fails". It's equally valid for KM.


1.It starts strong in a single department and then never makes it out;
2.Selecting the tools first;
3.Selecting the wrong tools and sticking with them;
4.There are no resources allocated to adoption and training;
5.It’s purely an IT initiative;
6.The effort excludes IT;
7.Engaging with HR, legal, branding, compliance, etc. too soon;
8.Pushing Enterprise 2.0 as a generic toolbox instead of the solution to specific problems;
9.Lack of effective executive champions;
10.Lack of effective participants: Empty blogs, wikis, or silent social networks;
11.No long term plan or budget for governance, community management, upgrades, or maintenance;
12.Failure to draw in key influencers as adoption broadens;
13.Building it all as a self-contained, top-down effort; and
14.Not waiting long enough to let critical mass build.

I would add one more -

15. Building it all as a bottom-up effort

Incidentally, I have been posting a series of "KM quantified success stories" recently, which you can find via the "case study" label to the right. I was thinking today that it might be equally instructive to post a series of "KM failure stories", so will start on that tomorrow.

Holiday break

---

Apologies to blog followers - I shall be on vacation until the end of the month, so no more posts until september

Distant transfer of knowledge

---

Semaphore
Originally uploaded by Rory Finneren

I blogged a few days ago about knowledge transfer through time and space, and promised in that blog to talk about the most difficult of the transfer contexts, which I called Distant Transfer (really because it is close to Nancy Dixon's "Far Transfer" from her book "Common Knowledge"

Distant transfer is a challenge because the opportunity for tacit knowledge transfer is minimal. Much of the transfer will therefore need to be done through captured and structured knowledge.

Here we have several problems. The knowledge needs to come from someone who may not be aware of what they know, translated into a format in which will inevitably lose a lot of its power and value, and transferred to someone who is unaware of what she needs to know. You cannot rely on her interrogating a database to find the knowledge she needs, when she is blissfully unaware of what she needs. She could not search for it, as she does not know what to search for.

For this transfer to stand any chance of working, the knowledge needs to be captured carefully (as described here), and packaged in such a way that the user can learn what she needs to know, even if she doesn't know what she needs to know. The way in which this knowledge is presented and structured is crucial. If it is not customer focused - if it does not give the future knowledge user what you are sure she needs to know, rather than what she thinks she wants to know - then the real knowledge does not get transferred, and so does not get applied.

I used to use the analogy of knowledge packaged for Distant Transfer as being like a Frozen Pizza. Here the ingredients have been assembled, packaged, and preserved. The user needs to do none of the work - other than defrosting and consuming. You aren't relying on the user to seek out and assemble all the pieces (given that she doesn't know what she needs) - you are presenting it to her ready-complete.

This packaged knowledge - these frozen pizzas - are what we refer to as Knowledge Assets

We have found these to be far and away the most effective means of Distant Transfer. However it places the onus on the creators of the knowledge, or the owners of the knowledge base (such as the SMEs) to do the packaging (and the Retrospect process leads naturally to packaged knowledge) so the knowledge user is given what they need to know, whether they are aware of that need or not.

To make this knowledge exciting, enticing, easy to read and easy to assimilate, is a skill. You want something better than another dull report. The knowledge needs to be presented in bite-sized chunks, in an intuitive way, illustrated with diagrams and pictures, and easily cross referenced. Whether you use a wiki, a website, or a word document to create the knowledge asset, it needs to be fully user-centric, and carefully structured, rather than thrown together. Ensure that your knowledge management approach includes this packaging step if Distant Transfer is needed. It takes time, it requires resources, it's one step removed from pure "user generated content" as it requires an organisation and structuring step, but without this step, you stand a good chance of failing to transfer some of the key detail.

Business-driven knowledge management

---

Meeting Outside
Originally uploaded by Office Now

I blogged yesterday about three modes of knowledge transfer, and how the business context behind the characteristics of the knowledge transfer will dictate the means, the technology and the processes you use for the transfer. I was thinking about this more over the weekend, and I've realized that the model I shared with you on Saturday is based on my fundamental approach to knowledge management, which can be summarised as follows

Knowledge management solutions should follow business need.

Let me explain what I mean. I think we can break this down into three steps.

Firstly, the business strategy should set the key knowledge which should be the focus of your knowledge management efforts. I have already blogged about the need for business focus, and I firmly believe that one of the first questions the knowledge management professional needs to ask his management is "What knowledge? What knowledge is important? What knowledge needs to be managed? What knowledge should be the focus of our KM activity". This critical knowledge will be knowledge which is crucial to the strategy of the organisation, and which therefore needs to drive your knowledge management strategy.

Secondly, you need to look at the specifics of the knowledge transfer which is needed, to make sure that this business-critical knowledge is getting to the right people at the right time in the right state. You need to ask the questions -

Who needs the knowledge?
Who has the knowledge?
Where are they located?
How do they work?
What artifacts do they use, and what frameworks frame their activity?
How can they work better?

Once you have fully worked through these specific questions, then you can start to tailor a solution. You can decide whether it's possible to get these people together face to face and transfer knowledge through tacit interchange and rich dialogue, or whether they should collaborate online, or whether you need a more sophisticated process of capture and documentation. This is where the three modes of knowledge transfer discussed on Saturday come in. You can see whether the transfer is serial, or synchronous, or distant, and then tailor your knowledge management solution to the specific case.

The process above is the thought process I prefer to use when putting in place knowledge management solutions. You can see that if you work this way, then your solutions are specific to a business knowledge need, and they are tailored to the specific context. I would far far rather approach knowledge management in this way than to introduce some tool or technology, and expect this to address business needs.

Black &Decker used to say "our customers don't want a power drill, they want holes in the wall".

Similarly in knowledge management, our customers don't want a "knowledge management system", they don't want "Enterprise 2.0", they don't want "asynchronous web-hosted online collaboration portals" - they want to make sure that the decision makers in the company have access to the knowledge they need, that will help them to make the best decisions. It's up to us to choose and design the tools, processes and roles that will enable this.

And if we are going to do our job properly, we need to do it from the bottom up, starting from the business strategy, looking at the specifics of the transfer needed, and then choosing the knowledge management approach that fits those specifics. We need to make sure that our knowledge management solutions follow the business need.

Knowledge Transfer through space and time - the three types

---

This is an old model, published in 1999 (the "knowledge with shelf life" article available for free here) but one I keep coming back to, as it can really help differentiate between different knowledge transfer needs, and therefore different knowledge transfer solutions. (Quite often, one of the reasons why people "talk past each other" in KM is because they come from different contexts of knowledge transfer, and assume that the solution that works for them will also work in other contexts)

It's a question of thinking of the knowledge supplier and receiver, and how they stand in relation to each other in time and space.

In some cases, activities and projects run one after the other, in a single location, and often involving the same people (the coloured blocks int eh diagram above represent project or other activity). Here knowledge needs to be transferred through time, but not through space - something we can call "Serial transfer". For example in one organisation we worked with, a series of LNG trains (effectively giant fridges for liquefying natural gas) were built in the Niger Delta. This is a task that requires specialist knowledge and experience. For each train, the team needs to learn as much as possible from the previous train, in order that they may build them better, faster, cheaper, more safely, and more effectively. In this case, the retrospect for each train could be followed immediately by a planning session for the next train - ‘learning after’ leading straight into ‘learning before’. The knowledge could be transferred in designs, in improved procedures, through direct conversation between the staff delivering each train, and in the heads of the people who will carry on. Knowledge transfer is a matter of discussing the learning, updating the documents, and making the changes.

Another example is where the same sort of projects or activities are running at the same time, all over the world. Here we need some sort of synchronous knowledge transfer, so people can learn from each other in real-time. An example comes from a client seeking to develop distribution networks in rural parts of the developing world, facing similar challenges in rural Brazil, in rural Africa, and in the Far East. In this case, the Synchronous Transfer is facilitated by a very effective community of practice, supported by a communication infrastructure and a live on-line knowledge base. Knowledge can also be transferred tacitly, through peer assists, knowledge exchange, knowledge visits, mentoring and coaching, and online interaction.

The third case is to consider projects that happen sporadically in time and space. This is an altogether more difficult challenge. They are a series of one-offs, which happen at intervals, in different places. They might be projects like constructing a pipeline over mountains, or entering a new retail market, or acquiring another company. These are projects that happen once at any one location, and are sufficiently unusual that you don't have several happening at once. Effective knowledge transfer is crucial, as each project is a new and unusual event for the project team, and there is tremendous risk of reinventing the wheel (in fact the traditional default is to re-invent). And at the same time, knowledge transfer is a real challenge, as knowledge has to be transferred through time and through space. You can't rely on human memory (here's why), and some form of documentation is needed (even though this is tough to do well). Knowledge needs to be captured from a project team, and packaged and stored so that an unknown team, at an unknown location, at some unknown time in the future, can access it, understand it, relate to it, use it, and benefit from it. This sort of Distant Transfer of knowledge is difficult, but possible. What it needs is some way of giving the knowledge a decent shelf-life through teh construction of Knowledge Assets - the challenges of which I dealt with in the article referenced above, and which I may come to in further blog posts.

The key is to recognise the three types of transfer, recognise that your company may face all three in different places and at different times, and do not assume that the method you apply to one, will work for all three, because it won't.

More from the lessons learned survey

---

Here is a selection of answers from the my lessons learned survey, to the question "What process do you use for lessons identification?"

Interesting, and heartening, to see the prevalance of group indentification processes such as AAR and various forms of Post Project Review. However a few organisations still rely on individual submissions, which I personally think is inefficient, as stated in this blog post.

Here's the list of methods used. Any spelling errors are the survey respondents'

After Action Reviews
After Action reviews during project activity
After action reviews during and following projects
After Action Review after project closure. Before During and After
After action reveiws at stage gates and ad hoc requirementsPost sales pitch reviews. After Action reviews during project activity
AAR, Project Stage gates assurance reviews, External benchmarking, project events (good and bad), retrospects
AARs during assignments (informal);
after action reviews, individual submission
After Action Reviews
Formal AAR,
AAR, Project evaluation, workshops
Developing AAR to improve the process.

Other post-project review
Learning From Projects - post implementation; RLI (Review Learn Improve) following reported assurance (safety, security, quality, environmental) incident.
A few via Project Reviews at the end of Projects
CVP process for major projects
Retrospect and/or interviews leading to key Beliefs
Post project reviews. Generally a lengthy meeting to specifically review process and capture lessons-learned. Recording of lesson-learned in a word document which relies on long-term follow-up to ensure application for subsequent projects.
Post project workshops + Intra-project PM collation + PMO Project auditing
After project review to gather the positive and negative experience that is then included in end of the project report
Post-project reviews (retrospects).
PPRs (formal).
Retrospect on request for major activities
Post (or milestone) debriefing of client projects; Formal process associated with project execution, and lessons can be submitted anytime.
Post-Mortem review meetings to assess each major release
After a project completes when team members are recapping activities and deliverables
Project team does a review and write up before it disbands (This could be the only thing between them and their next job)
Lessons learned are captured in the close project activity as a mean te get a check in the box for CMM assessment approval.
Review meetings held with project leaders, project workers and end users after each stage of the project. At times, a neutral facilitator to encourage submissions.

External reviews
External HSE system audit / inspection: especially to assess the statistics from the last lesson learned, in ordre to see the effectivness of the tracking-reporting system
External reviews of programmes
external reviews,

Individual submissions
individual submissions from my team which I have documented
Individual submission by site staff
Submission by the staff after the software release has concluded
Individual submissions by client facing staff.
individual submissions
the majority via individual submissions from inside AND outside the Organisation

Other
info exchange with partners
After a serious OHS incident eg potential fatality
Client feedback reviews.
on-line community discussion forums and ultimate wiki form completion
Different, sometimes prize competition (Marketing)
Project Board meetings usually last item on agenda
Template for project LL.
Constant review of processes thru metrics to discover if there are ways to improve
Well by well review raising concerns and discussing problems
Our lessons learned (called "Good Practices) are indentified during several, audit processes, as part of daily work, as part of our COP processes and part of our TPM implementation (continuous improvement programme)
we're a sales-oriented company, so all our metrics are sales based.

Quantified KM value, success story number 11

---

If Value, Then Copy
Originally uploaded by AGoK

Another success, delivered through

Focus on a real business problem
Exchange of Tacit Knowledge
Peer Assist.

A company had moved into a South American country through acquisition. They had taken over a chain of local dealers, and needed a business information system up and running. The vendors said “This will take you 10 months.” Management said “we need it in 6 months if we are to capitalise on this acquisition”

Although this implementation of a business information system was new to that country office, it was not new to the company. Offices in eastern Europe and the Middle East, had done this sort of thing recently, a team in head office were working on standard processes for business systems, and there were several vendors who offered these systems.

The country office decided to tap into this knowledge through a 2-day Peer Assist. They held video interviews with the participants to develop a shared context in advance, and built a careful agenda of knowledge sharing and solution creation.

An email from the country manager afterwards confirmed that they had benefited from applying the knowledge management principles, starting with the peer assist, which produced a much improved project plan, reducing the time-scale from 10 to 4 months.
Examples of processes/procedures and technical templates were lifted from Poland and Russia to start the project off. External benchmarking suggests that the costs would have been up to $500,000 higher without the knowledge transfer.

So a direct benefit of $500,000 was realised, with the additional indirect benefits of accelerating proper governance by 6 months compared to the original vendor estimate.

What makes a lessons learned system work? Some more preliminary survey results

---

(this post removed, as I think I got my sums wrong!)

Nancy Dixon, third stage of KM

---

An excellent blog post here from Nancy Dixon.

nancy has blooged on the first two stages of KM, and takes an unexpected (for me, at least) turn on the third stage. For Nancy, the third stage of Knowledge Maqnagement is harnessing collective knowledge, at all levels, in order to make crucial organisational decisions. She suggests that this needs to involve teh flow of knowledge not just within a team, not just from peer to peer, but at all levels. She suggests

Knowledge management processes have largely been focused on the frontline. Middle management for the most part has been ignored, as has senior management. These levels have had few, if any, processes designed to learn from each other or through reflection.

We, as knowledge management professionals, have somehow assumed senior leadership did not need to be concerned about how effective their own knowledge processes were. It is as though their positions somehow made them immune from the needs that were so clearly evident in the frontline. The role senior leadership has played in knowledge management has primarily been to provide the resources needed to apply knowledge management to the frontline, but not to itself.

Yet many of our greatest organizational problems have occurred because accurate knowledge did not flow upward and because senior leaders withheld knowledge from those at the frontline.

Hmmm - interesting! She suggests four ways in which leadersip can frame the conversations in such a way that collective knowledge can emerge.

1. Framing the question –
Framing the topic of the conversation requires posing a question rather than a solution. The question needs to be one that gets to heart of the issue, not just its symptoms. That may require the convener to name the “elephant in the room” – the issue that everyone knows about but no one talks about.

2. Configuring the physical space to serve the conversation-
Most large conference spaces are designed for speeches not conversation. Even conference rooms within most organizations’ walls tend to be furnished with rectangular tables that are more suitable for negotiation or adversarial discussions than conversation.

3. Identifying who needs to be in the conversation -
In considering who to bring together, organizations tend to err on the side of homogeneity rather than diversity. Thinking broadly about who impacts and is impacted by the topic of the conversation is one way to broaden cognitive diversity.

4. Design the interaction
The rule of thumb is that 80% of the time those who have come together should be in conversation with each other, leaving only 20% of the time for presentations and speeches. A design that alternates between small group and large group conversations is the most productive for integrating the organization’s knowledge.

This sort of exercise is something I know well within a community (our Knowledge Exchange process) or after a project (our Knowledge Handover process), and I am fully familiar with the power of conversation in these settings. So I see exactly what Nancy means when she talks about collective knowledge applied to strategic issues, and to cross-heirarchical knowledge sharing.

Currently I know of no organisations working KM in this third sense - from the CEO downwards (or outwards) - but I look forward to this vision being realised!