Embedding KM through accountabilities

Work gets done because people are accountable. KM also will get done if individuals are given accountability.

Work gets done because people are accountable. They are given a job, and they do their job. Where I have seen KM really live for a long time in organisations, it is because those organisations have

• been clear on the job of work KM has to do
• given that job to dedicated and accountable individuals, and
• put in place a reporting chain though which that job or work is assigned and delivered.

Let me give you two examples of how this operates, using the vectors of Communities of Practice, and Lesson-Learning. The description below is based on a number of organisations who work in this way.

Communities of practice.

1) The organisation has a clear idea of the functional competencies it needs to be successful.

2) These competencies are owned by senior staff, working through competency owners, competency committees or functional excellence teams. These staff/committees/teams have targets and deliverables relating to competence protection and development.

3) The leaders of the networks and communities of practice report to these senior staff, and hold a business plan or performance contract with the senior staff, stating how they will develop the CoPs in service of competence.

4) The network leaders take accountability for the development of the CoP and for the development of the community knowledge base. They may have a small team (for example a community facilitator) to help, and may have a small budget or community business. 

If this accountability chain works well, then the network leader can track the development of competence through CoP metrics, including success stories and performance metrics. They report this upwards to the senior staff, who report against their own targets and deliverables.

Lesson-learning, and Learning from Experience

1) The organisation has targets for project delivery (cost, time or quality targets).

2) These targets are owned by the Head of Projects, or some similar role.

3) Reporting to the Head of Projects will be an individual or small team responsible for project learning

4) This team, with the backing of the Head of Projects, takes accountability for the delivery of effective "learning from experience" within the project context. They monitor delivery of learning against the company expectations, they facilitate the lessons identification, and they operate the lessons management process, they drive re-use.

If this accountability chain works well, then the network leader can track the development of effective learning through metrics, and through improved project delivery (including learning curves). They report this upwards to the Head of Projects, who reports against their own targets and deliverables.

In both these cases, KM is given a job to do ("Improve or protect functional capability though CoPs and CoP knowledge bases", "Improve company performance through project learning"), has individuals accountable for that job, and has a reporting chain. The job is clear, performance is tracked.

That's how you really embed something for the long term.

Lesson learning roles in the RCAF

Roles and Governance are often overlooked elements of KM. Here is a great example of a set of roles and accountabilities for Lesson learning within the Royal Canadian Air Force.

The example is taken from a web page dated 2015 called "Canadian Forces Aerospace Warfare Centre, Analysis and Lessons Learned".

The RCAF have the following roles and accountabilities, shown in the diagram to the right, and described below:

• A senior sponsor, known as the Lessons Learned Command Authority - this is actually the Commander of the RCAF, and is accountable to the Vice Chief of the Defence Staff for implementing and overseeing the Lesson Learned Programme. Note that the Chief of Defence Staff requires the RCAF to establish processes that add value to the existing body of knowledge, or attempt to correct deficiencies in concepts, policy, doctrine, training, equipment or organizations, and the Lessons Learned Programme is one response to this requirement.

• A delegated customer/custodian for the Lesson learned program known as the "Lesson Learned programme Authority". This is the Deputy Commander, who is responsible for all Air Lessons Learned matters, including maintenance and periodic review of the programme. 

• A leader for the Lesson Learned program, called the Lessons-Learned Technical Authority. This is the Commanding Officer of the Canadian Forces Aerospace Warfare Centre, who reports to the Lesson Learned Programme Authority for lessons-learned matters, and who is responsible for executing all aspects of the programme with the help of a dedicated Analysis and Lesson Learned team.

• Clear accountabilities for the leaders of the various divisions in their roles as Lessons Learned Operational Authorities, to effectively operationalize and implement the programme within their command areas of responsibility.

• Each of these appoint a Lessons Learned point of contact to coordinate the Lessons Learned activities and functions for their organizations as well as to address issues that have been forwarded along the chain of command.

• Wing Lessons-Learned Officers embedded in the organisation at wing and formation levels, who provide Lesson learning advice to the wing commander related to missions and mission-support activities.

• Unit Lessons-Learned Officers within the RCAF units who coordinate the documentation and communication of what has been learned during daily activities; liaising directly with their relevant Wing Lessons-Learned Officer. These are like the Lesson Learned  Integrators in the US Army.

You can see how accountability for lesson learning comes down the chain of command (the red boxes in the diagram) from the RCAF Commander right down to Unit level, and how enabling and supporting roles are created at many levels - the LL Programme, the Divisional points of contact, the Wing LLOs and the Unit LLOs.

The principle of delegated accountability down the line management chain enabled by supporting resources is a good one, which can be applied in many organisational setting.

An "accountabilities" view of KM

If you get the KM accountabilities right, the rest of KM structure might just follow.

Peter Senge once pointed out that never mind arguing about the definition of Knowledge, we can't even agree on the definition of Management. He proposed this definition

'Being a manager means taking accountability for the work of others'

Now, this is a definition of a manager, rather than a definition of management, and we could extend it to say

"Management is a system of assigning accountabilities, and ensuring people deliver against these".

What if we took that idea, and applied it to Knowledge Management? We could come up with a statement such as the following:

Knowledge Management is a system of assigning accountabilities for Knowledge and for Knowledge related activities, and ensuring people deliver against these.

I was speaking recently with Jeff Stemke, one-time CKO for Chevron, and he said that the major breakthrough for KM at Chevron was getting the accountabilities right. This was also the experience we had at BP in the mid 2000s. Once accountability was clear, and people knew their role, then they would look for processes and technologies to support their role, and you could apply the governance to make sure they delivered against their role.

So maybe we can follow up our definition of KM above, and look at the subject from an accountability view?

What are the KM accountabilities?

In a mature Knowledge Management framework, we see three chains of accountability (see picture).

 Ownership, organisation and maintenance of the company knowledge base is the accountability of the functional organisation (orange). Individuals within the functions have accountability for developing and deploying best practice, in order to sustain the capability of the organisation. The chief engineer, for example, is ultimately accountable for the engineering competence of the organisation, and therefore for the state of the company engineering knowledge base. He or she will delegate components of this to individual subject matter experts. In addition, he or she will delegate accountability for coordinating the communities of practice which cover engineering topics.

 The line organisation (green) is accountable for the application of the knowledge in the work of the business, and for the creation of new knowledge. If the organisation has clear KM expectations for project or business activity (e.g. that every project should have a knowledge management plan, or that each project stage should be closed by a Retrospect) then the accountability for the line organisation is to meet these expectations. The accountability will probably lie with the project managers, though he or she may delegate some of the KM activity to a delegate (a project knowledge manager for example).

 The KM support team (yellow) is responsible for ensuring that the KM system itself (the tools, the processes, the technologies) are fit for purpose, and are well understood.

Get the chains of KM accountability clear, and you are one big step further towards creating your KM Framework

"Before and After" - the Knowledge Management Makeover

---

What does an organisation look like, when it is fully engaged with Knowledge Management? What will the After shot of the KM make-over look like?

Or to put it more prosaically, what are the roles, the accountabilities, the reporting structures? What is the structure of the knowledge-centred organigram?

It has become increasingly clear to us at Knoco over the years that if KM is to be embedded into an organisation, it needs to be embedded into the organisational structure, as well as into organisational process, the technology infrastructure, and the governance system (including the recognition and reward structure).  The KM organisation is not just a case of

1. The KM team
2. Everyone else

If KM is part of the business, then it needs to be part of the accountabilities as well. For example, at Tata Steel (widely recognised as one of the leading KM companies in the world), the KM team supports a KM organisation of

• 500 SMEs identified by the communities who validate the accuracy and reliability of all the good practices being submitted;
• 25 champions for the various communities;
• 250 practice leaders, who lead the sub-communities;
• 250 conveners who help manage the communities and sub-communities;
• 200 experts who help others over the discussion databases to resolve problems;
• 50 KM coordinators; and,
• 1000+ part-time evangelists. (Figures from 2009)

Or think about the US Army, with

• A full-time Centre for Army Lessons Learned
• An owner for every Doctrine
• Lessons Learned Integrators in every battalion, as well as the training centres
• Combined Arms centre staff who run the Battle Command Knowledge Centre
• Facilitators and core teams for the Communities such as companycommand.mil, platoonleader.mil etc
• Hundreds of trained AAR leaders
• etc

Or Wipro, with

• Full time functional team of 32 in Wipro Technologies (45 in consolidated Global IT Business).
• More than 400 part time KM Primes/Champions across various groups - typically committing 10-15% of their time to KM activities for the group.
• Full time team of 15-20 to support and enhance IS platform for KM.

So one question every organisation needs to think about, when implementing KM, is "What will we look like afterwards".  You will almost certainly need

• KM roles in the operational units and projects, to facilitate the processes and act as champions
• KM roles within the communities of practice, including community sponsors, leaders, core teams, facilitators
• Subject matter experts to look after the codified knowledge base
• People to support the KM technology infrastructure
• People to manage the lessons learned system(s)

You will need a Knowledge Management organisation.  Increasingly, organisational design such as this is becoming a part of our consulting offering, as companies take the KM Make-over.

KM governance in 5 letters

When your KM framework is complete and in place, you need to operate a level of governance to ensure the framework becomes fully embedded.

So what does governance entail?

Let's think about it in terms of 5 letters

• E is for Expectations. Everyone should know the corporate expectations for Knowledge Management; whatever they may be. They might be "Ask, Learn, Share", they might be "Learn Before, During and After", they might be "Every project should have a KM plan, and hold a post-project Retrospect". Whatever they are, everyone should know them.
• A is for Accountability. Everyone should know their personal accountability within the KM framework. Whether they are accountable for making sure a project fulfils its KM expectations, or accountable for maintaining an area of corporate knowledge, or accountable for building and facilitating a community of practice, they should be clear on what this accountability is.
• M is for Metrics. People should, to some extent, be measured against their accountabilities. Did the project follow the KM expectations? Is their area of corporate knowledge being maintained (complete, up to date, accessible, user-friendly)? Is the community of practice healthy and delivering value?
• I is for Incentives. If people meet their accountabilities, this needs to be reflected in their remuneration and recognition. Like any other component of work, "good performance in KM" should get reflected in pay and promotion? ALso "poor performance in KM" should impact pay and promotion.
• S is for Support. People need to be supported in KM. They need to get the training, they need to have the tools, and they need to have the reference material to be able to deliver against their accountabilities and expectations.

If you get E, A, M, I and S correct, knowledge management will become as embedded as any other component of your management system. You get one of these wrong, and KM may become unsustainable.

The four roles in KM

---

This blog post arises from a conversation I have been having with Mary Abrahams over the roles of knowledge manager and content manager and content catalyst, following the "turf war" post below. She asked me about my definition of content, in the context of roles and role descriptions, and we agree that content is recorded material (documents, videos, photographs etc). As the conversation moved into the field of Roles, then I realised that it was becoming too big for a comment on a blog post, and becoming a blog post in its own right.

In a managed KM system, I see four main facilitative roles, which we can link to the four squares of the Nonaka and Takeuchi SECI model, the four squares being

Socialisation - the transfer of knowledge between people,
Externalisation - where tacit knowledge is extrnalised, and then can be recorded (thus creating content)
Combination - where externalised knowledge or content is combined
and refined
Internalisation - where externalised knowledge or content is
internalised or "learnt" by the user

(I just want to say at this point that not all content, in fact only a small proportion, is externalised knowledge. There is a huge amount of content which is information or data. Also not all externalised knowledge, by the N&T definition, is content, but for the purpose of looking at roles, I will assume that we can equate the two. Please feel free to question this assumption, but that would lead us into different territory).

So what are the roles?

Socialisation - the role of the contact broker, for example the facilitator of a community of practice, or the subject matter expert who puts people in touch with people, arranging knowledge visits, conferences, round tables, knowledge exchanges, mentoring, demonstrations, conversations etc.

Externalisation - the role of the facilitator, who facilitates peer assists, AARs, Retrospects, Knowledge handovers, who conducts interviews, and who creates learning histories. This could be close to Mary's "content catalyst" role.

Combination - the role of the knowledge owner, or content owner. There will be a content manager role as well, who manages the repository of the content.

Internalisation - this is a fuzzier area, and this is an area of weakness for many KM programs. The role here is the broker for the internalisation of other people's knowledge. It may be the facilitator of the Business Driven Action Learning exercise, or the facilitator or trainer of other exercises(trainings, briefings, role plays, scenario planning) where people can internalise explicit knowledge.

These roles are in addition to the basic roles of knowledge provider and knowledge receiver/user. They facilitate the flow of knowledge, rather than contribute to it. Also they are not neccessarily roles on the KM team.

These need not be separate people - the knowledge owner or content manager could act as the contact broker, the externalisation facilitator can act as the internalisation facilitator. Or it could very well be more than four people. There may be many communities, each with a facilitator. There may be many facilitators of knowledge capture and knowledge internalisation.

But if knowledge transfer is to work well, these roles are needed.

It's not my job! Recruiting the experts to KM

---

THE BEAD MAKER -- Apprentice Watches the Master
Originally uploaded by Okinawa Soba

Remember the ancient approach to Knowledge Management, of Master and Apprentice? Throughout the middle ages, and into the early industrial age, the Masters were the knowledge holders, and Apprenticeship was the system of transferring that knowledge to a new generation of practitioners of a skill.

Has that survived to the knowledge age? Many clients I speak to are having real problems recruiting the knowledge holders to the concept of KM. Even in those companies where knowledge holders are few, and knowledge seekers are many, the experienced subject matter experts are often reluctant to become involved with KM.

The reason is, that because knowledge is scarce, they are busy doing the job, and have no time to teach. The fewer experienced practitioners the company has, the busier they are in actually performing the work. In addition, many experienced staff are experienced because they enjoy doing the work, and doing it well, and they see KM as a distraction or an added burden. They often feel that KM "is not my job".

"I am an experienced boiler-maker/salesman/brewer/application designer - my skills are in huge demand. Why should I take time out to share my knowledge? That's not my job"

The answer to this, of course, is to make it their job. You can't expect busy people, in demand from all over the organisation, to add to their burdens with work that isn't in their job description. But if their knowledge is vital to company performance, then sharing that knowledge needs to be in their job description. It needs to be recognised as part of their job, and they need to be given the space, the resources, the assistance, and (if necessary) the training to allow them to share their knowledge with the next generation - the apprentice generation.

The old career progression was Apprentice - Journeyman - Master. Knowledge Companies need to rediscover this progression, so that the Masters (of both sexes) - the Subject Matter Experts - can see their role as Teaching as well as Doing, and as passing on their skills to those who need them, through the tools of KM (wikis, community forums, peer assists etc) as well as through the traditional tools of apprenticeship (coaching, mentoring, training).

(The need for Knowledge Retention, described in the white paper available here, is often a symptom that the SMEs have become disengaged from knowledge sharing)

Accountability in Knowledge Management (2)

---

To continue the discussion on Accountabilities for Knowledge Management - lets discuss, who is accountable for KM, and what accountabilities do they have?

In a mature Knowledge Management framework, we see three chains of accountability (see picture).



Ownership, organisation and maintenance of the company knowledge base is the accountability of the functional organisation (orange). Individuals within the functions have accountability for developing and deploying best practice, in order to sustain the capability of the organisation. The chief engineer, for example, is ultimately accountable for the engineering competence of the organisation, and therefore for the state of the company engineering knowledge base. He or she will delegate components of this to individual subject matter experts. In addition, he or she will delegate accountability for coordinating the communities of practice which cover engineering topics.

The line organisation (green) is accountable for the application of the knowledge in the work of the business, and for the creation of new knowledge. If the organisation has clear KM expectations for project or business activity (e.g. that every project should have a knowledge management plan, or that each project stage should be closed by a Retrospect) then the accountability for the line organisation is to meet these expectations. The accountability will probably lie with the project managers, though he or she may delegate some of the KM activity to a delegate (a project knowledge manager for example).

The KM support team (yellow) is responsible for ensuring that the KM system itself (the tools, the processes, the technologies) are fit for purpose, and are well understood.

Accountability in Knowledge Management (1)

---

Here's another quote from the Peter Senge video I mentioned yesterday. He implied that - never mind arguing about the definition of Knowledge, we can't even agree on the definition of Management. He proposed this definition

'Being a manager means taking accountability for the work of others'

Now, this is a definition of a manager, rather than a definition of management, and we could extend it to say

Management is a system of assigning accountabilities, and ensuring people deliver against these.

I wonder what would result if we took that idea, and applied it to Knowledge Management? I was interested to try this, because for me, accountability is key to management, and accountability is seldom a concept people apply to knowledge*

Perhaps if we follow this train of thought, we could conclude

Knowledge Management is a system of assigning accountabilities for Knowledge, and ensuring people deliver against these.

That's a very interesting definition, and I think it could take us to some powerful conclusions, which I would like to develop further in another blog post, when I have clarified my thinking a bit more.

* However I think they should! One of the recent breakthroughs we made at BP was assigning clear accoutabilities within KM. Read more in our Dec 07 Newsletter