Drivers for KM activity

---

I posted a while ago about how I was beginning to see KM appearing in pre-qualification documents as a requirement for contractors tendering against contracts for government and for major clients.

In the last 2 months I have seen two other similar drivers for KM adoption. The first was from a big-company audit of potential suppliers, where they fed back to one supplier that

• your company is formed into silos,
• your silos are clearly not talking with each other, especially for identification and re-use of lessons learned,
• your company needs effective Knowledge Management.

The second example was a service company that wanted to demonstrate to clients that they were competent operators, and part of that would be to demonstrate a good KM system, because "our customers will expect us to do KM". Unfortunately the vision from their sales team was "a glitzy website or wiki we can show our clients", rather than a KM system that delivers value to the company itself, but nevertheless, the driver was there.

Good Knowledge Management, I would assert, is increasingly becoming an expectation; from clients, from customers, and from contracts.

This expectation-based driver will certainly revive the KM industry, as expectations from clients, customers and contracts will drive internal expectations within organisations.

Unfortunately there is no clear consensus on what "Good Knowledge Management looks like", though there are some common components, such as

• A connected organisation
• A good quality knowledge base, and
• An effective system for learning from experience.

A new KM barrier

---

Here's a new KM barrier I heard recently, which I had not come across before.

"Everybody is really busy, so I don't like to ask anyone for help and advice. If I do ask a question, I make sure it is a really simple one, so as not to bother them".

This is almost like institutional shyness, or institutional deference.

The result is that knowledge is not shared, people work inefficiently, mistakes are made, rework is needed, and as a result .... everybody is really busy!

Another KM Boston Square

---

Here's another potentially useful Boston Square for looking at different KM situations and approaches.

On one axis we have Push and Pull of knowledge. On the other axis we have centralised approaches, where knowledge comes from a defined central place or group of people, and dispersed approaches, where knowledge comes from the dispersed workforce.

Centralised Push represents knowledge being spread from the centre - manuals, training courses, official documents, newsletters and so on. Decentralised push is push from the workforce - blogs, wikis, microblogs.

Centralised Pull represents Pull from a central source such as a help desk or an expert pool. Dispersed Pull represents pull from the community or from the crowd.

Every KM system needs both Push and Pull, despite the tendency to underestimate the value of Pull.

However the choice between Centralised or Dispersed depends on where the knowledge lies in your organisation, which may be related to Demographics. If there are few experts or experienced staff, then go for a centralised system. If there are many experienced staff, then a dispersed system may be more appropriate.

---

"What you don't know will always hurt you." First Law of Blissful Ignorance

KM and the demographics of the organisation

---

Here's another factor that can affect the way you address KM in an organisation; the demographics of the workforce.

Take a Western engineering organisation. Here the economy is static, and the population growth is stable. Engineering is not a "sexy topic". The workforce is largely made up of baby boomers. A large proportion of the workforce is over 40, with many staff approaching retirement. Experience is widespread in the organisation - this is an experienced company, and knowledge is dispersed. Communities of Practice are important, where people can ask each other for advice, and that advice is spread round the organisation. Experienced staff collaborate to create new knowledge out of their shared expertise. The biggest risk is knowledge loss, as so many of the workforce will retire soon.

Take an eastern engineering organisation. Here the economy is growing, the population is growing, there is a hunger for prosperity, and engineering is also a growth area. The workforce is predominantly very young - many of them fewer than 2 years in post. There are only a handful of real experts, and a host of inexperienced staff. Experience is a rare commodity, and is centralised within the company, retained within the Centres of Excellence, and the small Expert groups. Here the issue is not Collaboration, but rapid onboarding and upskilling. The risk is not Retention of knowledge, it is deployment of knowledge.

These two demographic profiles would lead you to take two different approaches to KM. The Western company would introduce communities of practice, and use the dispersed Expertise to collaborate on building continuously improving practices, processes and products. Wikis could be used to harness the dispersed expertise. There would be huge potential for innovation, as people re-use and build on ideas from each other. Crowd sourcing, and "asking the audience" are excellent strategies for finding knowledge.

The Eastern company would focus on the development and deployment of standard practices and procedures, and on developing and deploying capability among the young workforce. The experts would build top-class training and educational material, and the focus would be on Communities of Learning rather than Communities of Practice. Innovation would be discouraged, until the staff had built enough experience to know which rules can be bent, and which must be adhered to. Crowdsourcing is not a good strategy, and the "wisdom of the experts" trumps the "wisdom of the crowd".

This is one of the factors that KM must address, namely the amount of expertise in the company, and how widely it is dispersed.

Back to Front approach for KM

---

 I had another request for advice recently from a guy I know; he is a good guy, he sees the value in KM, and wanted my comments on a proposal he wants to make to his management. Reading it made my heart sink.  It was KM; back to front.

You know how I always say that KM should be business-led? That if it's not addressing a business problem, that it isn't worth doing, and is doomed to failure? Well, his approach was far from business led.

First of all, his objective is to “try a community of practice”. So instead of looking for a business problem and choosing a KM solution to address it, he has chosen a solution, and is looking for something to use it on. A solution looking for a problem, rather than the other way round.

Secondly, his community of practice” has a membership of 10 people, spread around the globe. This is VERY SMALL for a global CoP.  Usually you would be looking for 100+ people. He will need to try very hard to make this work (unless these people are the core of a larger CoP or CoI), and I have a strong feeling that it is doomed to failure from the start.

Thiurdly his community objective is to “share best practices”. Not only is this not a business focus, it is a Push focus, and communities work best through Pull.

Fourthly he plans to use a wiki and a discussion forum as the main tools. For 10 people! When they could just as easily have a phone conference, and speak to each other instead.

Friends, your first steps in Knowledge Management should be careful ones. You nly have one chance to make a good impression, so plan your pilot carefully. Make sure it solves a business issue. Make sure you choose a solution that will work. Drive it through Pull (at least initially). Transfer knowledge through the easiest mechanism; through dialogue wherever possible. Set your pilot conditions so that you are most likely succeed. Then once you have that initial success, you have a sound platform to build on.

Expertise location, and the long tail of experience

---

One of the core tools in KM is Expertise location.

We know that not all Knowledge (in fact very little knowledge) is made explicit, and can be accessed through documents. We know there is a great richness of tacit knowledge in the organisation. We know that if we can "find the people who know", then we can access that tacit knowledge through asking them questions.

So we create an expertise locator.

One common approach to this is to build an "Expert locator". You think - "Who are the experts in the organisation? Can we make an index of the experts, so that people can find them, and ask them for advice?"

However Expertise is not always synonymous with Expert, and certainly Experience is not synonymous with Expert.

Consider the graph above - a plot of the years experience in an imaginary company. We see red bars and blue bars - the red bars are the Experts, who have 35, 32, 28, 27 and 25 years of experience - a total of 17 years. The blue bars are the workers. They individually have fewer years of experience, but there are a lot of them, and their collective experience adds up to 1187 years of experience - 8 times more than the experts. So if you need an answer to a problem, and if you want to tap into the experience of others, where is that relevant experience likely to sit? 8 times out of 9 (in this example) it will sit it the Long Tail of experience, not in the Short Head of the Experts.

Does this happen in practice? Do we get answers from less experienced workers rather than from more experienced experts? I think in real life - where knowledge exists in context, where contexts vary widely, and where many staff see knowledge in many contexts, then this happens quite a lot. Here is a story from a real company.

"I had written a report on the success of a particular operation in my business in the USE, and I made this report because one of my managers asked me to do this to support a decision. I was able to document some of our information from the last 4 year to help this decision. This is was a significant thing for my team, but it turned out to be significant for other teams as well. I saw a question through the web system asking "what has been the success of this operation in the company?". This was a question from a team in Africa, and it was a close enough scenario to the scenario for which I had written my report. You feel the Power - you feel the power of knowledge and the value that it might represent when you receive a response "Thank you very much for your reply, because this actually helped us to make a decision". It was an incredible experience to answer a question in the forum, with only 2 1/2 years experience in the company, and already being able to advice the whole world on the things we do and how we do it". 

The answer was in the Long Tail, the context was similar, the knowledge was transferred, and time and money were saved.

So when you create your systems for tapping into tacit knowledge - your Expertise Locators, your "Ask a question" functionality - do not fall into the trap of involving only the few Company Experts. Remember the long tail, which may contain nearly 90% of the experience and knowledge, and include those guys as well.

Knowledge of product, knowledge of practice

---

Some companies make things, some do things. Different focus, different business, different approach to KM.

OK, so that is an oversimplification - most companies are a mix of Doing and Making; they have product departments where they Make things, and sales/marketing/support departments where they Do things. However there are still two types of KM approaches; the approach that focuses on Product, and the approach that focuses on Practice.

A typical practice-based organisation would be the Army. They don't make things, they do things, and their KM approach is all about the development and improvement of Practice. They develop their doctrines, they develop Communities of Practice, and they focus on continual practice improvement. We see the same in the oil sector. The focus is on Practice Improvement. Communities of Practice, Best Practices (or whatever you prefer to call them), Practice Owners - the entire focus is on knowledge of Practice, Practice Improvement, and Doing Things Better.

A typical product-based organisation would be an aircraft manufacturer or a car manufacturer. They exist to make things, and their KM approach is all about the development and improvement of Product. They develop product guidelines. In DaimlerChrysler, their Electronic Book of Knowledge was about motorcar components, and their tech Clubs were more Communities of Product than Communities of Practice. The experts are more likely to be experts on a product, than experts on a practice area. With the more complex products, were design knowledge is critical, KM can become Knowledge Based Engineering, with design rationale embedded into CAD files and other design products. The Air Force, in contrast to the Army, is focused primarily on Product learning - learning about the Plane itself, much of which learning is shared with the aircraft manufacturer. For a Product based organisation, the entire focus is on knowledge of Product, Product Improvement, and Making Better Things.

The danger in KM comes when you try to impose a solution where it does't apply. KM should be pragmatic, and consist of "horses for courses", rather than a one-size-fits-all approach. This is also true for divisions within large companies. While the sales division, or the new business division, or the projects division may need Communities of Practice, perhaps the division that makes the products needs Communities of Product, so that Knowledge of Product can be transferred across company boundaries. Perhaps the traditional tools of Learning Before, During and After need to look at Product knowledge as well as Practice knowledge, and look for improvements in Product as well as improvements in Practice.

The idea of Communities of Product is an interesting one, as these Communities may extend beyond the designers and Developers, to include the Sales force and the Service Engineers, who also need product Knowledge, and can supply learning about the Product in Sales, and the Product in Use.

Ultimately the Product Community can extend to the Users of the product  - the customers themselves. That's when it really gets interesting!

Knowledge oversupply, a cautionary tale

---

Earlier this year I met up with a company who had taken a popular approach to KM; the approach of Explicit Push. However they had taken it to extremes, and as a result destroyed the value they had hoped to create.

Explicit Push is that component of KM that deals with publishing written material. It is only one of four components of KM, and it is the component that takes the longest to deliver any value. Push is "just in case" knowledge, and while there are times where Push is the correct approach, it is a wasteful approach for anything other than the publishing of guidance for repeat activity. It is an answer looking for a problem, rather than a problem looking for an answer.

This company, who shall remain nameless, had introduced

• A blogging platform for all staff. Directors and other senior staff are taking the lead, people rank each other's blogs, and star bloggers are given prominence and recognition
• A platform for publishing articles, again linked to recognition. Many blog posts are repeats of articles
• A wiki platform. Much wiki content is repeated on blogs, or contains contents of articles
• A discussion forum, used for announcements. Many of the posts are notifications of new articles.
• A microblogging platform, mostly used for notification of new blogs, articles and wiki pages

Explicit push in this company is

• modelled by senior management
• very visible
• rewarded
• reinforced by posters around the building
• modelled by peers, and
• supported by many channels.

Pull, on the other hand (and by Pull I mean the demand for knowledge - the curiosity to learn), is

• not modelled by senior management (no managers are asking their staff for advice)
• not visible
• not rewarded
• not mentioned on any posters
• not modelled by peers, and
• supported by only one channel, which doesn't work very well.

As a result they have created a vast supply of published material, much of it duplicated, and none of it well structured, and have almost no demand for that material. As a result almost none of it is being reused. Even if you know something has been published, it can still be impossible to find. Nobody can keep up to date with the volume of published material.

The vast volume of duplicate material creates a wall of noise, within which the signal of knowledge transfer has been lost.

Explicit Push is such a popular first-pass approach to KM strategy, that it is worth looking at what happens when taken to extremes, and how the sheer volume of pushed material can destroy all value in the system.

This is a reminder to make very very sure that the other three KM components are addressed as well.

The Great Firewall of China

---

I shall be in China for a couple of weeks,  behind the Great Firewall, with no access to Blogger, Twitter or YouTube. Normal blogging service will be resumed on my return towards the end of the month.

My presentation in Sao Paolo

---

Courtesy of Liane Grassi and her blog, here is her description of my presentation in Sao Paolo on "KM Culture". Liane was one of the two simultaneous translators for the event.

"Nick Milton focused on showing us how to create an organizational culture to support knowledge management. It is important to understand that sharing knowledge and asking questions can be met with resistance due to many factors. Employers/Employees wonder whether implementing knowledge management will represent a burden to their day jobs. The counter argument to this view is quite simple. It is important to seek, share and re-use knowledge for the good of the organization, but the best tools in the world will not work if people really don’t want to use them. There is an urge to change knowledge emphasis inside the organizations and it can only be done by taking into account the individuals that work in them and are part of them. The old culture considers knowledge a personal property or advantage. People can perceive new knowledge as a threat to their own knowledge and admitting ‘I don’t know’ can be thought of as a sign of weakness.

"Shifting to the culture of “we know”, perceiving knowledge as collective or community property and advantage, will make the same individuals feel that sharing knowledge helps them, that new knowledge improves personal knowledge and that admitting “I don’t know” is the first step to learning. Nick Milton also showed a video (leadership from a dancing guy – available on YouTube), which was a successful way of showing how to create a movement and how following great ideas is important for implementing or creating something new. The role of the leader treating his followers as equals and being easy to follow – even instructional - is very important. But without followers no movement is created, and leadership has been over-glorified. All people in the organization are important for the creation of a culture that supports knowledge management. Nobody should be left apart".

Thanks Liane!

Shakespeare on knowledge

---

"Hence is it that we make trifles of terrors, ensconcing ourselves into seeming knowledge when we should submit ourselves to an unknown fear." Shakespeare, All's Well that Ends Well, Act II, scene iii.

Quotes on expertise

---

"Believe one who has proved it. Believe an expert." Virgil, Aeneid

"An expert is a person who has made all the mistakes that can be made in a very narrow field." Niels Bohr, Danish physicist

Challenging the notion of generational differences

---

Another interesting study on generational work differences fails to find any significant link between generation and working style.

I know we often assume that the different generations will have radically different working styles, yet when we test this, we find little hard evidence.

Now we have another study, referenced above, which has the same conclusions, namely

• The study results challenge the notion of "generational differences"
• The differences in personality and work values are much smaller than expected given the current emphasis on this topic (seminars, books, training programs, etc.)

By "much smaller", the study quotes figures of 1% to 3% of the variability, ie statistically insignificant.. It then asks

• Are "Generations at Work" seminars/training valuable?
• Are programmatic initiatives simply based on stereotypes, rather than research?
• Example: Are HR initiatives specifically designed for the Baby Boomer generation worthwhile?

This is a warning to us when we build assumptions about generational preferences into our knowledge management programs - they may well be just that - Assumptions!

(If anyone can reference any studied that DO show statistically significant variations, I would be interested to see them. Please add a comment if you have such studies to share)

Consistent mediocrity beats inconsistent genius

---

A manager from one of our clients recently said to me "if we could only be average in everything, we would lead the industry".

This is a "tortoise and hare" vision. It's a vision of delivering steadily, unspectacularly, but making no mistakes along the way. It doesn't sound like a very exciting vision, which is why so many companies attempt to strive for excellence in a few things, and fail in other areas. But it would be a very successful vision.

A strategy of "no mistakes" - a strategy of consistent competent delivery in all areas - is one that Knowledge Management can easily support, and it may be a better strategy for many companies than a strategy of striving for excellence and innovation. Why not get the basics right before getting adventurous?

Ultimate vision for KM

---

KM as a project resource

---

Wikipedia describes project management as follows

Project management is the discipline of planning, organizing, securing, and managing resources to achieve specific goals. 

What it does not do, is define what those resources are.

Typically, people think of project resources are being Human resources and Capital resources, such as

1. Money 
2. People
3. Time
4. Technology
5. Space

But lets add number 6 - Knowledge - an Intellectual resource.

I think knowledge is often ignored as a project resource, as it is assumed that the people hired onto the project team will bring knowledge with them, but those of us who work with KM know that knowledge can be treated independent of the people. Knowledge Management and HR management are not the same. 

That's why a project needs to treat knowledge as a resource, and manage it as such, through the use of a project Knowledge Management plan, and through the application of processes such as Peer Assist and After Action review. 

(for more detail of KM in projects, see here)