When Peer Assists add value

Peer Assists are one of the most powerful processes in KM, but they are not for every occasion.

A  Peer Assist - a meeting when a project team seeks input of knowledge and advice from experienced peers - is one of the most effective tools in the KM armoury. It is demand-driven, the knowledge which is shared will almost certainly be reapplied very quickly, the knowledge is brought into the project in its richest form (in the heads of experienced practitioners) and the diversity of viewpoints within a peer assist helps eliminate many of the common cognitive biases.

However a Peer Assist is costly in time and (in the case of multinational companies) in travel costs. It is not something that can be done quickly, as it takes time for the visiting peers and the project team to fully understand each others' contexts. A Peer Assist for a major project may take days.

The value of the Peer Assist must outweigh the costs, which is why they are not a cure-all for every problem.

Here are some guidelines for whether a Peer Assist is the right solution for a project

• The project recognises that it needs knowledge
• The required knowledge is complex knowledge, which has not been codified into standards and best practices.
• The Project team has tried traditional knowledge seeking methods such as searching, browsing, eLearning, formal training, expert support etc.
• The scope of work, and the issues which need to be discussed, are clear.
• The project team have enough knowledge of the subject to understand the core issues, but still need expertise and experience from other people to help them make the correct decision.
• The project team are still open to new ideas and challenges, and are not yet committed to a course of action
• The potential saving exceeds the cost of the meeting.
• Therefore they need a Peer Assist

How to hold an effective Peer Assist

Peer Assist is one of the most effective KM processes, when applied well. But what is the key to a good Peer Assist?

Peer Assist in China

Peer Assist is one of the most popular, simplest and most effective of the KM processes, the closest we have in KM to a Killer Application.  In our 2014 KM survey, Peer Assist was judged to be the most popular and most effective of the KM processes.

Here are some tips for getting the most out of Peer Assist.

• Run a team planning process to determine which topics require a peer assist. Try Knowledge Gap Analysis, or KM Planning
• Research and network to determine if a possible solution to your challenge already exists, before calling for a Peer Assist. A Peer Assist is too valuable to waste on solving questions where the answer is already obvious
• Plan the Peer Assist once you are clear on the questions to be addressed, but early enough to incorporate the feedback. You must have an open mind for a peer assist to add value.
• Be very clear about the objectives. Fuzzy objectives is a common form of failure for peer assists.
• Spend time on getting the questions right - neither too general nor too detailed.
• Don’t invite only the “usual suspects”! Look for diversity and relevant experience
• Appoint a facilitator. Although a peer assist is simple, a facilitator can add massive value.
• Include time for socialising to build relationships and promote knowledge sharing.
• Set the atmosphere to ensure frank and open exchange.
• Allow the host team to describe their context and identify their issues.
• Allow the visitors also to list issues which the host project team may have overlooked.
• Run a quality dialogue session around each of the issues in term
• Finish the Peer Assist with feed back from the visitors summarising their advice, and feedback from the host team summarising their actions.

How to avoid "intellectual inbreeding" through knowledge management

Someone came up with a great phrase in a workshop recently - "Intellectual Inbreeding"

Groupthink by Oscar Berg on Flickr

What they meant by Intellectual Inbreeding is the sort of restricted group think you get when ideas or practices have been the province of a small group of people, and they have become stuck in a set of shared views and opinions which are impervious to (or oblivious of) external views.

On this blog I have often referred to this as "knowledge bubbles" (see the Brexit example, the Hitler/Stalin example, the social media echo chamber,  and how to burst the knowledge bubbles, perhaps through a lesson escalation route).

Intellectual Inbreeding is what happens when the pool of ideas is too limited, and people can't think outside the box, to bring in new ideas and topics. Intellectual inbreeding results in a restricted "meme pool", and can lead to catastrophic error.  I recommend Christopher Burns' excellent book "Deadly Decisions - how false knowledge sank the titanic, blew up the shuttle and led America into war" for some scary examples

On a smaller scale, we see this intellectual inbreeding very clearly in our famous and powerful Bird Island Knowledge Management exercise, where groups can get stuck on a particular design, and can't see the wider possibilities. Maybe they have built a design that reaches 60cm, and think that if they really push everything to the limits, they might reach 75cm, little knowing that the best practice design is far far taller.

The way to beat Intellectual Inbreeding is to bring in ideas from elsewhere, from outside the meme pool. You can do this through peer assist, for example, or through knowledge learning visits. In the Bird Island game, we open the doors and bring in people from other teams to share their knowledge and ideas. Often, while the team was racking their brains to take their design up to 75 cm, a member from another team might come in having built a design that already reaches 120 cm.

What happens then, is dramatic. You can almost see the scales falling from people's eyes, and you can almost hear the sound of the penny dropping, or the bubble bursting.

Intellectual Inbreeding is one of the most dangerous outcome of siloed organisations. Use techniques such as Peer Assist to break the silos, exchange the ideas and experiences, and expand the meme pool. A healthy meme pool leads to a healthy knowledge ecosystem.

The closest thing to a KM Silver bullet

There is no silver bullet for KM, but there is one process that comes close - the Peer Assist.

Image from wikimedia commons

We often hear about a “Killer App” for KM, whether it is SharePoint, Yammer, or some impressive new software tool. And at the same time, we hear that KM has no "silver bullet".

However there IS a killerish application, a bullet of somewhat silvery hue, that is proven in practice and delivers results every time, if applied wisely. In some cases – multi-million dollar results. In fact, as I started compiling my collection of value delivery stories through KM, I found that many success stories related to this one application. And it is not a software application at all. It is an application of minds.

It’s the Peer Assist.

Peer Assist is the simplest thing possible in KM. It is a process for bringing knowledge into a project, or piece of work, at the outset. It is a meeting, where a project team invite a number of people with relevant knowledge and experience, which they bring to bear on the issues of the project. They apply out-of-team knowledge to the team's context. The team take this knowledge away, and apply it to improve their project planning and delivery.

So what makes Peer Assist such a powerful tool in Knowledge Management?

1. It is as way of dressing up, or legitimizing, the practice of asking for help. People don’t like to say “I need help”; they don’t mind saying “Lets hold a peer assist”
2. It is focused on learning, or Pull of knowledge
3. It is focused on Doing, or application of knowledge (thus bridging the Knowing/Doing gap).
4. It brings knowledge to the point of need, at the time of need, when receptivity is greatest and the chance of that knowledge being reused is highest
5. It brings knowledge in its richest form – in the heads of people with experience
6. If structured and facilitated well, it transfers knowledge in the most effective way – through dialogue
7. It is the easiest most natural process in the world (assuming you involve the right people, at the right time, with the right structure)
8. Learning is two-way. Both the assisters and the assisted come away with new knowledge
9. Again, if facilitated well and held face-to-face, it builds strong trust which eliminates “not invented here”
10. The trust and relationships formed at the assist can form the core of a future community
11. It creates reciprocity. If you are helped, you will help others.
12. The results are often easily measurable, in a short time
13. You can implement Peer Assist as a stand-alone process (though it works best as part of a KM framework)
14. It results in an action list, which results in action

Let’s look at an example.

An oil company was looking for innovative ways to cut the cost of the construction of gas stations world-wide, in order for them to meet their financial targets. They had set a target of 20% cost reduction, which was a big challenge. They held a Peer Assist in the early stages of the project, and invited peers from around the organization, including other divisions of the company, to share knowledge and experience. One of the invitees came from the part of the company where they build oil rigs, and he explained the concept of Alliancing – of working in an alliance with the constructor, with strong performance targets and equitable sharing of risk and value. Although some at the peer assist were skeptical, they took the action to explore Alliancing as one of the options for the project. In fact, this turned out to be the best option, and an Alliance was started with a building contractor which was hugely successful, and ended up cutting the cost of construction in half. A 50% reduction. And without the peer assist, this would not have happened, as there was no other way of ensuring that knowledge of the alliancing possibility could reach the people who needed to know it, at the time when they needed it and they were open to learning about it, in a form where they could discuss it and understand the potential, and then take action.

So are you serious about knowledge management? Do you want a killer application, that is cheap, easy, can be applied tomorrow, and delivers benefit every time?

Try Peer Assist.

Fascinating figures on the usage and value of KM processes

I blogged yesterday about usage and value of Knowledge Management technologies. 

Here is a similar analysis, also drawn from our  2014 Global Survey of Knowledge management, of the usage and value of KM processes.

We asked the survey participants to rate these different KM processes by the value they have added to their KM program, including in the question the option to choose "we do not use this process" or "it's too early to tell".

The chart above shows these processes in order of usage from left to right, as a stacked area chart of responses, with the weighted value of the process overlain as a line (this line would be at 100% if all the participants that used this process claimed it had "high value" and at 0% they all claimed it had no value).

267 people answered this question on the survey. from a wide range of organisations around the globe.  95% of the people who responded had a KM role in their own organisation, and 75% were either leading the KM initiative or part of the KM team.

The processes are also listed below in order of the usage figures, and in order of the average value assigned by the 267 respondents.

Knowledge Management processes in order of usage  (most common at the top)	Knowledge Management processes in order of the assigned value when used (those rated most valuable at the top)
1. Peer Assist 2. After action review 3. Knowledge roundtables 4. Crowdsourcing 5. Coaching and mentoring 6. Positive deviance 7. Project lessons capture (large scale) 8. Open space 9. Wikithon 10. Action learning 11. Knowledge cafe 12. Retention interviews 13. Appreciative enquiry 14. Storytelling	1. Knowledge roundtables 2. Peer Assist 3. After action review 4. Crowdsourcing 5. Coaching and mentoring 6. Positive deviance 7. Open space 8. Action learning 9. Project lessons capture (large scale) 10. Retention interviews 11. Wikithon 12. Knowledge cafe 13. Appreciative enquiry 14. Storytelling

What does this tell us?

We could take these results at face value, and say that the chart and the lists above represent the usage of the various KM processes and (independently) the value of the various processes.  The strong correlation between usage and value that we see in the chart and lists could represent a tendency for companies to preferentially use higher-value processes. They therefore get more use because they deliver more valuable. This is a perfectly valid interpretation.

An alternative argument would be to say that processes deliver more value the more they are used. Processes at the top of the list are mainstream processes, used frequently, and delivering high value. Processes at the bottom of the list are less mainstream, and deliver less value to the companies that use them because those companies make less use of these processes (remember that the Value figure is derived only from the companies that make use of the process). This is also a plausible interpretation - that the list describes a transition from mainstream to "occasional use".

However I think we can conclude that the processes at the top of the list - the old standards of Peer Assist, AAR, Knowledge Roundtables (aka Knowledge Exchange), Crowdsourcing (eg through the use of CoP forums) and Coaching and Mentoring - should form the basis of any KM process toolkit.

Ten secrets for great Peer Assists

---

photo by BluEyedA73 on Flickr.

Peer Assist is one of the easiest, and at the same time one of the most powerful processes in the KM toolbox. It is powerful, because it brings knowledge to the point of need, in its richest form (i.e. in the heads of people with experience). It is simple, because it is based solely on dialogue between the host team and the invited “peer assisters”. It is a Help session - it allows people to ask for help in a safe way.

However to deliver the value from Peer Assist, there are some simple rules to follow. These are presented below in reverse order of importance.

10. First, check that you really need a Peer Assist. Maybe your network or community of practice can provide the solution to your problem, or maybe there is already an established practice in place that answers your needs. Peer Assists are powerful, but there may be a simpler way to learn.

9. Prepare some briefing material for the event. This should not be too detailed, but should provide the necessary context for the peer assist. At the very least, the visitors should have a good idea of the importance of the challenge they are being asked to help address.

8. Allow enough time for the peer assist. A peer assist on a really important topic cannot be conducted in a hurry. Half a day will probably be the minimum, but big peer assists can take up to 3 days or more.

7. Include time for the assisters to gather their thoughts and feed back. Without careful facilitation, the host team can dominate the time giving presentations. This is not what you want. Presentations should take up no more than 20%-25% of the time, and you will need to allow an hour (or even two) towards the end for the visitors to gather their thoughts, review what they have heard and seen, and prepare feedback for the host team.

6. Follow up after the Peer Assist. If you have been successful in forming the team spirit (see #5) then the visitors will feel they have a stake in the success of the host team’s project. Make sure they are keep updated with progress, and continue to use them as a resource for advice and experience.

5. Set the atmosphere to elicit frank and open exchange. This is crucial. If a peer assist descends into attack/defend behaviour, the event is broken and will not deliver value. If the host team is not open about their challenges, then the proposed solutions may not work. The facilitator needs to set the ground rule, watch the behaviours, and intervene if needed. Encourage the visiting group to perform as a team, together with the host group. A peer assist is almost like a problem solving team, where the host team has knowledge of the problem, and the visitors have knowledge of possible solutions. There is a joint responsibility to find the best solution(s) to the problem, and the visitors and the hosts need to feel they jointly own this. Include time for socializing to build the relationships that will promote this feeling. For example, for a one-day peer assist, invite people for a dinner the night before.

4. Invite a diverse group of peer assisters. The more diverse the group, the more likely you are to find the out-of-the-box idea that creates the breakthrough solution. Don’t invite “the usual suspects”, or you will just get the usual answers. Don’t just invite the old friends of the host manager, or you will just get the old friendly answers. Look for diversity of experience.

3. Be very clear about the objectives. This is really important. The clearer you can be about the objectives, the more likely you are to achieve them. SO before the event, spend time with the host team and the host manager, and create some clear terms of reference, with well-defined objectives and deliverables.

2. Plan the Peer Assist to be held when the host team are clear on the questions to be addressed and the challenges they face, but early enough that they are open to incorporating the feedback. Once the host team has decided their solution, it’s too late for a peer assist, as they may no longer be open to making changes. Then you end up with a frustrating event, where the visitors say “don’t do it like that, it won’t work” and the host team say “it’s too late, we are already committed”. This is where attack/defend behaviours can start.

1. Act on the results. This is the most important rule of all. There is no point in having a peer assist, if nothing changes as a result (except in the unusual case where the project team has already thought of everything). After the feedback session (#7) the host team should create an action plan (and feed this back to the visitors), detailing what they will do as a result of the peer assist. It is also worth checking that this plan is followed, so one of the actions may be to create a formal report back to the visitors, some time in the future, listing what was done as a result of the peer assist, and what the results were.

Follow these rules, and your peer assists should add real and lasting value. Neglect them, and not only will your peer assist potentially be a waste of time, you may also have tarnished the image of KM by introducing a tool which has not delivered against expectation.

How to get new staff up the learning curve

---

Sam Burgess (left) and Kyle Eastmond
playing Rugby League for England 

I keep my eye on two things online - Knowledge Management, and Rugby Union. Sometimes the two overlap, and indeed there is much that the business world can learn from sport when it comes to managing knowledge in order to drive performance.

Let's take the issue of how you incorporate new staff.

You bring in a bright and capable person from another industry. To maximise their value, you need to get them up the learning curve as quickly as possible. How do you do this?

Let's look at how they do it in sport.

Bath Rugby has just signed up one of the few Megastars in the Rugby world - Sam Burgess. Sam has been described by the BBC as "a rugby freak, a 6ft 5in, 18st beast of a man with quick hands and a charming character, brave and strong on and off the field, a sporting superstar".

Sam has joined Bath, with the ambition of playing for England in the 2015 Rugby World Cup.

The problem is that Sam plays a different brand of the game - Rugby League instead of Rugby Union. He has a massive amount to unlearn and re-learn as he starts life in a different context, hoping to reach the top within a year. How do Bath get him up the learning curve as quickly as possible?

Here's what Brian Ashton, former England head coach says.

“A coach like Mike Ford (head coach of Bath) will be a great help to Sam but the person who will potentially be a bigger help is Kyle (Eastmond, Bath player), because he only recently made the same switch (from Rugby League to Rugby Union) that Sam’s making. He is someone who can tell Sam about the pitfalls and blind alleys that can arise during the switch to Union. I’m a great believer that the best help you can get is from your peer group rather than the coaches in a situation like this.” 

The key then, according to Ashton, is Peer Assistance, rather than (or as well as) using the established Expert Coaches.

This is valid in business as well as in sport.

If you want to bring a new employee up to speed quickly in the way the company works, assign them, as a coach, a colleague who arrived a year or two ago, and who knows the pitfalls and blind alleys that can face a new employee. This is what Ashton is suggesting for Sam Burgess - using Kyle Eastmond as a peer coach, as Kyle and Sam have a shared context within which effective Knowledge Transfer can occur.

Similarly, if you are starting a new project, use Peer Assist rather than expert coaching, so the project team can learn from others who have "been there and done that".

If you are bringing in annual graduate intakes, then set up a Community of Practice for new graduates, so they can coach each other in "how we work in this organisation".  Look at the example of the US Military "Company command" forum, where company commanders coach each other, or the Platoon Leader version. Both of these are prime examples of Peer Coaching for individuals new in a role.

The world of the Military and the world of Sport know that the best coach for an employee in transition is someone who has recently made the transition themselves - a Peer Coach.

The world of business can learn this too.

"This time it's different" (wrong!)

---

Albert Einstein's definition of insanity was "doing the same thing over and over again and expecting different results".

And yet, any analysis of a collection of corporate lessons will show the same mistakes being made time after time. My colleague Rupert has made an analysis and collection of these repeat mistakes, with a series of blog posts describing each one - excellent reading for any project manager or knowledge manager.

So organisations obviously DO "do the same thing over and over again and expect different results".

Are organisations insane?

Or is there another factor at work?

The factor may well be what the Farnam Street blog calls the "This time it's different" fallacy. I quote from the blog -

“This time is different” could be the 4 most costly words ever spoken. 

It’s not the words that are costly so much as the conclusions they encourage us to draw. We incorrectly think that differences are more valuable than similarities. After all, anyone can see what’s the same but it takes true insight to see what’s different, right? We’re all so busy trying to find differences that we forget to pay attention to what is the same.

Different is exciting and new, same is old hat. People focus on the differences and neglect the similarities. In projects, this becomes the "my project is different" fallacy that I described here. People look at their projects, see the unique situations, find the differences, overlook the similarities to all similar projects on the past, and assume that "this time it will be different".

It never is.

The same old mistakes will creep up on you and bite you in the bottom, as they always do.

Instead of assuming "this project is different", perhaps we should start with the assumption that "this project is just like any project. It involves building and understanding client requirements, choosing and forming the team, selecting and managing sub contractors, balancing the innovation against the risk, communicating within the team and with the client, keeping the client requirements always in mind, managing quality, managing cost, managing time, managing expectations, managing risk, and so on".

Then look for the lessons that will help you with all those tasks, and will help you avoid all the old pitfalls. As the Farnam Street blog says,

If you catch yourself reasoning based on “this time is different” remember that you are probably speculating. While you may be right, odds are, this time is not different. You just haven’t looked for the similarities.

A great antidote to the "This time it's different" fallacy is that good old, tried and tested mainstay of Knowledge Management, the Peer Assist. Once a project team gets into a room with a bunch of people with experience, the conversation automatically focuses on the similarities. "Yes, we've seen that, we've been there, here's what we learned" and it becomes increasingly difficult to maintain that "This time it will be different".

Mutual benefit in the Peer Assist

---

The Peer Assist (the "Killer App" of KM) is unusual in KM in that it delivers value both to the givers and the receivers of Knowledge.

Nancy Dixon gives a great example of this in her book "Common Knowledge", and I have seen it myself many times in various Peer Assists around the world.

In theory, the transfer should be one-way. A team has a challenge - they invite others with experience to con and discuss with them and share their experience - they develop a new way to approach the challenge. It looks like a clear example of one-way knowledge flow.

However what happens when the conversation starts, is that the participants quickly discover that the experience if the visiting team was developed in a different context from the challenge of the host team. Sometimes there is a large contextual difference, sometimes small, but always there is some difference. The conversation goes something like this .....

• "You should try this"
• "No, that won't work here"
• "Well it worked for us"
• "But it won't work here"
• "Why not?"

It's in the discussion that follows the "Why Not" that both teams begin to learn. The visiting team needs to re-examine their solution, and understand the root causes of why it worked for them, and to separate out those root causes that were situation-specific and those which were generic. The host team needs to examine their challenge, and understand the root causes behind the challenge, and see which ones of these are generic enough that the visitors' knowledge can help. By collectively deconstructing both the solution and the problem, they collectively come up with something new.

That's why peer assists can take a long time - it can take an hour to do this deconstruction (and it doesn't need to be particularly structured either - the deconstruction happens through mutual exploration of the challenge in the light of the visitors experience). That's also why Peer Assists are far more effective face to face. That's also why both teams benefit. The host team learns a new solution to their challenge, and the visiting team understands their own solution much better.

When do you need a Peer Assist:?

---

Here are some guidelines for whether a Peer Assist is the right solution for a project

• The project recognises that it needs knowledge
• The required knowledge is complex knowledge, which has not been codified into standards and best practices.
• The Project team has tried traditional knowledge sharing methods such as iLearning, formal training, expert support etc.
• The scope of work, and the issues which need to be discussed, are clear.
• The project team have enough knowledge of the subject but still need expertise and experience from other people to help them make the correct decision.
• The project team are still open to new ideas and challenges, and are not yet comitted to a course of action
• The potential saving exceeds the cost of the meeting.
• Therefore they need a Peer Assist

Tips for effective Peer Assist

---

Peer Assist is one of the most popular, simplest and most effective of the KM processes, the closest we have in KM to a Killer Application.

Here are some tips for getting the most out of Peer Assist.

• Research and network to determine if a possible solution to your challenge already exists. A peer assist is expensive - try other routes first.
• Plan the Peer Assist once you are clear on the questions to be addressed, but early enough to incorporate the feedback. You must have an open mind for a peer assist to add value.
• Be very clear about the objectives. Fuzzy objectives is a common form of failure fort peer assists.
• Don’t invite only the “usual suspects”! Look for diversity and relevant experience
• Appoint a facilitator. Although a peer assist is simple, a facilitator can add massive value.
• Include time for socialising to build relationships and promote knowledge sharing.
• Set the atmosphere to ensure frank and open exchange.

KM in the rubber room

---

This is a great analogy I picked up last week from Emily Timmins, Knowledge manager at Severn Trent Water.

She has been introducing Peer Assists, and the analogy she uses for a "safe space" for knowledge sharing is the Rubber Room.

Of course they don't hold peer assists in a real rubber room, but they use that analogy to create an environment of safe experimentation, and open sharing.

Rubber is

• soft, you won't get hurt
• elastic, so you can bounce ideas
• stretchy, so you can stretch ideas
• allows you to erase things if you need to

It's a great analogy for the safe spaces you need in knowledge management.

Quantified KM success stories 21 - Peer Assist at De Beers

---

This success story is extracted from a chapter of my book "Performance through Learning", and describes how a Peer Assist at De Beers delivered a value of tens of millions of Rands
.

"Central Mines was one of the areas identified before the workshop as a potential pilot area for De Beers. Dieter Haage, the general manager at one of the larger mines, Finsch mine, already saw the potential of Knowledge Management but at that point did not have a clear idea of how he would implement it. That was partly why the December workshop had been so powerful; it had provided the mines with a toolkit and an implementation plan.

"Bruce Emerton had been identified as the potential knowledge manager for Finsch, and Bruce had attended the workshop. Bruce identified a couple of options for the application of KM, one of which was to hold a Peer Assist on the subject of earth-moving equipment. Finsch was about to invest heavily in earth-moving equipment, and wanted to draw on the knowledge and experience of the other mines first, and evolve the relationship with the chosen supplier through sharing knowledge to improve the outcome for mutual benefit. In some ways the peer assist was held later than would have been the ideal point, but the level of sharing was still very high, and some crucial knowledge and insights were exchanged during the breakout groups within the peer assist.  The facilitator calculated that there were over 240 man years of knowledge and experience present in the room, all of which could be brought to bear on Finsch’s issues.

 "Bruce believes that this knowledge has helped deliver R80 million in added value for Finsch mine. Again, this was a crucial early win for De Beers, and particularly valuable in that it delivered a hard monetary benefit in an area of strategic focus, namely underground mining. A similar peer assist for Premier mine proved equally successful in providing the Premier team with collective insight into how to improve current and future operational performance".

Success Story - Alaska Peer Assist

---

Here's an excellent success story on Peer Assist, told here by Kent Greenes

"I recently facilitated a peer assist for a health care provider in Alaska whose aim was to develop a capital business plan that would gain approval from budget holders outside Alaska to renew aging facilities and grow capability for long-term health care. A preliminary version of the plan had met resistance from these decision makers; the Alaska team was told to go back to the drawing board and develop a plan that required significantly less investment. The team had been working for months at reducing the cost and had gotten to a point where they exhausted what they knew and the knowledge they were able to get their hands on. They called me in to plan and facilitate a peer assist.

After calls with potential peers from the provider's operations in Washington and Oregon, we held the peer assist in Anchorage with the home team and eight visiting peers. The peers openly shared the lessons they learned from developing capital plans for long-term-care facilities in their regions. It was clear by early afternoon on the first day of the peer assist that their advice to the Alaska team was to reduce their capital plan by remodeling and repairing existing facilities.

The Alaska team insisted that their environment and customer needs were different from those in the northwestern United States and remodeling wouldn't provide the long-term care needed to attract, serve, and retain potential Alaskan customers. Later that afternoon (and planned as part of the session) the peers visited several long-term-care facilities. The experience made all the difference in the world. The visitors now understood the Alaskan context for long-term care and changed their advice. They felt new facilities were warranted in Alaska and spent the second day of the session developing new options and approaches for capital-plan submission with the home peers.

One of their recommendations was to perform a new survey of the aging population in the region. The peer from the Oregon provider operations had recently done something similar and offered a set of questions and a survey approach that were geared to providing design input for the development of long-term-care facilities. On the spot, the peers modified the design of the survey to address the Alaskan environment, native Alaskan culture, and other unique aspects of the aging customer base in that region.

The session led to a breakthrough in the Alaska team's thinking and capital plan. Not only was their plan approved, but the visiting peers benefited from the experience as well. An e-mail received by the Alaska team leader reinforced this: "Thank you again for the wonderful opportunity to work together last week. I really applaud your willingness to hear new ideas and your dedicated commitment to the people you serve. Kent, you taught us a new appreciation for the power of coming together to harness our collective knowledge to fulfill our mission. It was an enlightening two days for me, and I am very grateful for the experience."

Many of the peers who came together for those two days continue to communicate and collaborate on a routine basis".

Good job, Kent!

KM tailoring guide

---

day 259: expert tailoring

Originally uploaded by cuttlefish

Lets think about Knowledge Transfer, through a Push mechanism

Imagine you have some learnings within a team. How do you pass them on?

I am a great believer in tailoring your approach to circumstances, and the circumstances you need to consider are as follows

• Who needs the knowledge? The same team as generated it, or a different team?
• When do they need it? Now, or at some undetermined time in the future?
• Where are they? Near enough to sit down with, or somewhere remote?

So we have three variables, so we can't draw a Boston Square with four divisions - we have to draw a Boston Cube with eight. And in each of those divisions, we take a different approach to how we transfer the knowledge.

1. Same team, same place, same time - hold an AAR. Discuss the learning, and help everyone internalise it.
2. Same team, different place, same time (virtual team) - hold a virtual AAR. Discuss the learning, and help everyone internalise it. Checking for internalisation will be harder without access to body language.
3. Same team, same place, different time - hold a Retrospect and update and improve your team processes, procedures and practices. Then if you follow those next time, performance will improve.  
4. Same team, different place(virtual team), different time  -  conduct a Learning History and update and improve your team processes, procedures and practices. Then if you follow those next time, performance will improve.
5. Different team, same place, same time - hold a Peer Assist. Discuss the learning, and help the other team internalise it. Or host a site knowledge visit
6. Different team, different place, same time - hold a virtual Peer Assist. Discuss the learning, and help everyone internalise it. Checking for internalisation will be harder without access to body language. Set up a community of practice, or virtual coaching group.
7. Different  team, same place, different time - hold a Retrospect and document a Knowledge Asset. When the knowledge is needed, find someone from the original team to talk through the Knowledge Asset.
8. Different team, different place, different time - hold a Retrospect and document a stand-alone Knowledge Asset.

Different contexts, different approaches.

Learning to fail, or failing to learn?

---

failure
Originally uploaded by smemon87

I was reading this blog post the other day, about the role of failure in learning. In the post, the author says the following.

Every individual has three orientations in encounters with new areas of discovery — avoiding, performing and learning.

Most organizations are performance driven. The employees who perform the best are the ones who are rewarded. Those who try to improve on performance and fail are reprimanded. However, it is only in trying something new that they can improve performance, where new discoveries are made.

The implication here, is that failure and learning are linked, and that failure should not be treated as a negative thing, if it leads to learning. I know there is a strong body of thought that says you need to fail, in order to learn. "Experience is the best teacher" and so on. "Take risks, fail, learn". "Trial and error" is often used as a synonym for learning.

I have been thinking long and hard about this, and I dont think that I agree. I think you can learn, and still minimise failure. I think you can learn, and AVOID failure.

I know that the writer of the blog was contrasting "playing safe" with risk taking, and mentioning failure in the context of trying somethign new, but there are three points I would like to make here.

1. "Performing" should not be seen as in contrast to, or opposed to, learning. Performing and learning go hand in hand (see the video on Performing on our Knowledge Management video page - its in the middle of the bottom row). Performance should never be static - no manager should accept performance which is not constantly improving. Static performance is poor performance. John Browne's challenge to BP, which was such a strong driver of KM, was "every time we do something, we should do it better than last time". For him, static performance was failure.

2. Risk taking, trying new things, and failing are no guarantee of learning. I have seen people take risks, and create their own new solutions, as an alternative to learning from others. I have heard one guy say "I know that factory over there has done this before, but rather than learn from them, I am going to create my own solution. That's what I do - I am an engineer, and my favourite tool is the blank sheet of paper". Informed and strategic risk taking is fine. Taking stupid risks is just plain stupid. Failure in service of a stretch goal may also be fine, provided there are contingency plans and fallbacks, and also provided you haven't wiped out the company budget or killed someone along the way. Failure because you are too dumb or too lazy or too proud to learn from others before trying something new, is not fine.

3. Risk taking plus learning avoids failure. Part of the thinking behind the quoted post (that if you don't fail, you won't learn) is based on the assumption that all learning comes from doing. If you are "learning while doing", you need to feel your way, and mistakes and failures are unavoidable. But what if you "learn before doing"? What if you get us much knowledge as you can before you start? What if you learn from others (another plug for Peer Assist here), learn from your network and community, learn through practice, learn through scenario planning and role play? That way you take informed risks, and you minimise the chance of failure.

Let's sever this implied link between learning and failing. Let's embrace informed, knowledgeable risk taking as a way to avoid failure.

Let's re-unite learning and performing.

Lets learn to succeed, and learn to improve.

How intellectual inbreeding stifles the meme pool

---

Face 0000014
Originally uploaded by bixentro

Someone came up with a great phrase in a workshop today - "Intellectual Inbreeding"

What they meant by "Intellectual Inbreeding" is the sort of restricted group think you get, when ideas or practices have been the province of a small group of people.

We see this very clearly in our famous and powerful Bird Island exercise, where groups can get stuck on a particular design, and can't see the wider possibilities. Maybe they have built a design that reaches 60cm, and think that if they really push everything to the limits, they might reach 75cm, little knowing that the best practice design is far taller.

Intellectual Inbreeding is what happens when the pool of ideas is too limited, and people can't think outside the box, to bring in new ideas and topics. Intellectual inbreeding results in a restricted meme pool.

The way to beat Intellectual Inbreeding is to bring in ideas from elsewhere, from outside the meme pool. You can do this through peer assist, for example, or through knowledge learning visits. In the Bird Island game, we open the doors and bring in people from other teams to share their knowledge and ideas. Often, while the team was racking their brains to take their design up to 75 cm, a member from another team might come in having built a design that already reaches 120 cm.

What happens then, is dramatic. You can almost see the scales falling from people's eyes, and you can almost hear the sound of the penny dropping.

Intellectual Inbreeding is one of the most dangerous outcome of siloed organisations. Use techniques such as Peer Assist to break the silos, exchange the ideas and experiences, and expand the meme pool. A healthy meme pool leads to a healthy knowledge ecosystem.

quick wins, long term benefit

---

Where do you start with KM? Where do you put in your efforts? Especially if you want to demonstrate quick wins? Do you start with Push, or with Pull?

Many companies seem to start instinctively with Push. "Let's share our Best Practices" they think. "Let's find what we are doing well, and then look for opportunities to replicate this elsewhere in the company". Seductive though this idea is, it won't deliver the quick wins. Let's imagine they capture some best practices on mergers, or on outsourcing, or on implementing ISO. It may be a long time before another merger, or another outsourcing, or another ISO implementation. Maybe nobody is ready to adopt these Best Practices right now. And even if they are, there is the Not Invented Here barrier to deal with. Maybe nobody is interested. There's many a failure story from "all push and no pull"

My recommendation is always to start with Pull, if you want the quick wins. Start with a problem, and share knowledge to solve the problem. Start with something where someone IS interested. Start with Peer Assist ("the killer app in KM"). The knowledge shared through the Peer Assist will find an instant application and a willing audience. There should be little or no "Not Invented Here".

But don't forget about Push. Don't forget about the Retrospects and the Knowledge Assets. Some time in the future, there WILL be another merger, or another outsourcing, or another ISO implementation, and then the knowledge will come in really handy. And then later there may be another another merger, outsourcing, ISO implementation. Then another.

Push reaps benefits over the long term. Capture knowledge once, re-use it twenty times. Pull reaps instant benefit, but maybe only once. It solves an instant problem, but leaves no trace.

Any well-balanced KM strategy requires Push and Pull, but don't count on Push for quick wins, or Pull for long term benefit.

Ten steps to an effective peer assist

---

Help!
Originally uploaded by D3 San Francisco

Peer Assist is one of the easiest, and at the same time one of the most powerful processes in the KM toolbox. It is powerful, because it brings knowledge to the point of need, in its richest form (i.e. in the heads of people with experience). It is simple, because it is based solely on dialogue between the host team and the invited “peer assisters”. It is a Help session - it allows people to ask for help in a safe way.

(If you need to know more about Peer Assist, contact us for a copy of our Peer Assist guide).

However to deliver the value from Peer Assist, there are some simple rules to follow. These are presented below in reverse order of importance.

10. First, check that you really need a Peer Assist. Maybe your network or community of practice can provide the solution to your problem, or maybe there is already an established practice in place that answers your needs. Peer Assists are powerful, but there may be a simpler way to learn.

9. Prepare some briefing material for the event. This should not be too detailed, but should provide the necessary context for the peer assist. At the very least, the visitors should have a good idea of the importance of the challenge they are being asked to help address.

8. Allow enough time for the peer assist. A peer assist on a really important topic cannot be conducted in a hurry. Half a day will probably be the minimum, but big peer assists can take up to 3 days or more.

7. Include time for the assisters to gather their thoughts and feed back. Without careful facilitation, the host team can dominate the time giving presentations. This is not what you want. Presentations should take up no more than 20%-25% of the time, and you will need to allow an hour (or even two) towards the end for the visitors to gather their thoughts, review what they have heard and seen, and prepare feedback for the host team.

6. Follow up afterwards. If you have been successful in forming the team spirit (see #5) then the visitors will feel they have a stake in the success of the host team’s project. Make sure they are keep updated with progress, and continue to use them as a resource for advice and experience.

5. Set the atmosphere to elicit frank and open exchange. This is crucial. If a peer assist descends into attack/defend behaviour, the event is broken and will not deliver value. If the host team is not open about their challenges, then the proposed solutions may not work. The facilitator needs to set the ground rule, watch the behaviours, and intervene if needed. Encourage the visiting group to perform as a team, together with the host group. A peer assist is almost like a problem solving team, where the host team has knowledge of the problem, and the visitors have knowledge of possible solutions. There is a joint responsibility to find the best solution(s) to the problem, and the visitors and the hosts need to feel they jointly own this. Include time for socializing to build the relationships that will promote this feeling. For example, for a one-day peer assist, invite people for a dinner the night before.

4. Invite a diverse group of peer assisters. The more diverse the group, the more likely you are to find the out-of-the-box idea that creates the breakthrough solution. Don’t invite “the usual suspects”, or you will just get the usual answers. Don’t just invite the old friends of the host manager, or you will just get the old friendly answers. Look for diversity of experience.

3. Be very clear about the objectives. This is really important. The clearer you can be about the objectives, the more likely you are to achieve them. SO before the event, spend time with the host team and the host manager, and create some clear terms of reference, with well-defined objectives and deliverables.

2. Plan the Peer Assist for the right time. What’s the right time? It is the moment where the host team are clear on the questions to be addressed and the challenges they face, but early enough that they are open to incorporating the feedback. Once the host team has decided their solution, it’s too late for a peer assist, as they may no longer be open to making changes. Then you end up with a frustrating event, where the visitors say “don’t do it like that, it won’t work” and the host team say “it’s too late, we are already committed”. This is where attack/defend behaviours can start.

1. Act on the results. This is the most important rule of all. There is no point in having a peer assist, if nothing changes as a result (except in the unusual case where the project team has already thought of everything). After the feedback session (#7) the host team should create an action plan (and feed this back to the visitors), detailing what they will do as a result of the peer assist. It is also worth checking that this plan is followed, so one of the actions may be to create a formal report back to the visitors, some time in the future, listing what was done as a result of the peer assist, and what the results were.

Follow these rules, and your peer assists should add real and lasting value. Neglect them, and not only will your peer assist potentially be a waste of time, you may also have tarnished the image of KM by introducing a tool which has not delivered against expectation.

Cultural chicken, KM egg

---

Baby Chickens Beaded Easter Eggs (Ternopil, Western Ukraine)
Originally uploaded by MariyaZ

Which comes first, KM or culture change?

We all know the two are linked, but do we change the culture first, then bring in KM? Or do we bring in KM, and then change the culture?

I have blogged recently about the nature of the culture change, and about the need to implement KM in a stepwise manner based on the demographics of engagement. But even in the early stages of implementation, you still have this chicken and egg problem -

Which comes first - KM or culture change?

And of course the answer is that, just like chickens and eggs, you can't separate them. They are part of a system.

One of the things that really works in your favour, is that the KM processes themselves (and I stress processes rather than technology - technology can eventually change culture, but it is far slower) are in themselves culture change agents. They promote openness; people will learn that ‘there is no comeback’ and questions will receive answers. They promote reflection, learning and a performance focus, through discussions on "What did we set out to achieve? What actually happened”. They promote a sense of community.

Peer Assists are a prime example. By giving people space and structure to exchange critical knowledge, and by making it legitimate to ask others for help, you not only create, in that meeting, a culture of openness and sharing, you also start to build a sense of community between the project team and the Peer Assisters.

Not just Peer Assist either. We were working several years ago at an industrial plant in the US, experimenting with introducing After Action review. We found that not only did the AARs identify many many opportunities to save time and money, they also started to change the mindset, as these quotes from the workforce demonstrate.

I thought I needed to be the expert and felt threatened at first. After a few AAR’s I felt comfortable that the guys appreciated using their ideas and we became a team (Supervisor)

Before the AAR, they didn’t feel like they were a team; After a few AAR’s they became one. (Boilermaker)

I have been doing this work for 20 years, and no one has ever asked me what I thought before; so it was a change. (Boilermaker)

We are now doing a Before action review in the mornings. (Supervisor)

Here's another quote, from a mine manager in Botswana, where we used AARs to radically improve some of his production processes, and deliver savings in the million-dollar range. However for him, there was something even more important than the money.

"The most important thing is the engagement of the people. The people who were involved in this, they actually feel that they are part of a team now. It's not the project team vs the contractor vs the end users - everybody is part of a single team now. And people are actually coming up with suggestions for implementation, and what makes it quite exciting is that people come up with very good suggestions, we implement it, they see the implementation of that, and they see the benefit afterwards, and so success breeds success".

That engagement, and that "success breeding success," was worth more to this manager than a million dollars, because it is the start of a new engaged performance-driven knowledge-enabled and knowledge-seeking culture that will deliver value for years to come.