How to measure the pull-based knowledge cycle

Last month I described a "Pull cycle" for knowledge - let's now look at the the measures we can introduce to that cycle.

You can find a description of the cycle here. This is a cycle based on knowledge demand (unlike the supply-side cycles you normally see) and includes the following steps;

• The cycle starts with a problem, and the identification of the need for knowledge to solve the problem (the "need to know")
• The first step is to seek for that knowledge - to search online, and to ask others
• Seeking/asking is followed by finding
• However generally we tend to "over-find". Unless we are lucky, or there is a very good KM system, we find more than we need, so the next step is to review the results and select those which seem most relevant in the context of the problem.
• This found knowledge then needs to be integrated into what is already known about the problem, and integrated into solutions, approaches, procedures and plans.
• Finally the integrated knowledge needs to be applied to the problem.

Some of the people who responded to this post on linked-in pointed out that the cycle could break at certain points.  In the picture above, I have added the monitoring and feedback loops to each step, and acknowledged that each step could succeed or fail.  The metrics would work like this:

• Once a problem has been identified, you can measure whether there was any asking/seeking that happened. You would need to interview people in the business to do this, unless there was a process of KM planning in the organisation, in which case you could interrogate the KM plans.  You can also monitor the topics that people are asking about or searching for. You can for example analyse questions in a community of practice, or queries to a helpdesk, or you can analyse search terms from the corporate search engine logs. These will give you some ideas of what people are looking for, which you can equate with the knowledge needs within the organisation, which knowledge supply has to match. 

• After the question has been asked you can measure whether people found the knowledge they needed, or not. This is easy to do with questions to a CoP; unanswered questions in a CoP forum are pretty obvious (you still have to check whether the question was answered offline or by direct message), and may identify knowledge gaps in the organisation. It is not so easy to measure the success of searches of a knowledge base. However if you do it, you can identify gaps in the knowledge base where the knowledge needs are not being met, and this can trigger the creation of new knowledge assets of articles.

• After knowledge has been found you can ask for feedback on whether the knowledge was relevant or not. In reality this feedback will often be merged with the previous step. You can also ask for feedback on the quality of the knowledge you found. In the context of a knowledge base, this feedback will identify knowledge assets or knowledge articles which need to be updated or improved. In the context of a CoP, this can also help identify areas where existing knowledge is not enough. 

• After good and relevant knowledge has been found, you can look for feedback whether the knowledge was actually applied. This will help identify the most applicable and useful knowledge assets and articles in a knowledge base, and in a CoP will help demonstrate that knowledge shared in the CoP is of real value. The CoP moderator or facilitator can try and nudge members who ask questions, to feed back to the community whether the answers have been applied.

• Finally, you can look for feedback on how much difference the knowledge has made, and how much value was realised through problem solution. This allows you to track the value of the entire pull cycle and the entire knowledge management framework. Looking for this feedback will be hard work for someone in the KM team, and you will receive a lot of push-back from the organisation, but there are many examples where organisations have demonstrated measurable value from shared knowledge (see my collection of value stories), and often you can reduce this to discrete examples of shared knowledge (see here, here and here for example), or the value of a specific collection (see Accenture example, and Domestic and general). Just because its hard to get a value figure, doesn't mean you shouldn't try.

Many of these monitoring and feedback loops are well developed in the customer-focused KM approaches such as KCS (Knowledge Centred Support), but any KM approach can apply these as part of their own KM metrics framework.

It is through the feedback and metrics associated with the steps that you can tell whether KM is actually working, and if not, where the cycle is broken.

The value of jargon in KM - 50 words for snow.

To be able to transfer subtleties of knowledge, we need subtleties of language. That's where jargon comes from.

The Inuit languages have, it is claimed, 50 words for snow (falling or lying snow, and ice).  

This may or may not be true, but their various words can carry a huge amount of subtly detailed knowledge, and this detail is vitally important for a people that live, travel and hunt on snow.

For example there is a word "Nuyileq", meaning "crushed ice beginning to spread out; dangerous to walk on. The ice is dissolving, but still has not dispersed in water, although it is vulnerable for one to fall through and to sink. Sometimes seals can even surface on this ice because the water is starting to appear." (source here). This is a crucial distinction if you intend to  travel on this ice.

A community of Inuit hunters would make use of this wide vocabulary for transferring knowledge of hunting conditions. "Watch out for the coast round Uummannaq; there's a lot of Nuyileq about". This is jargon - "the specialized terminology associated with a particular field or area of activity" - and jargon makes it possible to exchange specialised knowledge within a community of practice with speed and efficiency. 

Those of us who live in temperate and tropical cities don't need this level of jargon.  Snow is an unusual feature for us, and we basically only have two or three words for it; snow, slush, and "the wrong sort of snow" (the stuff that shuts down the rail network).  To have 50 words for snow seems quite amazing, even though we have 100 words for rain. 

Winter mountain climbers on the other hand, who rely on snow and ice for the safe ascent of mountains, have developed a more nuanced jargon within their community.

• "Neve" - that tough snow that securely holds the pick of your ice-axe
• "Rime" - the coating of frost and snow over rock which you can brush off using a glove
• "Spindrift" - fine falling snow swirling in the air, not enough for an avalanche, but enough to get down your neck and soak your shirt
• "Cornice" - the awkward overhang of snow at the top of your climb which you must circumvent, or tunnel through.
• "Verglas"  - a thin coating of ice that forms over rocks when rainfall or melting snow freezes on rock. Hard to climb on as there is insufficient depth for your crampons to have reliable penetration.
• "Windslab" - treacherous and avalanche prone.

Words convey nuance, and the more important a context is to you, the more nuance you need and the more words you use. You can call this jargon, but really it is nuanced communication which allows efficient and effective knowledge sharing.

A community of practice is a collection of people united by a common jargon. 

A community of geologists has its own jargon, as does a community of electrical engineers, a community of software architects, or a community of primary school teachers. These jargons allow efficient nuanced knowledge sharing, but can also be a barrier to the newbie and the uninitiated.  The jargon test is often a good text for communities of practice; if they don't have a jargon of practice, are they really a community of practice?

When communities need to communicate with other communities, then jargon is also a barrier, and some translation is needed. For example when General Motors began to develop their library of design best practices, one of the first tasks was to develop a common nomenclature for car parts between the design teams, the manufacturing teams, and the sales and service teams.

And when communities from two different organisations are brought together, for example after a merger, there needs to be a deliberate time of jargon-alignment.

Jargon is important, and is the domain of the community. What looks like unnecessary distinction from the outside (50 words for snow, 100 phrases for rain) is the way community members share knowledge. 

How to break the 4 generic barriers to Knowledge Management.

There are only four generic barriers to KM. These are they, and all can be addressed.

The Boston Square shown here maps the unwillingness and the inability that can affect  the knowledge supplier, and the knowledge user. Any combination of these is a block to the transfer of knowledge from one to the other. 

The Supplier is unwilling to share.

The unwilling supplier is afflicted by Knowledge Hoarding. He or she feels they will lose something (power, job security, reputation) if they give their knowledge away. Luckily we can demonstrate that this is not true, and managers can ease the shift from hoarding to sharing by careful use of incentives, eventually outlawing hoarding entirely.

The User is Unwilling to learn.

The unwilling user is afflicted by Not Invented Here (NIH). He or she feels more secure in their own ("invented here") knowledge than in scary knowledge from somewhere else. This barrier can be addressed by redefining "here", so that "invented in my community" equates to "invented here", by using performance metrics to shock people out of complacency, and eventually by outlawing NIH completely.

The Supplier is Unable to share

The unable supplier suffers from the Stranger problem - "I don't know who to share this with". This can be tackled through developing a Pull-based approach, so that they share by answering  the questions of an individual or team (through community forums, or peer assist), or by using the concept of the "Unknown User" - the psychological construct that we can bring into retrospects and after action reviews.

The User is Unable to find knowledge

The unable user suffers from "needle in a haystack" - they don't know where to look. Here we need the knowledge assets, that synthesised knowledge that creates the faucet rather than the firehose. We need the expertise locator. We need good search, and we need the places to ask - the community forums described above.

All four of these barriers are very real. All four can be overcome.  The Ability to share and learn is provided by the creation and roll-out of a Knowledge management framework, while the Willingness to share and learn is provided by culture change and communication activities, and cemented by KM governance. 

The Battle of the Hedgerows - an example of rapidly-evolving bottom-up knowledge

The story of the "Battle of the Bocage" is a great example of evolving knowledge, driven from the bottom up.

Normandy Bocage
Image from
wikimedia commons

I am reprising this post from the archive, not just because its a great story, but because in demonstrates the maturing of knowledge through several stages, as described in this post from 2 weeks ago.  Thanks to Jack Whalen for first pointing me at this excellent Learning Story from WW2 and the D Day landings. 

What has been quoted as being "one of the greatest intelligence failures of all time", was the failure of the US forces to realise the nature of the battle they would fight after the D day landings - a battle in a maze of small fields, sunken lanes and almost impenetrable hedgerows, known as the Bocage.

For many of us brought up in rural Europe, where small fields and ancient hedgerows are a familiar site, we might have realised that this sort of landscape would be an obstacle. Yet for the US forces in early June 1944, the nature of the landscape was a huge surprise.  Hedgerows cultivated for over a thousand years to keep even the strongest bull in a small field, are not a feature of the American countryside. They are impenetrable to troops, and the earth banks under the hedgerow make them a death trap for tanks, as the unarmoured base of the tank is exposed as it climbs over. 

As one U.S. Army Captain put it, “We had been neither informed of them or trained to overcome them”. General Bradley called the Bocage the "damndest country I've seen."

Actually there had been warning of the hedgerows - see this quote from Brigadier General James M. Gavin- "Although there had been some talk in the U.K. before D-Day about the hedgerows, none of us had really appreciated how difficult they would turn out to be."  This is a classic failure of Learning Before - failure to share a context. The British would have known about the challenge of the hedgerows, as similar countryside is found in Devon, Dorset and south Somerset. They would probably have assumed that Americans knew about the challenge as well (this assumption is known as the Curse of Knowledge). The conversation might have gone

• Brit "Watch out for the hedgerows"
• American "Yeah no problem"

Whereas the conversations needed to have been

• Brit, "No, I mean REALLY watch out for the hedgerows"
• American "How do you mean? What's the problem with a hedgerow? Its just a few bushes, right?"
• Brit, "Let me explain ....."

The Germans knew all about hedgerow warfare, and had been practicing tactics for months - tactics of covering fire, pre-aimed mortars, communication lines between fields, covering fire from parallel hedgerows, turning each field into a deathtrap. They knew that they were perfectly hidden behind the dense hedges. The Germans had a knowledge advantage; they had knowledge of "how to fight effectively in the Bocage", which the American troops did not have. 

As a result, the first few weeks were a nightmare for the American troops, losing on average one man for every metre of progress. Imagine marching down the road shown in the picture above, with the potential machine-guns behind every hedge.

However, despite this failure to "learn before", some very smart "learning during" went on to fill the knowledge gap. The Americans improvised and innovated in the early stages of knowledge development, with successful innovations including;

• The Rhino Tank invented by Sergeant Culin - a tank-bulldozer combination, where recycled beach defences were welded to a tank, enabling it to burst through a hedgerow;
• A communication system, where an infantry observer could shelter under or behind a tank and direct its fire, linked by telephone to the tank crew;
• Use of light rifles for covering fire, instead of more unwieldy machine guns;
• A whole language of hand signals for communicating between tanks;
• Using the back of a tank as a platform for the mortar spotter;
• Employing light aircraft to scout in advance.

The book "Busting the Bocage" summarises the learning approach (my emphasis in bold)

Ideas on how to achieve better results against the Germans came from a wide variety of sources. In general, ideas flowed upward from the men actually engaged in battle and were then either approved or rejected by higher commanders. Within the bottom ranks of the Army, individual soldiers suggested ways that enabled their units to move against the enemy. Sergeant Culin's hedgerow cutter is the best example of a single soldier's idea that influenced all of First Army. At the top end of the chain of command, general officers also produced ideas on how to defeat the Germans. General Cota's supervision of the development of hedgerow tactics in the 29th Division typifies the contributions made by general officers. 

The effort to gather ideas on how to beat the Germans was decentralized. There was almost no effort to work out an Armywide solution to the tactical problems of combat in the Bocage. The First Army staff made no distinct attempt to devise tactical solutions for. the whole command to use in overcoming the German defenses. First Army did publish and distribute to all units a series of "Battle Experiences," reports that contained information and lessons learned in battle. The bulletins were not directive in nature, but subordinate commanders were expected to use the information to assist them in finding ways to defeat the Germans. In fact, in only one area did First Army headquarters take an active role in dealing with tactical problems: the production and distribution of Sergeant Culin's hedgerow cutter.

What explains the decentralized, collective method of tactical problem solving exhibited within First Army? Firstly, the U.S. Army was not in a position to analyze the German defense systematically and produce one best solution for attacking through the hedgerows. First Army simply did not have the time to slow the pace of combat operations while seeking a uniform, coordinated solution to tactical problems. The U.S. Army had to push inland and expand its beachhead as a prelude to larger operations. Corps and division commanders received orders and were expected to execute them as quickly as possible while overcoming all difficulties. Commanders who did not perform well were relieved; several division commanders lost their posts during the Normandy campaign.

Once the knowledge of tactics had been created, it was rapidly spread among the various divisions through use of the bulletins. Individual divisions created their own variants of these approaches, which were shared as Example Practices.

Within a few weeks a standard practice was developed; a doctrine, or series of approaches, for clearing a field, involving the close operation of a tank and an infantry squad ("'One Squad, one tank, one field'"). This close operation of armour and infantry at this level of detail (single squad, single tank) was itself an innovation. 

  
As quoted here

"After the rehearsal on 24 June, the 29th Division's operations staff prepared diagrams and explanatory notes outlining the new hedgerow tactics in detail. The operations section then distributed the information as a training memorandum to all regiments within the division. Units in the 29th Division practiced and rehearsed the new tactics in preparation for their next bout with the Germans.  On 1 July, General Cota summed up the 29th Division's tactical experience in France: "What held us up at first was that we originally were organized to assault the beach, suffered a lot of casualties among key men, then hit another kind of warfare for which we were not organized. We had to assemble replacements and reorganize. Now we have had time to reorganize and give this warfare some thought. I think we will go next time"

Using the new knowledge, and with Rhin Tanks being manufactured in advance, the 2nd Battalion made spectacular progress. They completely ruptured the main line of German resistance.  Infantry casualties were relatively light during the attack, and not one tank was lost. Other US Army units delivered equally impressive advances.

Thus newly developed knowledge turned the tide of the battle.

This is an interesting story, and an interesting example of Learning in Action, when speed of deployment was more important than consistency. It is also an example of the development of knowledge, starting with the recognition of a knowledge gap, the bottom-up development within the community of practice of good practices, and the eventual development and application of a standard practice. 

Of course, were the context to change, the knowledge would need to go through a new cycle of development. Who knows how the tactics would change with the introduction of drones, satellite imaging etc. However within one month in 1944, the US Army was able to create, develop and deploy knowledge of a critical topic - "How to effectively fight your way through the Bocage".

How to deal with the shrinking half-life of knowledge

Knowledge has a half-life, and that half-life is getting shorter every year.

When John Browne was CEO at BP, he talked about "the shrinking half-life of ideas". This always struck me as a very interesting concept; one which was fundamental to Browne's approach to corporate KM. I have since found that he was quoting an older idea from 1962 concerning the shrinking half-life of Knowledge, which has now been popularised and explored by Sam Arbesman (see video) among others.

The idea of a half-life comes from nuclear physics, and originally applied to the decay of radioactive nuclei. This quote (now no longer online) from the people behind the popular QI program tells us

"What we think we know changes over time. Things once accepted as true are shown to be plain wrong. .... But what's really interesting is that studies of the frequency of citations of scientific papers show they become obsolete at a predictable rate.  

Just as with radioactive decay, you can’t tell when any one 'fact' will reach its expiry date, but you can predict how long it will take for half the facts in any discipline to do so. In medicine, for example, 'truth' seems to have a 45-year half-life. Some medical schools teach students that, within a few years, half of what they’ve been taught will be wrong – they just don’t know which half. In mathematics, the rate of decay is much slower: very few accepted mathematical proofs get disproved

Not all knowledge has a short half-life - sometimes the knowledge is linked to the technology, and if you are running a nuclear power station using 1960s control software, then the half-life of the knowledge of the software has to exceed the life of the power station. However in most other areas, where knowledge is evolving and changing, and your competitive advantage lies (at least partly) in having the best and most valid knowledge, then hanging on to old knowledge which is past it's half-life can be competitively dangerous. And the faster the speed of change, the shorter the half-life of knowledge and the greater the danger of using obsolete knowledge.

The implication for KM

Where knowledge has a short half-life, Knowledge Management is not so much about documenting and protecting "what you know", it is about how fast you can know something new, and how easily you can let go of the old. That's what will win you the battle with the competition. Colonel Ed Guthrie of the US Army used to liken this constant learning to the aerial dogfights in world war 1. "In those days" he used to say, "It was about getting inside the other guy's turning circle. That's what would win you the engagement. Now it's about getting inside the other guy's learning circle".

This implies that any knowledge which has been documented must constantly be re-examined in the light of new lessons and new experiences, and obsolete knowledge must be constantly updated or archived. New knowledge must be rapidly disseminated to replace old knowledge, just as updates to pilots checklists are rapidly disseminated. 

A knowledge base full of old documents runs the risk of containing old "facts" which are no longer true. This is why some organisations require subject matter experts to continually update practice collections, and why others use constantly-updated wikis to store knowledge, especially where knowledge is changing rapidly and has a relatively brief half-life. So beware if your strategy is to use search and AI to interrogated the documented knowledge in your organisation, as this often lags behind the evolving state of knowledge. 

Be aware of the shrinking half-life of knowledge, and be prepared for constant knowledge update if the half-life is short.

How the best KM approach changes as a knowledge topic matures

The way you manage knowledge that is very new and highly dynamic, is not the way you manage mature and static knowledge topics. 

Any single knowledge topiccpasses through a series of stages as it matures, as shown and described below, and you can argue that the task of Knowledge Management in each stage is to develop and improve the knowledge and to move as effectively as possible to the next stage. As the knowledge domain matures, so the management approach for that knowledge evolves.

The stages are shown in the plot below. The plot has two axes:

• The maturity of the knowledge topic, defined as the rate at which that knowledge evolves and changes; and
• The number of knowledge users. 

These two are generally linked. Older, more mature knowledge has more users. Brand new knowledge many be known to, and used by, only a few. Therefore a knowledge topic often takes a trajectory or journey through this space. We can recognise 6 stages in this maturity journey, illustrated below in the context of an organisation developing new products (other contexts are available).

Stage 0. Innovation, or Knowledge Creation.

This step is where ideas are made. Knowledge Management helps innovation by creating proactive processes for generating new ideas in the areas of greatest business need, often incorporating networked innovation (Deep Dive, for example,). There are relatively few people working on this knowledge, which may be held only within a single innovation teams. The knowledge is provisional - it may not have been tested yet.

Stage 1. Research

Research is Idea Testing - moving from an Idea to Knowledge through practical experimentation. Knowledge Management helps here by introducing roles, processes, technologies and governance for capturing that first knowledge, as well as by capturing what did NOT work (and why), and also the most promising research leads that there was no time to explore. The knowledge evolves rapidly, through the use of  techniques such as Action Learning, supported by blogs and wikis (see this example). There may be relatively little written about the knowledge at this stage; and as it is still developing rapidly, a wiki is a better solution that writing documents which will become outdated very rapidly.  Once the main theoretical problems are solved, the knowledge needs to be passed to the Development team, and also retained for future Research programs. 

Stage 2. Knowledge Development

The development stage involves taking the best research ideas and testing them further to develop a viable process or product which can be rolled out in the business, or delivered to a customer. Knowledge Management helps here by introducing a framework for learning during development, both to make the development process more effective and efficient, and to ensure the "knowledge workstream" is well managed (i.e. the creation of knowledge for the benefit of the users further along the value chain).  The techniques of After Action review, Retrospect, and Knowledge Asset development are important here. Once the main practical problems are solved, the knowledge is passed to a wider user base in sales, manufacturing or operations. There needs to be more focus on documentation, although all user documentation is provisional until the knowledge has been thoroughly tested in the user market.

Stage 3. Establishment of Best Practice

Even when the process or product is in use, the knowledge can be further perfected. The organisation can still improve the process or product, and can learn to improve its application. Because the product or process is now in use in many locations, Knowledge Management helps by introducing a framework of knowledge sharing and re-use, so that people all over the organisation can learn together, and all refinements of the knowledge can be collated and synthesised. The techniques of Communities of Practice, Lesson-Learning and development of Knowledge Bases become important, ensuring that these knowledge bases are dynamic enough to allow regular update. 

Stage 4. Standardisation

Once the knowledge has been perfected through use, the next step is to standardise the knowledge, as further experimentation would now be wasteful "reinvention of the wheel".  The knowledge becomes codified in manuals, reference materials and training. Knowledge Management helps now by ensuring these "knowledge assets" are well constructed and easy to find. This is an area where AI may help, and agents like ChatGPT, which develop answers based on a large and stable written body of knowledge, may become powerful tools for stage 4 if the user base is large enough to warrant the cost.

Stage 5. Reinvention.

However no knowledge lives for ever. There are often cycles of reinvention, where old knowledge is replaced by new ideas, and the cycle begins again with Innovation. Knowledge Management should promote constant challenge of the status quo, to test whether there could be a better way to do things, and to decide whether the maturity cycle needs to be restarted.

The need to accelerate this maturation journey

Business in a world of change is a learning race. The winner is the organisation that can develop and mature knowledge more quickly than the competition, bringing new and improved products and processes into the market first, and so gaining First Learner Advantage.

Therefore one way of viewing Knowledge Management is to see it as a strategic approach to maturing critical and competitive knowledge domains in the most rapid and effective way. 

The most successful organisations will be those who can run this maturity cycle at optimum speed, and so out-learn their competitors.  

Why don't we use THIS cycle as a Knowledge Management model?

We are used to seeing pictures of knowledge cycles, but there is one cycle you never see, and it's very important.

You can find very many versions of the knowledge cycle, and they all seem to work the same way.

They start with "Create" or "Capture", and progress through "Store", "Share" etc until they get to "Use" or "Apply. Some have as few as 3 steps, some have 8 or more steps, and the 4-step basic has even made it into the Stock Photo collections. However all these cycles work in the same way, as all of them are "Push" cycles.

By "Push Cycle" I mean a cycle that is driven by knowledge supply, and describes how that supply of knowledge works through various stages until the knowledge is used again. It is a supply chain model, and people use the cycle to put in place roles and processes to move knowledge along the steps in the supply chain. 

I blogged last month about the problems with the Push cycle, one of which is as follows:

Supply is only half the story, and you need to look at Demand as well.

The diagram shown here is a cycle driven by knowledge demand - a "Pull cycle" - and it works like this.

• The cycle starts with a problem, and the identification of the need for knowledge to solve the problem (the "need to know")

• The first step is to seek for that knowledge - to search online, and to ask others

• Seeking/asking is (if the KM framework is operating well) followed by finding

• However generally we tend to "over-find". Unless we are lucky, or there is a very good KM system, we find more than we need, so the next step is to review the results and select those which seem most relevant in the context of the problem.

• This found knowledge then needs to be integrated into what is already known about the problem, and integrated into solutions, approaches, procedures and plans.

• Finally the integrated knowledge needs to be applied to the problem.

So why do we never see this Pull cycle in diagram form?

• Is it because Pull (Demand) is less important than Push (supply)? Surely not! Most people would see them as equally important, and there is an argument that Pull is in fact a bigger driver of knowledge transfer than Pull. 

• Is it because the Pull cycle is less useful than the Push model?  Surely not! If we can generate knowledge pull, and a demand for knowledge, we can spark knowledge supply. 

• Is it because the Pull cycle is more difficult to work with than the Push cycle? Maybe this is one reason. Asking is less of a natural behaviour and more of a cultural barrier than sharing, so sharing may be the easier option. But ignoring barriers wont help you in the long run.

• Is it because the Pull cycle is less measurable? The Push cycle is often linked with the creation of documents, and this is something that can be measured. Leaving aside the question about whether anyone is looking for these documents, and whether these documents are useful when found, it is easier to measure the first couple of steps in a Push cycle than it is to measure similar steps in a Pull cycle. However you can also measure searches, and measure questions in a community forum.

• Is it because people only want one diagram? Yes, probably, but we know that KM cannot be reduced to a single and simple diagram; it is far too nuanced for that.

• Is it because everyone else draws their cycles this way? Probably yes. But just because everyone else does it, doesn't make it correct or sufficient.

There are many places where this Pull cycle can be applied very well.

• Each individual uses this cycle when searching for knowledge. Most of the steps are done in the individuals head, but it may be useful to talk them through with a manager or colleague.

• You can apply the cycle within a Peer Assist meeting, and the format of the meeting can follow the entire cycle from asking the questions, to reviewing the answers, to integrating them into the forward workplan.

• You can apply it within a Community of Practice forum. Someone asking a question on the forum could  be asked to give feedback on the answers they received, the knowledge they selected from these answers, how they integrated this knowledge into their plans and (ideally) how it helped solve the problem. 

• You can apply it as part of KM planning. A project team can identify their knowledge needs, conduct a search/ask activity, then get together to discuss how they will select and integrate the knowledge they have found. 

Being more conscious and explicit about the Pull cycle gives you more ways to create and stimulate knowledge demand in your organisation, and helps drive a Knowledge Seeking culture. 

Please do not focus only on the Push cycle for KM - its only half the story. Make sure your KM Framework incorporates the Pull cycle as well.