Nowadays I talk about the four legs of the Knowledge Management table being Roles, Processes, Technologies and Governance.  But why do we need the extra leg? What is the purpose of KM governance?

I have seen many examples of organisations with what look like very good Knowledge Management systems which are not being used.

For example, they might have defined accountability for capturing knowledge from projects, they might have a defined process for lessons capture meetings, and they might have a top range lessons management system, and yet only a trickle of lessons are entering the database, and even fewer are actually re-used.

So what is missing, when a system is in place but is not used?

You could say “culture” or “behaviours” – but both of these are outcomes of something else, namely governance. To understand what else is needed, let’s think about what makes people adhere to other systems at work. For example, what makes people follow the (sometimes onerous) safety procedures, or the security procedures, or the time writing procedures?

It’s three factors:

• They know they should follow the procedures
• They know how to follow the procedures, and
• They know if they don’t follow the procedures, there will be consequences.

As part of our three global surveys of Knowledge Management professionals in 2014, 2017 and 2020, we asked the participants to select from a list the Knowledge Management governance elements that had in place in their organisation. 

Most of the survey respondents reported at least one element of Knowledge Management governance, with the most common being the Knowledge Management Strategy  (reported by 62% of the people who responded to this question).

Having a defined KM approach was second highest, followed by KM reference materials, to allow this approach to be followed.

It is also interesting to see a Knowledge Management policy being applied in 35% of the cases.  KM policies are quite hard to find online – but there must be a few of them out there.

Please do not think that because a governance element is low in the list, that it is not important!

 We would suggest that all these elements are important, with the exception of having a separate KM incentive system (see here for more on KM incentives). It’s just that some are more commonly applied than others, often because people do not realise the value these elements bring.

The diagram below shows how the usage of these KM governance elements varies as the KM program matures from the early stages (blue), through “well in progress” (red) to fully embedded (green).

Firstly it is seems that the big difference – the biggest jump – is between the early stagers and those who are well in progress. This represents either the adoption of KM governance needed for progression, or the lack of progress of those who do not have those elements.

Those organisations where KM is embedded have an even greater application of all of the KM governance elements, the top 4 being KM strategy, Knowledge Management framework, KM training and KM reference materials. The biggest proportional difference in usage is the KM success stories, which tend to be collected as the KM initiative progresses.

At Knoco we would suggest that some of these governance elements should be developed within the first year of your KM journey, notably the strategy, the framework, the business case, the vision and the high level champion. Others such as the success stories and the network of champions in the business should be the next target, while the KM policy, training, metrics and reference are late-stage governance items.

Knowledge Management often involves balancing two forces – Connect and Collect, for example, or value to the individual and value to the firm. If you are not careful, this balance can turn into pendulum swings from one factor to the other. Here is a story of this happening.

Typical cycles in the balance between predator and prey

This is a story about how KM activity and support, in one organisation, has fluctuated wildly on an 8-year periodicity. It is also a story about why this happened (with reference to predator-prey cycles) and how other companies can avoid it happening to them.

The story

In the mid 80s, the company in question first realised that the various factories around the world were failing to learn from each other, and that there was a massive efficiency gain to be made by sharing best practice. They started a series of Global Practice Groups, and immediately began to deliver some quick wins in terms of business value. 

Every community of practice should have a charter, but what does a good charter look like?

Image from wikimedia commons

One of the main success factors for a community of practice is a charter.

A charter is a definitional/governance document, created by the community members, which describes what the community is for, and how it will work. Often a draft is created by the community core team, or by the people present at the community launch event, and that draft is then refined over time through discussion within the community.

The community charter usually contains the following elements:

• Community Purpose – what the community is for; it’s high level aims and vision, and business case if appropriate 
• Objectives – what the community is trying to achieve in concrete terms; things that you can measure
• Scope – which areas of practice knowledge are in scope, and which are not
• Processes – the ways in which the community will operate in order to share, use and co-create knowledge
• Tools – the technologies the community plans to use 
• Roles – who does what (names of the community leader, sponsor, core team etc)
• Principles and Behaviours – which underpin the community.

The Community Charter for the PMI Agile Community of Practice contains the following elements:

• Vision of Who We Are (a community of highly accountable project professionals, improving skills, expanding minds, and continuously raising the day-to-day effectiveness and professional satisfaction of project teams across the world.)
• Mission (To equip PMI Members with Agile skills and knowledge)
• Values
• Goals & Objectives
  • Resources
  • Committed from our sponsor
• Expected from community stakeholders 
• Roles
• Working/Operating Agreements

I like the way resources has been split out, and I like the way “values” and “operating agreements” are differentiated.

The Wisconsin Heart health community charter is a 9-page document containing the following sections:

• Overview
• Justification
• Scope
  • Vision (Wisconsinites living with healthy hearts)
  • Mission (To improve cardiac health related outcomes across Wisconsin – especially a reduction in hypertension – through the advancement of best practices, establishment of strong organizational relationships, and the mutual activities of community of practice members)
  • Goals
• High level requirements
• Major Deliverables
• Participation
  • Benefits
  • Norms
  • Ground Rules
• Assumptions
• Constraints
• Risks
• Roles and Responsibilities 
• Facilitator

For me, this is just a little too long, and many of the sections which could be single sentences, are paragraphs instead. However it is certainly a very well though through charter, and there are several charters out there that use a similar template.

The Restraint Reduction Network community of practice

Without using a formal template, the page linked above defines

• The Vision of the community (We are a community seeking to equip one another to reduce restrictive interventions through using person-centred, proactive, preventative and therapeutic strategies)
• The Mission (We share and discuss resources, tools, policies, research and personal experiences to encourage and inspire one another as we seek to improve quality of life for those at risk of restraint and the people who interact with them on a daily basis)
• The tools the community uses,
• and a really nice “Rules of Engagement” Graphic linked below.

I think I like this charter best because it is concise and straightforward, and the Rules of Engagement poster is inspiring, simple, and can be printed and posted on a wall as a reminder of the way the community works.

The problem with Dualism in KM is that it leads to pendulum swings in terms of focus. Here is how to avoid this.

Image form wikimedia commons

There can be quite a lot of Dualism in KM – seeing KM in terms of two mutually exclusive opposites which require a choice. Examples might be

• A strategy of Connecting (connecting people) vs a Strategy of Collecting (collecting content)
• KM introduction from the Top-down, or Bottom up
• KM all about People, or KM is all about Technology
• A focus on Conversation, or a focus on Content
• Optimisation for for search or optimisation for browse?

Of course this Dualism is wrong, its always a case of “both/and” rather than “either/or”, and the trouble with Dualism is that when you choose one alternative you neglect the other. Over time, you realise you are missing something and switch your attention to the “opposite pole”.

As a result, KM can suffer from pendulum swings.

To give you an example, one company for many years had a KM approach focused almost entirely on Communities of Practice. After a series of project overruns, they  introduced a framework for project KM, which had a fantastic impact on results.

Over the subsequent years this approach became taken for granted – seen as “embedded”. The high level champion left, and was replaced by a lower level champion, who was replaced again by someone even lower, and gradually attention and governance slipped. The framework began to be ignored, new management came in, and said “project KM doesn’t work – lets put our attention on Communities of Practice instead”.

And so the pendulum swang, with a frequency of a decade.

Maybe in 5 more years there will be a series of project overspends, the spotlight will turn again onto project KM, and the pendulum will begin it’s back-stroke.

How do you guard against this? How do you ensure that KM is given an even-handed and consistent treatment?

A clue comes from a comment from John Donahue on one of my blog posts. John says

I’ve been working with US Army KM programs for some time and even with this structure (of strategic teams) there’s a tendency for KM to slip into IT/Portal management. Fortunately this strategic level guidance allows units to self-assess, and “adjust fire” as they’d say. I don’t believe Army KM would have been so successful without this formalized structure to keep the program on track.

The formalised  strategic guidance – KM Governance – stops the KM pendulum swinging towards IT and Portals. And certainly the company I mentioned above doesn’t have the strategic level guidance.

If you want to avoid the pendulum of fashion when it comes to KM, then you need to set up, and maintain, the strategic level governance that can keep it on the straight and narrow.

If you outsource knowledge work, make sure the contract requires the contractor to have KM in place. 

Contractors review plans, by US Army Corps of Engineers, on Flickr

A few years ago I was running a multi-day lessons capture event with a company that had recently commissioned construction of a large production plant.

 Here’s a story that the client project manager told at the event.

“This plant was based on a similar plant built by the same contractor, and on that previous plant they had made a big construction error – in one of the emergency release lines, they had put a non-return valve in backwards. Had there been an emergency, this could have been a disaster. We spotted the error, fixed the valve, and we discussed it, together with other lessons, with the contractor at the end-of-project lessons capture session.  

So this time, when I was walking the lines, I thought ‘shall I bother to check that valve? Surely they would not have put it in the wrong way round again? But I thought – better safe than sorry – and blow me down, it was the wrong way round again!”

Disaster averted for a second time, but what’s the moral of the story?

The moral is that when we outsource work (to a contractor, or to an outsource provider) we are also outsourcing the knowledge of how to do the work. We  expect the contractor or the provider to bring the knowledge needed to deliver the work properly.

And when we outsource the knowledge, we outsource the management of the knowledge as well. We expect the contractor or provider to learn – to constantly improve their knowledge – to never repeat mistakes.

So what went wrong on this case? Who was to fault?

Obviously the contractor was at fault; they should have had a proper KM system in place, with closed-loop lesson-learning, which eliminated repeat mistakes. And there is nothing worse for a contractor than having a client with a better KM system than you – who knows your repeat mistakes before you do!

However the client was equally at fault. They assumed that “Surely they would not have put it in the wrong way round again? Surely they would have learned?”.

But this was an assumption. There was nothing in the contract that stipulated a KM system, and no audit of the contractors learning ability. The client just assumed, and we all know what Assume makes!

The moral of this tale is that if you outsource major work, you also outsource the knowledge needed to do the work, and you need to outsource the management of that knowledge as well. Therefore make sure that your contractor has a top-notch, independently audited and verified, KM and learning system, with the sort of closed-loop learning that eliminates repeat mistakes.

Make sure this “effective KM” is stipulated in the contract.  require your contractor to demonstrate an effective KM approach, compliant with ISO 30401:2018.

And its still worth walking the lines and checking as well – just in case!

Knowledge Management is fully embedded when refusing to do it is not an option.

Let me give you an analogy, from the world of Safety. A couple of years ago I was conducting knowledge management exercises at a gas plant in the Niger Delta.

In places like this, safety is a huge consideration; both personal safety (keeping individuals safe in a hazardous environment), and process safety (keeping the environment from becoming even more hazardous).

For example, it was mandatory to wear a hard hat and safety boots when on site, no matter how uncomfortable these might be in the African sun.

One of the engineers was giving me a tour of the plant, and we were on a high walkway when he spotted a worker who had climbed a tall tower and was sitting at the top, resting in the sun, without his hat and boots on. Immediately the engineer stopped the tour, and ordered this guy to put his safety equipment back on and report to his foreman about the break of safety regulations.

It did not matter that the worker was safe, and that nothing was about to fall on his head or his feet – it was that such behaviour – such a breach of the safety policy – was not permitted. One small breach for the sake of resting in the sun could lead to a larger breach, and then to something dangerous. There was zero tolerance, and everyone was involved in reporting breaches. Even out of sight on a tall tower it was not allowed, and anyone (like my engineer) who spotted it would take action. If this worker could get away with avoiding the safety rules, then others would know, and would copy, and soon there would be a reduction in safety discipline, and accidents would happen.

Now, if we truly want Knowledge Management to be embedded, then we will eventually need a similar attitude.

Imagine if lesson-learning were truly embedded in the project lifecycle for example.  Imagine that the leadership of your organisation had realised the cost of repeat mistakes and rework, and had made it clear in their Knowledge Management policy that they expected every project to identify, document and share lessons and knowledge for the benefit of the rest of the organisation.

Then imagine what would happen if people could get away without doing it.

As soon as one project manager realised that they could skip lesson-learning with no sanction, then the others would also realise, and would copy, and soon there would be a reduction in learning discipline, and repeat mistakes and rework would creep back in. This breach of the Knowledge Management policy, this neglect of lesson learning, could cost the organisation millions of dollars and put other projects at risk. It should not be permitted.

If you are serious about Knowledge Management, and if you want it fully embedded in your organisational practices and your organisational culture, then you need to aim, eventually, for a time when people cannot get away with not doing it.

KM Governance on its own is like a half-built bridge. It gets you nowhere.

Half built bridge cc-by-sa/2.0 – © David Lally – geograph.org.uk/p/2266263

KM governance is a crucial part of KM, and much of the new ISO KM standard deals with issues of governance, such as leadership, support, and the creation of a KM Policy. However governance on its own is not enough, you have to go farther and tell people exactly how to fulfill the expectations set by the governance system. Let me give you an example.

I was working with a major company, doing an assessment of their knowledge management capability.

One of the things we always check for is Governance of Knowledge Management – whether people know what they are expected to be doing in KM terms, whether they have the resources to do it, and whether the incentive system is aligned with KM expectations (i.e. are they disincetivised, and could they get away without doing KM, and still avoid getting into trouble).  These are all elements within the ISO KM standard.

I was reviewing the alignment of project management and KM within this organisation, and particularly the habit of capturing knowledge from projects.

“Yes”, they said. “We are expected to capture knowledge. It says so in our project guidelines”.

When I checked they were absolutely correct, there was a line in there about “all projects will document lessons learned from their activity”. However there was no guidance on HOW to do this.  As a result, there were a variety of approaches, the most common being for the project manager to jot some things down in a spreadsheet, and file it in the project files.

As regular readers now, this is far from being an effective lesson-capture process, and the lessons were sketchy, inconsistent, poor quality, and very hard to retrieve.

So the company had gone halfway towards having a KM policy for projects (albeit a sketchy one, hidden within the project management guidelines), but had not gone all the way in defining what actually needed to happen, not on quality-controlling the content, nor on ensuring that the lessons could be and would be re-used.

Governance is crucial, but needs to be accompanied by well-defined processes, roles and technology if it is to fully span the KM gap.

Even in the most progressive organisations, sometimes the boss needs to drive a “culture of asking.” Here is how Elon Musk did it.

Image from wikimedia commons

Musk’s email is quoted here, and seems to have been sent in response to a dissatisfaction with default communication and knowledge sharing habits at Tesla.

There are 6 things I want to point out regarding this email, which I have highlighted in the text of the email

below.

1. Musk is setting the expectation for lateral communication and knowledge flow, rather than the vertical communication seen in many other organisations (which I describe as knowledge hedge-hopping).
2. He makes his expectation very clear, and backs it up by spelling out the consequences (“Any manager who allows this to happen, let alone encourages it, will soon find themselves working at another company”).
3. He places this expectation in the context of problem-solving and asking for help (“Anyone at Tesla can and should email/talk to anyone else according to what they think is the fastest way to solve a problem for the benefit of the whole company”). Musk is looking to drive a culture of “open asking”.
4. He makes this expectation very eplicit. It is not a request, it is an obligation.
5. He separates out this behaviour of problem-driven asking from “random chit-chat”, and sees it as key to competitiveness.
6. He recognises that the default “hedge-hopper KM” behaviour is driven by a natural human tendencies which needs to be “fought” in support of the corporate good.

Subject: Communication Within Tesla 

There are two schools of thought about how information should flow within companies. By far the most common way is chain of command, which means that you always flow communication through your manager. The problem with this approach is that, while it serves to enhance the power of the manager, it fails to serve the company. 

Instead of a problem getting solved quickly, where a person in one dept talks to a person in another dept and makes the right thing happen, people are forced to talk to their manager who talks to their manager who talks to the manager in the other dept who talks to someone on his team. Then the info has to flow back the other way again. This is incredibly dumb. Any manager who allows this to happen, let alone encourages it, will soon find themselves working at another company. No kidding. 

Anyone at Tesla can and should email/talk to anyone else according to what they think is the fastest way to solve a problem for the benefit of the whole company. You can talk to your manager’s manager without his permission, you can talk directly to a VP in another dept, you can talk to me, you can talk to anyone without anyone else’s permission. Moreover, you should consider yourself obligated to do so until the right thing happens. The point here is not random chitchat, but rather ensuring that we execute ultra-fast and well. We obviously cannot compete with the big car companies in size, so we must do so with intelligence and agility. 

One final point is that managers should work hard to ensure that they are not creating silos within the company that create an us vs. them mentality or impede communication in any way. This is unfortunately a natural tendency and needs to be actively fought. How can it possibly help Tesla for depts to erect barriers between themselves or see their success as relative within the company instead of collective? We are all in the same boat. Always view yourself as working for the good of the company and never your dept. 

Thanks, Elon

When you are setting up a KM function, where should it report?  Here are some statistics about the most common reporting set-ups.