How organisational demographics affect Knowledge Management

The demographics of your organisation determine the distribution of knowledge, and therefore the details of the Knowledge Management Framework you need to deploy

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

Because the demographics are is linked to the distribution of knowledge across the staff, it determines how many sources of knowledge you have, how many net users, and the balance between the two.

For example:

• A company with very many experienced staff will have many knowledge suppliers, each of whom is also a knowledge user, and will therefore have to find an efficient and effective way to allow these people to compare, combine and continuously improve the knowledge they have.
• A company with very many junior staff and few experienced staff will have few knowledge suppliers and many knowledge users, and will therefore have to find an efficient and effective way to provide the knowledge of the few, to the many.

 Lets look at two examples. 

An organisation with many experienced staff. 

This is a profile you see in many Western engineering organisations. 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 - the blue line in the graph above.

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. Knowledge can easily be kept largely tacit. The engineers know the basics, and a short call to their colleagues fills in any gaps. The biggest risk is knowledge loss, as so many of the workforce will retire soon, and a Knowledge Retention strategy would be a good investment.

An organisation with many inexperienced staff 

In many parts of the world, such as the BRIC countries, the economy is growing, the population is growing, there is a hunger for prosperity, and engineering (in contrast to the West) may be a growth area. The workforce in a growing organisation may be 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 - the red line in the chart above.

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 so much Retention of knowledge (although of course the knowledge of the few experts is vital and must be protected), but is more about deployment of knowledge. The reliance on a few experts means that they must be given a Knowledge Ownership role, rather than using them on projects.  Rather than keeping knowledge tacit, it makes sense to at least document the basics in explicit form (the experts will be too busy to answer basic questions), though there is of course a need to keep this documentation updated as the organisation learns.

The KM framework  

These two demographic profiles would lead you to take two different approaches to developing a KM framework. The first (experienced) company would introduce communities of practice, and use the dispersed knowledge 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 second (largely inexperienced) 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".

It would be a mistake for an organisation in the second category to copy a KM framework from an organisation in the first category, and vice versa.

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

There is no "silver bullet" for knowledge management. Here's why

There is no silver bullet for Knowledge Management, because KM is a management system with many component parts, all of which need to be in place. 

Bar Silver Bullet by Sprott Money on Flickr

We often hear vendors promising us a KM silver bullet - usually some sort of technology. "Buy our search engine/Collaboration software/enterprise social app/remote working platform and your KM problems will be solved".

But it doesn't work like that I am afraid.

Knowledge Management requires more than technology, it needs a management system. And as ISO 30401 reminds us, this system has many elements. For example it should cover the four enablers of

• Roles and accountabilities; roles such as CoP leaders, Knowledge Managers, and Knowledge Owners
• Processes; specific KM processes such as After action review, Lessons Capture, Knowledge Asset creation etc
• KM Technology, a suite of tools such as portals, collaboration tools, search engines, lesson management systems etc.
• Governance, such as KM policy, metrics, incentives, support etc.

ISO 30401 adds the 5th enabler of KM culture - which ensures that when the management system is in place, it is applied, supported and sustained.

All of these elements are mutually supportive. There is no point in introducing one of them (collaboration tools, for example) without addressing the others as well.

Also many of the promised solver bullets cover only one aspect of Knowledge Management, such as searching, or allowing conversation. However there is no point in searching for knowledge, without addressing the possibility that the knowledge is still tacit and can only be accessed through conversation. Also there is no point in conversation if the knowledge needed lies beyond the memories of individuals, and is documented somewhere, waiting to be found.

ISO 30401 also tells us that the roles, processes, technologies and governance need to address:

• Transfer of tacit knowledge through conversation; in networks, Peer Assist, communities of practice, mentoring and coaching;
• Codification of knowledge; in lesson learned systems, A3 sheets, and community- created guidance;
• Synthesis of multiple sources of codified knowledge into one set of guidance - a Knowledge Asset;
• Finding, reviewing and internalising codified knowledge in some sort of planned learning process.

Knowledge Management is therefore a management system, with a framework of components which need to be interlinked in order to deliver a functioning knowledge workstream within the organisation. 

• Search technology is therefore not a silver bullet, as without processes, roles, governance and culture there will be no documented, synthesised and maintained body of knowledge to search, and no behaviours of seeking or of applying any knowledge which is found.
• After Action Reviews are not a silver bullet. Although they can be very useful in helping teams improve their internal process, any knowledge generated is unlikely (without the existence of a management system) to find its way to other teams which need it, nor to update the body of knowledge. 
• Communities of practice are not a silver bullet (though they come close) as they address only the functional axis of organisational matrices, and not the project axis.
• Even Peer Assist (though it also comes close) is not a silver bullet, as it covers only the element of tacit knowledge seeking; one of the generic 4 dimensions for KM.

In most organisations therefore, introducing Knowledge Management is not a case of introducing one component - one silver bullet.  It is a case of introducing a system - a new way of working, and a new way of thinking.

Think System, not Bullet. 

An analogy to help you understand a Knowledge Management Framework

We know that Knowledge Management requires a management framework, rather than a silver bullet technology. But how do we explain what a management framework is?

We know that KM requires a framework of roles, processes, technologies and governance, but how do we explain this to our managers; especially the ones that think that buying new technology will solve the issue?   ISO 30401 calls the framework a "knowledge management system", but many people hear the word "System" and interpret this to mean a technology system, which is why I personally prefer the term framework.

The best way to explain the concept of a management framework is to use an analogy.

The analogy I commonly use is to compare the Knowledge Management Framework with other management frameworks, showing that these are also an interconnecting framework of people, processes, technologies and governance, which cannot work if there are holes in the framework.

One of the easiest to understand, because everyone has some involvement with it, is financial management. I know knowledge and money are not the same, but both require a company-wide management framework if they are to flow round the company in an effective and systematic way.

If you Google "Financial Management Framework", this will give you many examples, most of which contain common elements, and most of which contain a mix of people, process, and governance (strangely technology is often missing from these frameworks, presumably either because financial technology is pervasive and taken for granted, or because the framework should be technology-independent).

Let's look at some of those common elements, and then let's ask what happens if some of these are missing.

People
Financial Management frameworks all contain defined roles and responsibilities, such as:

• Budget holders - the people accountable for money within projects and operations;
• Accountants and Cost engineers - the people doing the nuts and bolts of money-tracking;
• Central finance team - the people who shuffle money between the projects and operations;
• CFOs and Finance Directors - the people accountable for the financial management system itself

Processes

Financial Management frameworks all contain certain processes, such as:

• Financial planning and forecasting;
• Budgeting;
• Invoicing;
• Expenditure management;
• Cost tracking;
• Timewriting;
• Reporting.

Governance

All Financial Management frameworks mention governance, which typically includes:

• Financial policies;
• Monitoring;
• Auditing;
• Training and support.

If there were mention of technology, this would include

• Technology for logging and tracking transactions, such as SAP;
• Technology for reporting of figures, such as Excel;
• Technology for counting, such as a calculator or cash register.

All of these fit together into a financial management framework, and the complexity and completeness of that framework needs to fit the scale of the operation. The framework listed above has 18 elements; large companies can easily have more elements. My small company has fewer. If you were selling tickets for a village fete, you framework would be simpler still - a treasurer, a money pot, a book of tickets, a bank deposit account, and a report to the organising committee.

What would happen if there were holes in the Financial Management framework? 

Let's pick a few items from the framework listed above, remove them, and imagine what would happen.

• If there were no budget holders there would be no attention paid to financial management within the projects and operations, because it's nobody's job.
• If there was no process of financial reporting then financial management would fall apart, because the company would have no record of money gained or spent during operations.
• If there was no consistent technology, there would be no way of comparing and compiling financial figures from across the organisation.
• If there was no auditing, there would be no way of knowing if people were doing proper financial management, people would cut corners, fudge figures and put money into their own pockets, and pretty soon a consistent approach to financial management would disappear.

So there's our analogy. Financial management needs a minimum framework consistent with the scale of the business, and if there are holes in that framework, financial management becomes impossible.

It is the same for knowledge management

Knowledge management needs a minimum framework, and if there are holes in that framework, knowledge management becomes impossible. Here are some equivalents to the holes mentioned above

• If were no people accountable for KM within projects and operations, then KM just would not get done. There would be no attention paid to knowledge management within the projects and operations, because it's nobody's job.
• If there were no process of knowledge reporting (knowledge capture) - then knowledge management would fall apart, because the company would have no record of new knowledge gained during operations.
• If there were no consistent technology for knowledge management, knowledge management would be a mess, as there would be no way of comparing and compiling and communicating knowledge from across the organisation.
• Imagine there was no equivalent of auditing there would be no way of knowing if people were doing proper knowledge management, people would cut corners and fudge figures and keep knowledge in their own heads, and pretty soon a consistent approach to knowledge management would disappear.

So if your managers question the need for a KM Framework, and ask (for example) "do we really need defined roles for KM?", then ask them to imagine a financial management framework without defined roles.

The Financial Management framework is one of your better analogues for explaining the Knowledge Management framework.

Contact Knoco for help in designing your Knowledge Management Framework

The importance of Joined-up KM

One of the major differences between a Knowledge Management Toolbox and a Knowledge Management Framework is that in a framework, the components are joined up.

Image from wikimedia commons

I have blogged before about the evolution in KM thinking from tool, to toolkit, to framework. I have argued that the framework is more complete than the toolbox, as it includes not just a listing of the processes and technologies, but a definition of when they are expected to be used, and by whom. The framework adds the governance element (the expectation), and the roles element (the "by whom").

The framework defines how KM is embedded into the work process and into the accountabilities in the organisation. Instead of the toolbox lying unopened in the garage, it is brought in and put on the table; made a part of how you work.

However there is one other main advantage to the framework, which is that it allows the elements of KM to be joined up.

When KM is treated as a kit of tools, there is a risk that each tool exists in isolation. The lesson learned tool collects lessons in a database, the knowledge retention tool creates retention reports, the community of practice tool hosts discussions, the video tool creates a library of videos, and the best practice tool creates a library of best practices. 

Where then do you seek for knowledge? Is the answer that you seek in the lessons database or the community forum, in a video or a retention report, or in the best practice collection? Or, in the worst case scenario, do you find contradictory answers in each? Or does each have its own taxonomy, making the seekers job even harder?

In a framework, these disparate tools are joined up, perhaps in the following ways:

• The community of practice leader is also the practice owner, accountable for making sure best practice guidance is developed where possible
• The community discussions, when complete, are converted into best practice guidance
• The results of knowledge retention exercises are also used to update best practice
• Videos are embedded into the best practice guidance
• The lessons learned system makes sure the practice owners are notified of any new lesson in their area of practice
• New lessons are notified to, and can be discussed by, the relevant communities
• After discussion, the relevant practice is updated based on the new lesson
• The structure of the communities is based on the same taxonomy as the best practice system and the lessons management system
• The metadata and taxonomy set is consistent across all three elements as well
• The operation of the communities and the creation of the best practice guidance is monitored and reported together.

So instead of these components being separate tools in a box, they become part of an interlinked framework, through which knowledge flows (as in this example from NASA). The joining-up allows the flow, and completes the framework.

Contact us for advice on turning your KM toolbox into a joined-up framework.

Why it is important to audit KM regularly.

There is a lot of value in a KM audit, so long as you do it regularly.

In this post, I suggested that there are two types of KM surveys; the audit and the assessment. I said the first was like counting the apples in your orchard, the second was like reviewing your farming methods.

It is the assessment - the methods review - that has the most value, in that it tells you how to improve your knowledge management approach. However the audit is also valuable, in telling you where you need to focus, and which problems you need to solve. There is merit in running both regularly. 

The audit measures the current management status of various knowledge topics - are they documented, are they covered by communities, are they held only in the heads of a few people approaching retirement? When you introduce your improved KM approaches, the audit should show improvement.

Our favoured approach to run the audit on an annual basis. It works like this

• The KM team works with the knowledge owner, or process owner, to audit their own knowledge area.
• Based on the results of the audit, they identify actions for the following year
• The next year, the audit should show improvement
• The KM team can use the audit results, and the change in results over the year, to construct a KM dashboard for reporting to senior management. If KM is working, all audit scores should show an increase over the previous year.

The Assessment measures how well the KM framework is operating, and whether it needs to be tweaked, augmented or updated. ISO 30401:2108, the ISO management systems standard for KM, requires the organisation to have a plan for regular internal audit of the KM framework against the organisations needs and the requirements of the standard. This is in order to drive continual improvement of KM. The assessment probably does not need to be done annually - maybe every 3 or 5 years might be more appropriate. But it needs to be done regularly. 

As part of your KM governance, make sure you conduct regular audits and/or assessments both of the health of the KM framework, and also of the level of management applied to key knowledge domains. 

4 flavours of KM - which one do you work with?

The more time I spend in the field of KM, the more I see certain brands of flavours of the field which share a common name (knowledge management) and common principles, but can use very different roles, processes and supporting technologies.

Image from wikipedia

Below are the main flavours I see, together with some of the common elements you find within their KM frameworks. Sometimes different flavours are seen in different divisions within the same organisation - Practice-flavoured KM in the project department, Product-flavoured in the Engineering department, customer-flavoured in sales and marketing. These different flavours of KM can use very different processes, technologies and roles - even within the same organisation.

Please let me know via the comments section if you have an additional flavour to add to the mix.

1. Practice-flavoured KM

This is the brand of KM which I was brought up on, in the early stages of my 28-year KM career.

This flavour of KM focuses on know-how and on practice and process improvement to support increased operational effectiveness and efficiency. You see this brand of KM in the military, the oil sector, the construction sector, charities, and other organisations focused on "doing stuff". 

Practice-flavoured KM is based around communities of practice, best practices, learning from experience, and process innovation, supported by community collaboration software, wikis and process documents such as Standard Operating Procedures.

Engineering-product-flavoured KM

This flavour of KM focuses on capturing and reproducing the expert knowledge of product design and manufacture, primarily in industries such as the car industry, the aerospace industry, defence contractors and so on. It's aim is to make expert design knowledge available, in order to increase quality and reliability in future products. It often uses knowledge-based technology to support computer-aided design.

The components of engineering-product-flavoured KM include knowledge engineers, knowledge acquisition programs (for example using the MOKA methodology), concept mapping and A3 diagrams, supported by a Knowledge Based system or expert system such as ICAD.

Document-product-flavoured KM

This flavour of KM focuses on creating knowledge-based document products to customers, primarily in areas such as the legal industry, education, aid and development, and many areas of government. It's aim is to provide the best knowledge and advice to customers and clients, through access to a wide and up-to-date knowledge base.

The components of document-product-flavoured KM include researchers and analysts, evaluation programs, library staff, and communities and networks focused on specialist areas of interest (specific client industry groupings, specialist legal advice areas and so on). Supporting technology is usually provided by excellent document and information management, and portal technology. AI and semantic search can help.

Customer-flavoured KM

This flavour of KM focuses on supplying knowledge to customer-facing staff, or even providing self-help knowledge directly to customers. It's aim is to build a strong customer base through effective customer support. You see this brand of KM in the retail sector, financial services, and media companies.

Customer-flavoured KM is based around communities of brand and communities of product, customer relationship management integrated with KM, and the development of knowledge articles within a knowledge base (of which there are many commercial examples). Chatbots can be used to support customers directly.

When seeking analogues, be aware of these different flavours, because the KM solutions do not always map across from one to another. 

5 universal principles for Knowledge Management

There is no universal solution for Knowledge Management in an Organisation, but there is a set of universal principles.

A Management Framework for KM is bespoke - not off-the-peg. Each organisation must find its own solution , and must design its own Framework. There is no template, no universal solution, no single toolbox of KM technologies, no "KM Ultimate Swiss Army Knife", no one magic system that does it all, no single KM Process set, no a single design for set of KM roles, no universally applicable KM policy that all companies can adopt.

However I believe there IS a universal set of 5 Knowledge Management principles that every successful Knowledge Management application adopts, and which form the foundation for a successful KM framework. 4 of these principles are embedded within ISO 30401:2018, the ISO management systems standard for KM.

Please note, these are the principles behind KM framework design, not the principles for KM strategy [which are about the vision and direction for introducing KM], or the principles for KM implementation [which is how the framework will be developed and rolled out].

These Principles are as follows.

1. Aligned. The KM framework must align with the needs and strategy of the organisation.

Knowledge Management should not be introduced for its own sake; it should be introduced because it solves business problems and helps the organisation perform better. ISO 30401:2018 supports this by,  in the first two requirements, asking for an understanding of how KM supports the organisational context, and for a mapping of the stakeholders and their needs. These two tasks form the foundation for the Management Framework.

The primary value of knowledge is helping people make better decisions, and so perform work better, faster and/or cheaper. There are secondary values as well (helping people fell more engaged, more connected, more supported) but all of these are also in service of a better organisation.  Knowledge management for its own sake can often destroy value, as this example of misplaced collaboration shows.

Your knowledge management framework therefore needs to focus preferentially on the knowledge of highest organisational value (ISO clause 4.3), and of providing the highest value and highest utility knowledge to the knowledge workers and other stakeholders at the place and the time that they need it (hence the concept of KM as a Knowledge Supply Chain).

Unfortunately business alignment is the second weakest of all the elements in our free online self-assessment survey, which suggests that this principle is not always followed.

2.  Connect/Collect. The KM Framework must include Connect and Collect (aka Conversation and Content)

One of the earliest models in the history of Knowledge Management, and one that sometimes seems to get forgotten, is that there are two key dimensions in Knowledge Management, representing two routes between the knowledge suppler, and the knowledge user.

These are the Connect route, and the Collect route.

The Connect route supports knowledge transfer through connecting people and focuses on tacit knowledge.  The Collect route supports knowledge transfer through collecting knowledge into documents and focuses on codified knowledge.

Connect and Collect are not alternative strategies. They are two components of a single framework and a single strategy, which work in parallel.  Your organisation will contain critical knowledge of very many kinds; some of it managed as Content, and some as Conversations.  Conversations are a far richer medium than Content,  potentially 14 times richer, though Content can reach far more people, and has a longer life-span than a conversation.

Content and Conversation are the King and Queen of Knowledge Management - they rule together. Content is something to talk about, Conversation is where Content is born and where it is Tested.

In clause 4.3.3, the ISO standard requires organisations to address Connection through Human interation, and Collection through a) the representation of human knowledge in the form of documents, videos, and other artefacts: b) the combination and synthesis of documented knowledge, and c) the internalisation and reuse of knowledge.

3. Push and Pull. The framework must address Push and Pull (aka knowledge supply and knowledge demand)

I have blogged many times about push and pull in KM - push being the transfer of knowledge driven by supply (eg speculative publishing, or loading material to a database or wiki), and pull being the transfer of knowledge driven by demand (eg asking a question on a forum, or searching an Intranet).

 The ideal KM system runs push and pull in parallel - both supply and demand as valid ways of instigating the knowledge flow.

Push without pull (supply without demand) leads to knowledge over-supply and overload, and to ultimate destruction of knowledge value. Pull without push is better, but is ephemeral. Knowledge management, whether you view it as a market or as a supply chain, needs both supply and demand - both push and pull - if it is to function.

ISO 30401 does not address Supply and Demand, unfortunately.

4. The 4 legs. The KM framework must include Roles, Processes, Technologies and Governance

There are 4 enablers that support Knowledge Management, like 4 legs that support a table. These are

• The technology elements, such as portals, collaboration tools, search engines, lesson management systems etc.
• The elements of roles and accountabilities, such as CoP leaders, Knowledge Managers, and Knowledge Owners
• The process elements, such as After action review, Lessons Capture, Knowledge Asset creation etc
• The governance elements, such as KM policy, metrics and incentives, support etc.

Like the 4 legs on a table, the 4 elements of KM are all equally important. No single element is dominant - they all support KM, and they support Knowledge Management in supporting the business.  Focus on all four enablers, to an equal extent, and your Knowledge Management table will stand firm and secure in support of the organisational strategy.

Clause 4.4.4 of ISO 30401:2018 contains the requirement to address these 4 enablers, plus the additional factor of culture. I do not include culture here, as I believe culture is an outcome of the management framework rather than part of the framework. The ISO standard goes on to include specific sections on three of these enablers:

• 3 clauses addressing Roles (5.3, 7.1, 7.2)
• 1 clause addressing Process (section 8)
• 14 clauses on governance (5.1, 5.2, and all of sections 6, 7, 9 and 10)

5. Embedded. KM must be embedded into the structures of the organisation.

Lots of KM programs do not take root, because they have never been embedded in normal business. They are delivered by a strong team and a charismatic leader delivered as something separate - not fully rooted in the work structure and management framework of the company. They are like a tree in a pot - well tended, well watered, but separate - and when the tender care is removed, the organisation tips back. KM needs to be like a tree in a forest - rooted in the fabric of the business.

The goal is to embed a self-sustaining approach to KM in all elements of the business, with clear governance and good support, and clear evidence of sustainable culture change and sustainable business value.

Change the project requirements, to include KM. Change the minimum conditions of satisfaction for project delivery, to include effective lessons identification. Change the rules for project sanction, so a project gets no money if it hasn't done any learning. Change the job descriptions for the company experts, so that they are held acountable for stewardship of the company knowledge. Change the reporting requirements, the HR appraisal mechanism, change the incentive scheme to reward collaboration and discourage competition. Change the rules on timewriting. Notice the use of the word "change" there? Every such change is another KM root going down.

ISO 30401 requires these changes to be in place, and that top management ensures "the integration of the knowledge management system requirements into the organization’s business and project processes".

Using the 5 principles

Use these 5 principles to design your Knowledge Management Framework, with guidance from ISO 30401:2018. You will still need to decide

• What the critical business knowledge is, that you need to align to
• How to connect people and set up conversations
• How to collect knowledge and manage content
• How to create a demand for knowledge
• How to create a supply of knowledge
• Which roles to put in place
• Which processes to adopt
• Which technology to use
• What governance to apply, and
• How and where to embed the roles, processes, technology and governance.

However the principles will ensure that the framework you create works well, is stable, has no gaps, covers all relevant types of knowledge, and will not "tip back" to the previous pre-KM state.

Contact Knoco if you need any help in designing your KM framework.

How to apply Knowledge Management to 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. 

Image from wikimedia commons,
Merger of KCR and MTR operations 2007-12-02

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, where 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 and Acquisitions (and let's include Divestments as well) should be as follows; 

• Learning Before. Through Peer assists and other knowledge-seeking activities, the M&A team should seek to acquire lessons, guidance, success factors and pitfalls from previous Mergers, Acquisitions and Divestments. They may conduct a Knowledge Gap Analysis, to map out the knowledge they need to acquire, and should create a Knowledge Management Plan for the M&A project. 
• Learning During. If possible, and for high value Mergers, Acquisitions and Divestments only, a Learning Historian should be seconded to the M&A team to capture lessons, practices and key documents as the exercise progresses, perhaps through a series of After Action Reviews. 
• Learning After. Interviews and Retrospects of the key players should be held to determine the success factors to repeat, and the pitfalls to avoid. The focus here 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 should 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 should 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. Of course, the framework chould be compliant with ISO 30401:2018. 
• 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 

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, with savings on external consulting spend in the order of $1 million.

Is KM a tool, a toolbox, or a management framework?

What is the Knowledge management solution? That's a question that's been debated for two decades, but I would like to take a high-level approach to the question and ask - is the solution a tool, a toolbox, or a management framework?

Image from wikimedia commons

Is it a tool?

Many organisations start the knowledge management journey believing that the solution to Knowledge Management is a tool. They introduce Yammer, for example, and hope that the connectivity we see in the world-wide web via Twitter will translate into sharing of valuable in-house knowledge. Or they buy a wiki, or knowledge-base software, or get SharePoint, and expect that an in-house equivalent of Wikipedia emerges.

Of course the problems are not solved. One tool does very little to dent the huge issue that is KM. KM has many aspects, and expecting one tool to deliver KM is like buying a hammer, and assuming your home repairs will all be sorted.

Is it a toolbox?

Pretty soon, people realise that one tool does not solve all problems. This is especially true when it comes to KM process - there are a suite of processes that can be applied in different situations; from Peer Assists to After Action Reviews, to Knowledge Exchange circles, and so on. Any one such process is not enough, you need a suite. And the technology tools very rarely stand alone, no matter what the vendors tell you. Any KM technology that claims to be a Jack of All Trades is really a Master of None.  Different KM needs require different (though linked) technologies to satisfy them.

So the companies build a toolbox. "Here are the KM tools" they tell the knowledge workers - "Use them when applicable".  Most of us have such a toolbox in our house, for home improvements. Most of these toolboxes (other than those owned by the enthusiasts) linger untouched in the basement or garage.

The same is true of the KM toolboxes. The enthusiasts use them, but they never get into the mainstream.

Is is a management framework?

Yes, it is. Tools don't get used regularly unless people know how to use them, when to use them, and realise its their job to use them. The framework you need for Knowledge Management includes not just a listing of the processes and technologies, but a definition of when they are expected to be used, and by whom. The framework adds the governance element (the expectation), and the roles element (the "by whom") to the processes and technologies. The ISO KM standard, ISO 30401, is based on the view of  KM as a management framework (they call it "management system").

This management framework defines how KM is embedded into the work process and into the accountabilities in the organisation.  Instead of the toolbox lying unopened in the garage, it is brought in and put on the table; made a part of how you work.

If we stick with the analogy of tools, you can imagine an operating theatre as an example of a framework. Yes, the surgical tools are vital, but the surgical toolbox alone does not result in effective operations. You also need the roles (the surgeon, the anaesthetist, the theatre nurse) and the governance (the expectations on each party, the support and training they have, the checklists they use, and the metrics that are gathered). Just having a box of surgical tools does not mean that you can perform effective surgery.

Knowledge Management is not heart surgery - it is far simpler and far easier. However it still needs to be addressed as a management framework - not as a toolbox, and certainly never as a single tool.

Contact us for help in designing your Knowledge Management Framework

The 4 legs on the KM table - comparison of Google vs ISO

A recurrent theme on this blog is to address "the 4 legs on the Knowledge Management table" - the four enabling elements of the Knowledge Management Framework (and indeed of any management framework) - roles, processes, technology and governance.

Two days ago I published a quick exercise, looking at the relative "Google ranking" of these four elements, as a proxy measure of where the attention typically lies, and comparing this with results 5 years ago.

• A search for "knowledge management process" gave  632000 hits
• A search for "knowledge management technology" gave 416,000 results
• A search for "knowledge management roles" gave 169,000 results
• A search for "knowledge management governance" gave 122,000 results 

These figures show an imbalance between the 4 elements  (although less so than in 2015) with far more attention paid to KM processes and KM technology than to KM roles or governance.  My colleague Ian Fry in Australia then suggested we look at ISO 30401:2018 for a good coverage of governance.  So I went through the various clauses of ISO 30401:2018 to determine which referred to each of the 4 elements. The results are shown in the chart below, and are very interesting.

The plot above shows the results. In ISO 30401 there are

• 4 clauses addressing Roles (4.4.4, 5.3, 7.1, 7.2)
• 2 clauses addressing Process (4.4.4 and the single clause in section 8)
• 1 clause mentioning technology (4.4.4)
• 15 clauses on governance (4.4.4, 5.1, 5.2, and all of sections 6, 7, 9 and 10)

So the view of KM on Google (its all about KM process and technology) and the view of KM on ISO (its all about governance) are diametrically opposed.

Now to an extent that is to be expected, as ISO is a governance document, but it certainly shows that, for organisations wanting to comply with the ISO standard, governance is something that no longer can be neglected. There is no point, for example, in having a toolkit full of processes and technologies if there is no planning, no leadership, no policy, no objectives, no measurement of results, no regular audit, no controlled documentation and no means of continuous improvement of the KM Framework.

Hopefully an increased use of the ISO KM standard will lead to a further balancing of the 4 critical elements that form the 4 legs of the KM table.

Product Life-cycle Knowledge Management

Product life-cycle management (PLM) is a well-established discipline. To support this, we are going to need Product life-cycle knowledge management. 

Image from wikimedia commons

In industry, product lifecycle management is the process of managing the entire lifecycle of a product from inception, through engineering design and manufacture, to service and disposal of manufactured products.  Industry has already made big strides with using shared data systems to support the lifecycle of a product. Similar strides can be made in using Knowledge Management approaches.

PLKM differs from standard practice-based KM.

• Instead of Communities of Practice, we need to look at Communities of Product (or Product line, or product family). The Community members will cover the lifecycle of the product; from development through manufacturing through sales to service and maintenance,and back to redevelopment. 
• Instead of Best Practice, we look at Best Design
• Knowledge is passed along the value chain; downstream from development to manufacturing, from sales to service, and back upstream from service to development.
• The key knowledge is mostly "Why" knowledge - why the product was designed the way it was, why design changes were made, why the marketing has taken the chosen approach, why failures happen in service, and so on. 
• The taxonomy will not be a practice-based taxonomy, but will align with the product tree
• Some of the KM processes will be different as well. Specifically the A3 report will replace the After Action Review.

For those of us who are working in a product-based organisation and who are looking to introduce KM into a PLM structure, we need to be thinking in terms of Product Lifecycle Knowledge Management. 

Are the legs on the KM table getting less wobbly?

A recurrent theme on this blog is to address "the 4 legs on the Knowledge Management table" - the four enabling elements of the Knowledge Management Framework (and indeed of any management framework) - roles, processes, technology and governance.

In a 2015 blog post entitled "the wobbliest legs on the KM table" I looked at the relative "Google ranking" of these four elements, as a proxy measure of where the attention typically lies. The results showed that there was far more published on technology and Process than on Governance and Roles.  Today I decided to repeat the exercise.

• A search for "knowledge management process" gave  632000 hits (up from 330,000 in 2015)
• A search for "knowledge management technology" gave 416,000 results (up from 264,000 in 2015)
• A search for "knowledge management roles" gave 169,000 results (up from 68,000 in 2015)
• A search for "knowledge management governance" gave 122,000 results (up from 34,700 in 2015)

We can see two things from these figures - firstly the number of hits has increased (as you might expect, given that google hits are cumulative), and secondly that the imbalance between the 4 elements seen in 2015 is beginning to lessen, as shown in the plot below.

This plot shows the relative attention given to these elements, in the quick surveys in 2015 and 2020, measured by Google hits. So for example in 2015 "knowledge management roles" received just under 10% of the total hits, and in 2020 this is up to 12%. The proportion of hits on "knowledge management governance" is still low, but double what it was in 2015. The proportion of hits on "knowledge management technology" has decreased.

Now in reality attention is needed to all 4 of these elements.

• If there are no roles and accountabilities, then Knowledge Management is nobody's job (or else, it's "everyone's job" which soon becomes "no-one's job") 
• If there are no processes for KM, then nobody knows what to do, or how to do it. 
• If there is no Technology for KM, then nobody has the tools, and KM can never extend beyond the immediate and local 
• If there is no Governance, then nobody sees the point. KM remains an optional activity, and nobody has time for optional activity.

If these are the 4 legs of the table, it is still a wobbly table, with 2 strong legs getting all the attention, and 2 weaker legs. However its not quite as bad as it was 5 years ago.

The message remains this  - if your KM programs are going to be in balance, you need to address all 4 legs of the table. Your processes and technologies may well be fine - you need to bring your roles and governance up to the same level. The evidence is that this is beginning to happen. 

Content and Conversation - equal and complementary focus areas for KM

I  blogged recently about Connect and Collect - the two parallel approaches to transfer of knowledge. Now let's look in more depth about the two modes by which knowledge is carried - Content and Conversation. 

Kids of conversation by Kris Hoet on Flickr

During the Connect approach we facilitate the transfer of knowledge through Conversations, whether these are online conversations or face to face meetings.

During the Collect approach we facilitate the transfer of knowledge through captured and codified Content in the form of documents, files, text, pictures and video.

We also know that Conversations are a far richer medium than Content, potentially 14 times richer, though Content can reach far more people, and has a longer life-span than a conversation.

Any comprehensive Knowledge Management framework needs to enable, promote, facilitate and otherwise support both Conversation and Content.

Focusing on conversation and focusing on content are not alternative strategies, they are complementary and interlinked. Neither approach is sufficient on its own (although the content-only focus seems very common), and each relies on the other.

Managing conversation without content leaves no trace, other than in the minds of the people involved. That in itself is useful, and we know that most of the processes of Knowledge Management, such as Retrospect, After Action Review, Peer Assist and so on are valuable individual learning experiences. But managing conversation without content is not a valuable organisational learning experience. Unless new knowledge becomes embedded in process, or guidance, or recommendations, it is never truly "learned", and without this we find knowledge becomes relearned many times, with errors being repeated, wheels reinvented and so on.

Managing content without conversation leads KM towards the already established fields of Content Management and Information Management, and you could (as the author of the famous "Nonsense of Knowledge Management" did) challenge what KM adds over and above these other disciplines. A focus on content without conversation results in a focus on publishing; on creation of reports and files, blogs, wikis, as a proxy for the transfer of knowledge; on Push rather than Pull. But unless people can question and interrogate knowledge in order to internalise it, learning can be very ineffective, and this approach always seems to deteriorate into technology, search, and the perennially soon-to-be-delivered benefits of AI.

There is a saying in social media circles that "Conversation is King, Content is just something to talk about". Like any other dualism-based statement, this is wrong. Knowledge Management, as a field, is far more "both/and" than it is "either/or".

Content and Conversation are the King and Queen of Knowledge Management - they rule together.

• Content is something to talk about
• Conversation is where Content is born and where it is Tested.

As a Knowledge Manager, please focus equally on both, and please do not assume that all Conversation needs to be by written means. Face to Face is still the preferred transfer mechanism for high-context knowledge, and "getting people together to talk about what they know" is an amazingly effective tool within your Knowledge Management Framework.

Make sure you promote and support Conversation and Content as equal partners in your KM Framework. 

A new way to differentiate Industry approaches to KM?

If you are interested in how different industries approach KM, here is a new way to differentiate them. 

Different industries tend to approach KM in different ways, or apply KM in "different flavours."  In September I posted a ternary plot, where different industries were plotted on their relative focus on Product Knowledge, Process Knowledge, or Customer Knowledge. Below is a similar plot, but looking at the preferred "default approach" to KM.

This plot is derived from answers to our KM surveys in 2014 and 2017, answered by more than 700 knowledge managers worldwide. One of the questions asked the respondents to list, in order of importance, a series of KM components (communities of practice, for example). In this plot we look at three components, 

• Connecting people through communities of practice;
• Learning from Experience;
• Improved access to documents (including search and portals)

The plot maps out the percentage of companies from each industry which chose each one of these three as their top area of importance. Of course for many companies, all three were important, but for this plot, we look at which of these three components was chosen as MOST important.

A Ternary plot such as this one shows a choice between three components, measures on three axes (labelled in the plot above) and the closeness to each of the apices shows the proportion of companies in that industry which chose that KM approach as the most important of the three. For example, the data point on the far left, the "Legal" data point scores 

• 71% on the axis "improved access to documents"
• 26% on the axis "connecting people through communities", and
• 3% on the axis "learning from experience"

This represents the views of the 35 survey respondents from the legal industry concerning which of these three was most important for KM. 

What is interesting about this plot, is that the points are well spread out, suggesting that this is a way to differentiate some of the industries. 

• Legal, for example, sees access to documents as the most important of these 3 KM tasks. Finance/Insurance and Health are similar. 
• Oil and Gas, on the other hand, sees a mix of communities of practice and learning from.experience as more important (only 15% of respondents voted for "improved access to documents").
• IT/telecoms has the highest proportion of people preferring "connecting people through communities", perhaps related to their long history of online collaboration.
• "Learning from Experience" gets its greatest attention from Aid/Development, Military/Emergency and Mining.
• In the middle of the plot, where all three areas get equal votes, are Utilities, Construction, and Education/Training.

You can see the outworkings of these preferences in all sorts of things, such as the ways KM job descriptions are written, the skills from which KM teams recruit, and the preferred components of the KM Frameworks. 

What's the conclusion? I think that this plot may be an interesting way to differentiate different KM approaches, but perhaps the main conclusion is that id you are looking at analogue Km approaches to learn from; stick to a neighbouring industry. There would be no point in an oil and gas company applying a KM framework from Legal, or Legal applying a KM framework from IT, or IT applying a Framework from Mining. 

Understand how your industry approaches KM, and use that as your starting point. 

A KM framework for frontline sales

Knowledge Management case studies are often from the manufacturing, projects, operations or service world. However Knowledge management can be applied to any business activity. In this reprise from the archives, we look at how it can apply to Sales.

Sales team meeting by  Jim Larrison on Flickr

The sales force often work as individuals,  grouped into teams covering specific regions and specific products or product ranges for their organisation.  They may be selling FMCGs (fast-moving consumer goods) such as clothing or pharmaceuticals to buyers in high street chains, they may be selling IT solutions to blue-chip businesses, or they may be selling cars to fleet buyers in major multinationals.

They work to sales targets, and are often highly motivated and incentivised to meet those targets. They spend a lot of their time with the buyers and customers, and relatively little time at “head office” with the rest of the team.

In this blog post, we explore some of the issues of KM for frontline sales staff (we exclude the practice of Knowledge Management for bid teams - that is far closer to the practice of KM in project-based activity).

Critical knowledge for sales

The sales force needs the following knowledge

• Knowledge of how to sell. They need the basic knowledge of the sales process, such as relationship building, negotiation, and closing. This can be taught in theory, but the knowledge is really only acquired through practice, for example through role-play and coaching, as well as on-the-job learning and "learning before doing". As one sales director told us, “we always do a lot of scenario planning. Before reviews I sit with my team and I plan what is the worst case that might happen, and how do we combat it? What is the most likely case, and how do we combat this?  What is the best case, and how do we maximize the outcome”?

• Knowledge of pricing. Sometimes the price of an item is flexible, with the potential for offers and promotions such as “buy one, get one free”. The sales force need to know the pricing strategy, the pricing options, and how to sell the benefits of the pricing approach to the buyer. This knowledge needs to be provided to the sales force by the experts in the sales organisation, who themselves rely on input from the sales force. Pricing strategies can usefully be shared between sales forces in different regions and different countries.

• Knowledge of product. The sales force need to know the details of the product, and to be rapidly briefed in any new products that may be developed. In the conversation with the buyer, the sales person has to be the product expert. This knowledge comes from the product development unit, and may also be informed by feedback from customers and consumers. One firm producing motor oil products delivers regular training to its sales and marketing departments to bring them up to speed in new products.

• Knowledge of the consumers and their behaviour. This includes knowledge of buying habits and how to influence them; through display, promotions, education and negotiation. The sales person selling to a retailer, for example, must be the recognised category expert and understand the category shopper better than the buyer, and better than the competing companies. “One thing that we offer is our understanding of the local consumer, and we need to use that knowledge to advise the retailer” said one sales manager. This knowledge can be used to sell the products and brands better, to build more shoppable displays, and to help to grow sales for the retailer, and thus for the sales force. The sales rep starts to act as a consultant to the retailer, offering a knowledge based service.

• Knowledge of the sales to that buyer. They need to know the sales data, the margins, and the trend. This knowledge will be delivered by the central sales organisation, based on studies and on aggregated sales data from across the firm. One sales manager told us “we have to know our data and information much better than the buyers do. They will use a set of information on how much they buy and sell from us, we need to know this data far better than they do”. If the buyer understands the data better than the seller, then the buyer is at an advantage.  This knowledge needs to cover the buyer’s competitors’ data as well, if possible. The sales rep selling to a retailer will probably have data for all of the retailer’s competitors, and although they cannot give away any specifics, they can talk about trends, and provide them insight in terms of what is going on across the overall marketplace. This knowledge is much appreciated by the buyer, and becomes an added service the sales force can offer.

• Knowledge of the buyers and the buying companies. The best sales work through mutual advantage, so that both the buyer and the seller benefit from the deal. Therefore the sales force need knowledge of the buyers (both individual and organisational) and their goals and objectives.  They seek to understand their big customers, their game-plan and drivers, and develop and define a customer profile which is shared with and understood by the entire sales force. Although much of this knowledge comes from the sales force themselves, it will again be aggregated by the central organisation. 

• Knowledge of the production capacity of the organisation. There is no point in selling something that can’t be delivered, so the sales force need to know what can be produced for and delivered to the client. Again, this knowledge needs to be delivered to the sales force, by knowledge transfer along the internal supply chain, and needs to be incorporated into sales targets

A KM Framework for sales

A Knowledge Management framework for a sales organisation, to allow transfer of these areas of knowledge, will probably contain some of the following elements (obviously tailored to the specific organisational context).

• Roles - these will include  a KM person or team providing KM support for the sales organisation; also owners of critical knowledge, such as practice owners for the key areas of sales practice, product owners who ensure product knowledge is up to date and accessible, and key account owners, who hold the knowledge of dealing with key accounts.

• Processes - Coaching and training (including role play and scenario planning). Regular knowledge exchanges and mini-peer assists during meetings of the regional team, and the wider sales community. Regular (e.g. quarterly) Retrospects for the sales team to generate lessons. Creation of knowledge assets on pricing, consumer behaviour, effective techniques, and dealing with buyers (especially major accounts). These knowledge assets will have been developed through interviews with key successful sales staff.

• Technology - Access to the sales community of practice while on the road, to share updates and ask questions. Access to customer-related and account-related data while on the road, and in the office, through a CRM application. Provision of knowledge of products, supported by a mobile-enabled knowledge base.  Access to past sales lessons. 

• Governance - tracking the frequency and effectiveness of sales KM, including the completeness and availability of knowledge assets, and the interaction within the Sales community. Monitoring the effectiveness of Knowledge Management in increasing sales.

Together these 4 elements form a KM framework for frontline sales staff.

Seven potential building blocks of a KM framework

Knowledge management is a large and complex field, covering many elements, and applied in many different ways (see my blog post on 50 shades of KM for example). However there are a small number of Knowledge Management sub-components or modules which come up time and time again, and probably represent the main building blocks for KM.

Lego #5 by Antonio on Flickr

These modules are applied in different ways in different organisations, and use different processes, technologies and roles. Each of them delivers a certain amount of value; combined, they can create a complete Knowledge Management framework. Any one of them might be favoured in any particular industry.

The seven main KM modules are listed below.

1. Connecting people, through Communities and Networks.

Connecting people through Communities of Practice and Networks is the most popular module within Knowledge Management, applied (according to our global KM surveys) in three quarters of KM programs; Legal KM programs being the main exception. This module requires an effective set of Community software, but more that this, it requires governance, leadership roles, and community processes (see the ten success factors for Communities of Practice).  Through connecting people in this way, knowledge can flow from person to person, across silos and organisational boundaries.  Questions can be asked and answered, and individuals can collaborate on solutions.

2. Learning from Experience.

About two-thirds of KM approaches include some form of learning from experience, or lesson-learning (again, Legal KM programs often proving an exception).  Learning from experience can be applied at many levels; to teams, to projects, to products or to programs. It may involve After Action Reviews, Design improvements, Toyota A3s, Retrospects, and other techniques. But however it is applied, and however it is supported by technology and roles, the same principles of systematic gathering and re-use of new knowledge are needed if learning from experience is to be successful.

3. Creation of "Best Practices".

The third most common KM module is the creation of some form of compiled and documented knowledge base. Whether you call it "Best Practices" or not, 60% of KM approaches address this issue of "gathering and synthesising what we know". The home for this synthesised knowledge may be a Wiki, a Knowledge Asset, a Checklist, or even an Expert System. I am not talking about libraries here - the key to a Best Practice approach is developing and making available the Current Best Way to do something, and then continuously improving that "Best way" to make it even better.

4. Provision of Knowledge to external Customers

This is a version of number 3, which focuses on providing knowledge to external parties. This can be done through Knowledge Centred Support (customer support staff working with the help of a knowledge base), through chatbots, or through customer self-service (publishing knowledge on a site for customer use). 

5. Better access to knowledge documents.

"Better access to knowledge documents" is a very common area of focus of Knowledge Management programs, although this verges into the adjacent fields of ECM and information management. Portals and Enterprise Search (even Semantic Search) are the key tools here for ensuring findability of documented knowledge.

6. Knowledge Retention.

Knowledge retention is a strategic approach to protecting against knowledge loss as experienced staff leave an organisation, and a whole variety of KM interventions can be applied to both retain and transfer the knowledge.

7. Innovation.

Innovation as a separate KM module deals with Knowledge Creation, often through development of innovation teams, creation of breakthrough innovation projects, and use of structured innovation processes.

Business sectors and the seven building blocks

As already hinted above, different business sectors tend to have a focus on different KM modules. Some of the main differences are as follows (and please bear in mind that most organisations address the first 4 modules, and many address all seven to varying extents).

• Connecting People is a core focus for multinational organisations, where knowledge is spread over many sites and many countries. Aid and Development organisations, for example, focus on Connecting People, as do the multinational oil companies.
• Learning from Experience is a core focus for Project organizations, such as Construction, Engineering and Aerospace.
• Best Practice is a core focus for service organisations, and for Manufacturing.
• Provision of knowledge to customers is a focus for Finance, Insurance, Retail and Educational organisations, as well as the development banks.
• Better access to knowledge documents is the core focus in the Legal sector, but is part of the KM Framework for almost every organisation.
• Knowledge Retention is a core area of focus for many organisations; typically Western Engineering and manufacturing companies concerned about reliability (Nuclear, Aerospace, Utilities etc) or growing organisations relying on the knowledge of a few experts. 
• Innovation is a focus for any competitive organisation, be it product innovation or process innovation, but is seldom the core focus for a KM program. 

However whichever building blocks you choose, the key is to link them up into your final framework, as no block stands alone.

How projects and organisations work together to make a KM system

Projects and the wider organisation are linked in a Knowledge-handling cycle

Please note, in this article you can replace the word "project" with "department" or "division" or "team" or "office" throughout.

The Boston Square here is one that I have used with projects as part of their Knowledge Management planning, and is a useful framework to allow projects to reflect about the knowledge sharing they need to do.

The thinking is as follows.

• The project knows some things
• The wider organisation (the centre, the functional departments and other projects) knows some things as well.
• At the start of the project, they need to learn as much from the wider organisation as they can. If there are important things the organisation knows but the project doesn't, the project needs to learn these things.
• At the end of the project, if the project has learned things the rest of the organisation does not know, then the project needs to share this knowledge.
• At all other times, the project and the organisation should be in synch - in the green boxes in the diagram.
• If there is any knowledge held in the red boxes, meaning that the organisation doesn't learn what the project knows, or the project doesn't learn what the organisation knows, then this is evidence of organisational silos, and of the lack of knowledge sharing. 

The projects therefore import knowledge from the organisation at the start, and export new knowledge at the end. They are the users and the creators of knowledge. In many ways the rest of the organisation exists as a knowledge-handling mechanism to service the projects with knowledge. 

Knowledge circulates through the interactions between the projects and the organisation, as shown below, and grows, deepens, evolves and develops as it does so.

 

The projects and the organisations are like two chambers of a beating heart, responsible for the circulatory flow of Knowledge