Friday, 31 July 2009


Quantified value case study number 10


To continue this occasional series - here is a story told to me about a quantified benefit identified in a Technical Limit meeting. Technical Limit is a Knowledge Management technique used in the oil sector, pioneered by Shell, for detailed knowledge-based operational planning. It is a combination of learning from the past (in that the planning is based on a through understanding of past performance), tacit knowledge exchange (in that the operational crews bring their detailed knowledge to the event), and innovation (in that the driver for the meeting is to innovate beyond the best of past performance). The story is told by someone who was running one of these meetings, and the story starts in the technical limit meeting, where the operational teams are being challenged on performance improvement on one small step in the process of drilling the next well. As you read this story, remember that in oil drilling, time is money, as offshore drilling rigs can cost $250,000 per day to hire. The pressure is therefore to shave as much time as possible off the process, and the key knowledge is "How to drill quickly".

The rig crew had taken a look at the task of 'running the riser' (constructing the large pipe that connects the rig to the seabed), and they felt that based on the best of the past performance, they could run the riser in 48 hours. When they were challenged to do it a bit faster, they worked on things that would shave maybe an hour or two off the time. So the next step was to get them to analyse why it took 48 hours, and what the critical things in the path were that caused it to take 48 hours, and it turned out that the hydraulic wrench, which was used to bolt the riser sections together was the critical element.

And the next question was, 'What would it take to run two hydraulic wrenches', because if they could run two hydraulic wrenches, they could cut the riser running time from 48 hours to 24hours. Then they said they actually had two hydraulic wrenches on the rig, as they had a back-up in case the primary one failed.

So why they couldn't run those two simultaneously? And the answer back was that they only had one hydraulic pump.

What would it take to run two pumps? It would take $16,000 to buy the second pump.

What would it take to buy the second pump, and they said that they hadn't been able to get anyone to authorise that $16,000 capital expenditure.

So it turned out that for saving $16,000, the company was spending an additional $250,000 in rig time running the riser. So a deal was made with the rig contractor to add a second hydraulic pump and adjust the dayrate, and cut a day off the well time.


Technical Limit meetings can identify many such savings in a single meeting, and can result in overall time and cost savings of 40%, as shown in this example from Oman

Thursday, 30 July 2009


Knowledge capture quote



Post-it notes
Originally uploaded by watchsmart

I write down everything I want to remember. That way, instead of spending a lot of time trying to remember what it is I wrote down, I spend the time looking for the paper I wrote it down on.
- Beryl Pfizer


What is Knowledge Management? Simplest definition


I don't think I have shown this one on my blog before - it's one of the first videos I uploaded to Youtube, and currently the most popular. It's a very simple, very generic definition of Knowledge Management.



All comments welcome!

For more Knowledge Management Video, on a wide range of topics - go here

Wednesday, 29 July 2009


What are you searching for?




curious roy
Originally uploaded by fazen
An interesting post from Mary Abraham on what an analysis of searches might tell you about knowledge topics. If you could analyse patterns of searches, it might lead you to identify emergent knowledge topics in your organisation, your community, or in society.

We tried just this approach of analysing queries in a big community of practice recently. The queries to the community forum were already characterised into topics because when you submit a search to this particular community of practice you have to choose which topic it is related to. So that saved us having to assign categories.

We divided these topics into four quadrants;

1. Topics where there were few questions, but each one got lots of answers. These tended to be areas of common knowledge, where most people knew the answer and only a few new people did not. For these topics, we could write guidelines or faqs for the benefit of the new staff

2. Lots of questions, lots of answers. These were the important and evolving Knowledge topics where it was worth while setting up community meetings so that we could start to exchange and document best practice.

3. Lots of questions, few answers. These were the problem areas, where some more research or action learning was needed to start to develop solutions.

4. Few questions, few answers. Our assumption was that these are not particularly important areas, but that it was worth watching them in case they developed into problem areas.


This was a very useful analysis and led to a greater understanding of the important evolving and problem topics within the community.

Tuesday, 28 July 2009


Governance framework for Knowledge Management



Introducing Knowledge Management is widely recognised as a culture change process, and once the culture has been introduced, along with the roles, the processes and the technologies, then it's tempting to think "Job Done!

But you cannot just assume that cultures will stay changed! Even with long-established management cultures such as the culture of financial rigour, there are always the lazy people who fudge the figures, or the unscrupulous individuals who "cook the books". However as as far as financial management is concerned, there will be good governance in place. There is a clearly defined compliance standard that defines what acceptable financial management is, and any company that wants to operate in the market place abides by the standard and plays by the rules. If the rules are broken, there are sanctions and punishments, as the directors of Enron found out to their cost. These rules, standards and sanctions are partly responsible for ensuring that good financial management is widespread and sustained, despite the odd bad apple.

As yet, there are few governance standards or governance systems being applied to Knowledge Management. Many companies assume KM will be sustained by the enthusiasm and belief of the practitioners. However this enthusiasm is not endless, and KM implementation often falls into a familiar pattern:

1. Knowledge Management introduced with a fanfare and management support
2. Implementation team set up, with budgets and targets
3. Implementation team delivers successful high-profile pilots in some areas of the business, and introduces some new technologies and processes
4. Implementation team realizes that implementing Knowledge Management is going to be slower and more difficult than anticipated
5. Management loses patience and declares victory anyway, prematurely closing down the implementation team
6. Knowledge Management continues for a while, sustained by enthusiasts and champions, but never becomes an established management discipline, and gradually dwindles away.


I have seen this "dwindling" happen very often, once the initial driving force is removed.

Why does this happen? Why does Knowledge Management so rarely survive the departure of the implementation team? Is there something that we can learn from the implementation of other successfully sustained management practices? Yes there is - the answer is Governance.

Governance for me refers to all of the management and organisational elements that need to be in place to ensure an asset (in this case Knowledge) is managed properly and with rigour in a sustained way.

If you are a manager and you want to get something done in your organization, you need to set three things in place.
  • Firstly, you need to make it very clear what you want done.

  • Secondly, you have to give people the tools and the training to do it.

  • Thirdly, you need to check that they've done what you want it.


This is true in all areas of life. If you wanted to get your teenage son or daughter to mow the lawn, for example, you would firstly be very clear with them what you expected them to do, secondly you would show them where the lawnmower is, and tell them how to use it. Finally you would check that they really have done it. Without the clarity of expectation and explanation, they would most likely claim that they weren't sure what to do and so not do it, or else they would half-do the job, leaving the edges untrimmed and the grass clippings all over the lawn. If you don't give them the lawnmower and show them how to use it, they wouldn't be able to get started anyway, and if you didn't check up on them, the likelihood is that they might be distracted by more urgent activities such as the PlayStation, or instant messaging their friends. Those three elements - clarity of expectation, the tools to do the job, and monitoring – make sure the job gets done. They form a governance system for mowing the lawn. The same three elements are needed in a governance framework for KM.

Management disciplines are sustained, because there is a framework fo governance to sustain them. Again if we look at financial management, everybody in the organization is clear on what is expected of them. They know that they will have to prepare budgets at the start of any significant piece of work. They know they will have to do cost tracking as the work continues, and will have to balance the books at the end of the job. They will have the tools to do these activities, such as SAP or Excel spreadsheets, and they will have the training they need. They also know that management will be checking that they have done what they're supposed to do, and there may well be periodic audits to check compliance against the expectations. Whether or not the employees believe that financial management is a good thing, the company has put in place a framework to ensure that it happens.

Imagine if a similar governance framework were applied to Knowledge Management. Imagine if the staff in your organization knew that they had to do a “knowledge budget" [or other learning and planning activity] at the start of any significant piece of work. Imagine they knew that they would have to do knowledge tracking as the work continues, and "balance the knowledge books" by capturing their learning at the end of the job. Imagine that they had the tools to do these activities, and the training to use the tools, and also that management will be checking that they've done what they are supposed to do. Whether or not the individual employees believes that Knowledge Management is a good thing, such a governance framework would ensure that it happened.

The framework we recognise for Knowledge Management therefore contains the following elements (see Figure):

  • A set of clear corporate expectations for how knowledge will be managed in the organization, including accountabilities for the ownership of key knowledge areas, and the definition of corporate standards for Knowledge Management.

  • A Knowledge Management system, providing the means by which knowledge can be managed. This is not just an IT system, but a holistic management system, which will include
    • Roles for Knowledge Management

    • Processes for capturing, organizing, accessing and communicating knowledge.

    • Technologies for capturing, organizing, accessing and communicating knowledge.

  • A person or team monitoring and measuring the application of KM, to make sure that people are delivering on their accountabilities, and applying the system in the way that they are expected to, to identify the need for new interventions to improve the KM system, and to ensure a continuous improvement in the ability of the organization to manage strategic knowledge.


    Monday, 27 July 2009


    More preliminary survey results


    I blogged yesterday about results from the Lessons Learned survey, showing that more than half of the respondents were less than satisfied with their lessons learned system.

    Here are some of the barriers or problem areas identified by those who scored 2 or less out of 5 for the effectiveness of their system. Do any of them ring a bell with you?

    • Incoherent information management process, senior management buy-in, no metrics, time!
    • Currently no central access point or repository for lessons, no central senior sponsorship, currently culture very much on delivery not learning
    • Management involvement; taking ownership for (sharing/learning) processes beyond borders of own field of responsibility. Takes continuous attention.
    • Cultural resistance to flagging bad news; difference between talking the talk and having to walk the walk (corporate commitment); sheer size and scope of the organisation
    • Besides noting the lessons down the organization does near to nothing with them. Conclusions from lessons range from "continue' to 'don't do this again" which means the lessons and mainly the conclusions are not SMART. No actions however arise from the defined lessons making it a purely 'check in the box' activity with no added value.
    • Rapid change of staff / redeployment at the end of projects
    • Lack of organisational buy-in, lack of clear path to improvement, too many initiatives
    • Restricted audience. Hard to find the reports. Done in an inconsistent way. Can be seen as box ticking. Little top management follow up.
    • Transferability of Lesson Learned
    • Management buy-in and commitment to doing this
    • Sharing of the lessons learned to a wider group within the organization.
    • Formalising the process and incorporating in new work
    • Taking action on the learning after post-project reviews.
    • Sharing the learning more widely, beyond those who participate in review meetings.
    • Consistency in following the process.
    • The prevailing attitude was "this is how we have always done things and we won't change."
    • Lack of commitment from the management, long approving process, lack of immediate actions taken, lack of lessons that actually brought some visible improvement, lack of understanding how Lessons Learned can benefit company and individuals, lack of incentives for doing so, the process is not very well defined and people found it hard to follow, people are confused how to find the right lesson, etc
    • Functional management enforcing continuity of process and, therefore, lessons learned from project to project.
    • Although LL are collected there is no real evidence of anybody looking at them before starting other project work. Communication. Poor search facility.
    • Lack of appreciation of the value; management does not set the expectation; tendency to 'check the box' approach.
    • Has not become part of the culture and the way we want to do business
    • Not a good platform for sharing.
    • Willingness to conduct process
    • Improve the LL should leverage further for cross project sharing, improved template and common forum to discuss these (not just adding to repository)
    • No recognised process, limited follow up, limited prevention (living in present rather than planning for future), always something else more important,
    • Governance behaviour and resourcing and people moving on
    • Time constraints
    • Being able to demonstrate re-use
    • Finding time, and availability of consultants with the tacit knowledge, to undertake lessons learned exercises and to capture same explicitly.
    • leaders/sponsors need to create the climate so that LL can be learned and applied
    • Concerns about litigation
    • Timing is an issue - we don't immediately record them, and I believe that some are lost completely, or details are lost
    • Lack of performance management and follow through
    • Improve the closure of projects and easy access to lessons learned (both people and documents)
    • Not seen as central to performance management
    • Poor dissemination and use of lessons learned. Often just a tick the box exercise. Where something valuable is found, this is rarely transmitted to others who need to know or embedded in the network.


    I will share the final results from the study in a few weeks, when I close the survey. For the moment, its still open, and if you havent contributed please Click Here to take the survey, either on behalf of your own company, or a company you know well as a client or former employer.

    Sunday, 26 July 2009


    Lessons learned survey - interim results




    I have been getting some interesting results from my Lessons Learned survey. It's not yet time to share the full results, as I hope to get a few more responses (and if you have't filled in the survey yet, please Click Here to take the survey, either on behalf of your own company, or a company you know well as a client or former employer.


    So far, about 80% of the respondents say they have a Lessons Learned system.

    Of those 80%, the majority of respondents scored the effectiveness of their system as 2 or less out of 5.

    Thats a lot of unsatisfied companies!

    Friday, 24 July 2009


    Don't wait for knowledge to be volunteered - go seek it out



    I Know The Answer!
    Originally uploaded by ngader
    The problem of the Unknown Knowns (see yesterday's blog post) has another corollary - if you don't realise you have learned something, you don't volunteer it to anyone. And as I argued in the blog post, you often don't realise you have learned something, until you discuss it.

    Sometimes you find organisations who have set up a system whereby people are required to identify lessons themselves, and to add them into a lessons database. I am not as huge fan of volunteer systems like this; I don't even like them for collecting innovation suggestions. I think you capture only a small proportion of the lessons this way, because people are not aware that they have learned anything, and if they are aware, they often discount the learning as "not important". Also, self-written knowledge are often superficial, because there hasn't been the depth of dialogue and questioning to get to the lesson.

    Instead, don't wait for lessons to be volunteered - go seek them out. Go and do some proactive knowledge identification.

    There are two main approaches for doing this; reactive, and scheduled.

    The reactive approach requires someone to identify particular successes and failures from which to learn. The failures can be obvious, such as HSE incidents or significant project overruns, and many companies have mandatory processes for reviewing these failures. But how do you spot the successes? Maybe you can use your company benchmark metrics, and pick the best performing units for review. Perhaps you could work with the knowledge from the manufacturing plant that never had an accident, as well as from the one with frequent accidents. Maybe you can look for the best sales team, and look to learn the secrets of their success. Or maybe you can do both successes and failures - I did a very interesting study not long ago for an organisation that measures staff engagement using the Gallup survey. We picked the ten top scoring sales teams, the ten bottom scoring teams and the ten teams which had shown the most improvement over the previous year, and interviewed the team leader and a team member of each one, to pick out the secrets of successful staff engagement.

    Another organisation we have worked with uses global consultants and Technical Directors to identify opportunities for learning and knowledge transfer. They travel the world, reviewing activity at different centres, and will identify good practice which needs to be repeated, as well as opportunities to learn from mistakes.

    An alternative approach, common within project-based organisations, is to schedule learning reviews and knowledge exchange within the activity framework. These could be
    After Action Reviews on a daily basis during high-intensity learning, or after each significant task (BP drilling, for example, hold AARs after completing each section of an offshore oil well)
    Peer Assists early in each project stage, or during project set-up
    Retrospects (or some other form of Post Project review) at the end of each project stage, or at each project review gate
    • A Knowledge Handover meeting at the end of a project, to discuss new knowledge with other projects
    • A Technical Limit meeting during the detailed planning stage, to bring in knowledge from people with detailed experience
    • A Retrospect (or some other form of review) at the end of a bid process, when the company knows if the bid has been successful or unsuccessful.

    There are many advantages to the scheduled approach. Firstly, success and failure are components of every project, and if every project is reviewed, lessons may be identified which can avoid the big mistakes later on. Secondly, if lessons identification is scheduled, it becomes a clear expectation, and the company can monitor if the expectation is being met. This expectation is common in many organisations, thought the rigour with which the expectation is met seems to vary. Finally, by scheduling and facilitating the learning dialogue, you can uncover the knowledge that nobody knows they know, until they start to discuss it.

    Now I know that one of David Snowden's rules is that "Knowledge can't be conscripted, it can only be volunteered". I am not arguing for conscription, I am suggesting that you don't wait for the volunteers to come to you. Instead you give people scheduled facilitated conversation-based opportunities where they can become aware of what they know, and which provide a safe and encouraging environment for them to volunteer. Knowledge can't be conscripted, it can only be volunteered, and often it won't be volunteered until you ask.

    Thursday, 23 July 2009


    The Unknown Knowns



    Ignorant
    Originally uploaded by topgold
    We hear a lot (famously from Donald Rumsfeld) about the unknown unknowns, and how difficult they are to deal with, and in knowledge management terms, they can be a real challenge. However an almost equally challenging issue is the unknown knowns. These are the things that people know without realising – the unconscious competencies. These are very often the deep-lying technical knowledge that is of real value to other. But how can someone share knowledge is they don’t know they know it?

    An example comes from when I was teaching my daughter to drive. To start with, she did not know what she did not know. The whole topic of driving was a closed book to her. However, once she was behind the wheel, she began to be aware of the things she needed to learn. Now I have been driving so long (36 years), that I drive automatically, without thinking. I know how to do it, but I am not conscious of what I am doing much of the time. I don't know what I know any more. So when she asked me complex questions such as “when changing gear going down a steep hill, do I put my foot on the clutch before I put it on the brake, or do I brake first?” I had to think for some time, and often I had to get into the driving seat, go through the manoeuvre, and analyse what I was doing in order to become conscious of it, before I could explain it to her.

    The people who have the knowledge, are often unaware that they have it, like me and driving. The people who need the knowledge may often be unaware that they need it. Without an effective process to address the unknown knowns, the crucial knowledge may never get transferred. We need a process of helping people know what they know.

    We have already seen the process from my driving example – the process is questioning. There is a saying in the Middle East – “Knowledge is a treasure chest, and questions are the Key”. The most effective means of knowledge transfer is through dialogue – via questions and answers. Through a question and answer process, the knowledge supplier becomes conscious of what he or she knows, and once they are conscious, they can explain or demonstrate to the learner. The explanation or demonstration can be recorded and codified and made explicit.

    This works for teams as well. Teams have an unconscious competence in the way they work effectively together. Not only do the individual team members not know what they know as individuals, they doubly don’t know what the other team members know. So before you can start to capture or harvest any knowledge from a team, you need a team Q&A dialogue, carefully facilitated. Once you start the dialogue, and start discussing the reasons behind why things happened, the team will often piece together the learning as a group activity.

    Now imagine that you did not do this, and instead that you asked the team members to write down what they know. You would never get the unknown knowns, and you would never get at the double unknown secrets of team delivery.

    And yet many organizations expect just that – individual submissions – as a feed into their knowledge base. And then they wonder why they don’t get the value.
    Instead, look to make use of the dialogue-based processes,
    Interview
    After Action review
    Peer Assist
    Retrospect


    Use these as your primary means to help competence to become conscious, to help the knowns to become known, and to start to generate some content of real value.

    Tuesday, 21 July 2009


    "All the brains I can borrow"


    "I not only use all the brains that I have, but all that I can borrow".
    - Woodrow Wilson

    Great quote

    Monday, 20 July 2009


    The partitioning of noesis contradictoriness


    This has got to be the greatest product description ever, taken from this website referring to the book "advanced methods for inconsistent knowledge management"

    I quote

    Product Description

    The requirement for partitioning of noesis contradictoriness arises in some applicatory applications of machine systems. This category of contradictoriness results from the ingest of assorted resources of noesis in realizing applicatory tasks. These resources ofttimes are free and ingest assorted mechanisms for processing noesis most the aforementioned actual world. This crapper advance to inconsistency. This aggregation provides a panoramic photograph of nimble technologies for contradictoriness resolution.

    Features and topics include: Knowledge contradictoriness resolving; consensus and offend theories; contradictoriness of noesis – grammar and semantic; methods supported on contradictoriness measures for contradictoriness processing; noesis offend profiles; conflicts of ontologies; applicatory aspects of applications of planned methods.This aggregation presents state-of-the-art research, stuff a vacuum in the literature within the earth and offers researchers and graduates an valuable maker of meaning on the topic.


    Wow - that was a valuable maker of meaning on the topic! Now I just need to find out what a crapper advance to inconsistency is!


    Knowledge Management is not an end in itself


    Here's an excellent quote I found in my archives, from a review of Bechtel corporation in the late 90s

    "Knowledge Management is not an end in itself.
    Companies do not exist for the purpose of propagating and advancing knowledge - they exist to sell products and services.
    But to the extent that competitive advantage relies on informed decision making within the business - knowledge management has a crucial role to play".


    This speaks to the whole issue of the driving purpose of KM, which I covered in my blog post "Are you putting a man on the moon? Or just trying out a new mop?"

    The key three words in this quote are "informed decision making". If the key decisions in the company can be informed by the collective knowledge of the organisation, then competitive success is within your grasp.

    Sunday, 19 July 2009


    Beyond Explicit? Embedded knowledge.






    Originally uploaded by Liamngls
    Most people I speak to understand explicit knowledge to be as defined here from Wikipedia (and I would like for the moment to side-step the discussion about whether the description below refers to knowledge or information)

    Explicit knowledge is knowledge that has been or can be articulated, codified, and stored in certain media. It can be readily transmitted to others. The information contained in encyclopedias (including Wikipedia) are good examples of explicit knowledge.


    It is something codified and stored, and can be transmitted; like an article, an instruction, a video which demonstrates a process. Someone else can interact with this material and internalise it, act on it, and do something as a result.

    But there is another state in which knowledge can be expresses, and that is actually to embed it in a product or an object or a system. Let me explain with an example.

    I worked with a team in a pilot chemical plant in the USA. This was a plant which operated a new process, and they were learning - gaining knowledge- about plant operation. One of the things they learned, through discussion, and through trial and success, was how to shut the plant down safely. Once they knew how to do this, they wrote it down as a procedure, and perfected the procedure until they had it just right. The next step was then to program this procedure into the plant operating system, so that if there is a problem - a fire, an overflow, a blockage - the plant automatically shuts itself down by following the best-practice procedure.

    Now, what state is that knowledge in? I would say it has gone beyond explicit. Its no longer like an encyclopedia example, its not something that "can be readily transmitted to others". It's hardwired into the operating system.

    Let's call it "embedded knowledge"

    There are lots of examples of embedded knowledge around us. The lawnmower with the deadman's handle that shuts off the blades if we let go, because we all know it's dangerous to handle a mower with spinning blades. The microwave that calculates the defrost time based on weight and food type. The aeroplane that knows how to land itself. The satnav that knows how to get from London to Paris. These are all examples of where the decision making is taken away from the human operator, and designed into the product. Someone has taken what they know to be "the best way to operate", and encoded this into design.


    Sometimes this embedded knowledge is annoying, like the Microsoft Document that thinks it knows better than me where it needs to be filed, and what formatting it should use, but let's not go there.


    There are other ways Knowledge can become embedded. It can be embedded in organisational Structure, for example. There as a time when it was "established knowledge" that a function-based organisation worked best. Then it become "established knowledge" that multidisciplinary teams worked better. Each change in knowledge becomes embedded in a change in the structure of the company. Also project management structures like PRINCE2 can be seen as knowledge embedded into frameworks.

    So what is the implication of recognising this additional form of knowledge?

    Firstly, it leads us to think that writing knowledge down as a process is not necessarily enough to ensure the process is always followed. Maybe we can embed it in a system or design. It's not enough, for example, to write down as a lesson "don't let the driver drive the tanker away, until you are sure the hose is uncoupled" - maybe you need an action, to put a barrier in front of the tanker which will not open until the hose is back in its holder.

    Secondly, the implication is that as knowledge develops, then structures, frameworks and programming may need to develop also. PRINCE2 for example needs (in my opinion) to develop to include recent advances in project-based Knowledge Management.

    Thirdly, it can be easy for this embedded knowledge to become decoupled from the real knowledge that fed it. I was talking with some people a while back, who were describing the programing that had gone into one of their products, that was effectively embedded knowledge, and the people who had programmed it had gone. Nobody now understood the rationale behind the programming. With the tacit knowledge missing, nobody could quality control the embedded knowledge, and say if it was still valid.

    So think about it. maybe your approach to KM in your organisation needs to look beyond the explicit, and look at the embedded knowledge as well.

    Saturday, 18 July 2009


    Knowledge Management Strategies - youtube video


    Here's my latest upload to YouTube - on Knowledge Management Strategies.



    I have uploaded this one to replace the video we have on our Strategies introduction page, since I have found that having any video on your site means you get multiple hits from people harvesting free video files. We got almost 4000 hits in an hour from Algeria, a couple of weeks ago, just downloading mp4 files. That sort of thing can get us close to our monthly transfer limit, so I am increasingly moving these files to Youtube

    Friday, 17 July 2009


    Are you learning to avoid mistakes, or learning to succeed?




    These animals bite!
    Originally uploaded by
    AMagill
    I have been getting some responses back from my Lesson learned survey, and a couple have really surprised me. Both of them were from people I know, who work for major multinationals. One said "I recommend replacing traditional lessons learned processes with a visible learning process which addresses not only actionable preventions to lessons (things gone wrong and corrected) but also learnings (things gone right and valued for sharing and reuse)". The other guy seemed to imply (and I have a phone called booked with him to clarify) that they have "given up on Lessons Learned", and now look only at re-applying successful practices.

    There were two surprises here for me. The first was that both people traditionally associated "Lessons Learned" with "Learning from mistakes and failure". I mean ONLY with learning from mistakes. Then when I though about it a little more, I realised that perhaps, for many organisations, that is correct. Perhaps there is a mindset that "Lesson Learning" means reviewing mistakes and errors only, and never looking at success.

    I have two problems with this!

    Firstly - any system that learns only from mistakes, builds safe processes and products designed to avoid failure. You end up with band-aid processes, held together by protective measures. Now in some cases - areas of product safety, for example - this is a good thing. In other areas, it may drive conservatism and risk avoidance. I would rather have processes designed to replicate success, than processes designed to avoid failure. There's a subtle but important difference in outlook!

    Here's an example for you.

    Imagine a company with a Health and Safety learning and knowledge management system, focused on learning from mistakes, and triggered by HSE incidents. Imagine it has two identical operating plants, A and B. A runs a very safe operation, and has had no safety incidents or near misses in a million man-hours of operating. B has a near miss once a quarter, and an accident every year.

    Where you you think the HSE learning system focuses? It's triggered by incidents, so it focuses in plant B. But Plant A is the one that has the knowledge of "how to run a safe operation"! This knowledge will never be addressed if the learning system learns only from incidents. (We explore this further in our white paper on Knowledge Management in HSE, available on our downloads page).

    Secondly, if learning only analyses mistake and failure, it becomes tarnished as a concept. People don't like it. It's a short step from "let's learn from our failure" to "Witch-hunt". People start talking about "Post-Mortems". The lessons identification exercise becomes a depressing experience. Which it does not have to be.

    So lets look at this differently. Lets learn from success as well as failure. Lets celebrate success. Lets make learning proactive - learning to replicate the best. If the term "lessons learned" is tarnished, lets throw it out and use something else. "Learning from Experience" perhaps.

    Personally I would not advocate going as far as the second guy, and reviewing ONLY success - there can be really valuable lessons from failures as well. Personally I would advocate learning from all projects and all operations - celebrating the successes as something worth replicating, acknowledging the challenges and difficulties as something to learn from and something that never needs happen again. Most projects are a mix of success and failure, and effective lesson-learning implies acknowledging and learning from both.

    Wednesday, 15 July 2009


    Army KM principles



    Don't click on this link just yet! It seems to hang up my computer if you click on it, but a right-click will allow you to download an interesting document from last summer by the United States Army, listing (and illustrating) their 12 Knowledge Management principles. Some of you may have seen this before.

    These principles are

    People and culture

    1. Train and educate knowledge management leaders, managers and champions.

    2. Reward knowledge sharing.

    3. Establish a doctrine of collaboration.

    4. Use every interaction as an opportunity to acquire and share knowledge.

    5. Prevent knowledge loss.


    Process

    6. Protect and secure information and knowledge assets.

    7. Embed knowledge assets (links, podcasts, videos, documents, simulations, wikis and others) in standard business processes and provide access to those who need to know.

    8. Use legal and standard business rules and processes across the enterprise.


    Technology

    9. Use standardized collaborative toolsets.

    10. Use open architectures to permit access and searching across boundaries.

    11. Use a robust search capability to access contextual knowledge and store content for discovery.

    12. Use portals that permit single sign-on and authentication across the global enterprise, including partners.

    An interesting list, and also interesting to see what's missing - nothing there about institutionalising capture and reuse, nothing there about accountabilities and ownership for knowledge, nothing there about linking KM to the primary issues; presumably because these three are all now firmly embedded in the US Army structure and ethos. Nothing about "learning before, during and after" - in fact nothing there about the processes of KM itself. I would not use this list as a generic list - it must work for the US Army, but I suggest that it would need modification to be used elsewhere.

    Also that's a slightly different interpretation of People/Process/Technology than the one we use (click on 'model 2' on this page)

    Tuesday, 14 July 2009


    Lessons Learned Survey



    Dear blog readers

    I have been commissioned to write a book entitled "The Lessons Learned Handbook: a Practical Knowledge-Based Approach to Learning from Experience" which I hope to complete by the end of the year.

    To help me gain a little bit more of a view of the state of lesson-learning in organisations, I have devised a questionnaire which I would be very grateful if you could fill in. If you work in an organisation in the public or private sector, please answer on behalf of your organisation. If you consult, feel free to answer on behalf of a client, but please make it clear that's what you are doing, in the answer to question 1!

    The survey only has 10 questions, and will take no more than 10 minutes, unless you have lots you want to share.

    I will share the results via my blog, in a few weeks time

    Click Here to take the survey

    Thanks in advance


    KM in projects - optional, or mandated?


    There is a debate going on in comments to a post on Arjun Thomas' blog about whether knowledge management processes such as the After Action review should be made mandated in projects. Charles Parry suggests that

    "unless learning and improvement is explicitly built into work processes so as to essentially be unavoidable, the collection and sharing of knowledge is a moot point. I know that’s harsh, but its pragmatic. It takes time, so if it’s not important enough to build in time for, it just doesn’t happen".


    Arjun, on the other hand, worries that this will lead to a box-ticking mentality "as a lot of people will end up doing this for the sake of “doing” it"

    I have to say, I agree with Charles. Even if people end up doing things for the sake of doing them, at least they get done! And providing you quality control the processes, then useful results will emerge. What in fact you find over time, is that at first people do these activities because they are required to, but then they pick up on the value, and begin to do them because the believe in them. That's if you ensure the processes deliver value, of course, which means closing the loop from the after actions reviews, acting on the input from the peer assists, and delivering the actions from the Knowledge Management plan. In BP in the 90s, one of the first Knowledge Management processes to be developed and deployed was the Peer Assist, and this came as a mandate from senior management that no project would receive sanction unless it demonstrated that it had (through one of these meetings) tapped into the knowledge from round the world. First people saw this as a box to be ticked, but you don't have to hold more than a couple peer assists to really see the value. the same is true of after action reviews, provided the learning loop is closed.

    If these processes are not mandated and unavoidable, then they are effectively optional. And which project has time for optional activity? They are stretched enough delivering what's vital, without worrying about what's optional. So if we believe in the value of knowledge management, and we can demonstrate that value to senior management, then our request to senior management must be to embed a core set of Knowledge Management processes into the project management framework, to make them a clear expectation for projects and a clear accountability for the project manager, and then to track that they get done (and get done well). And if senior management grant this request, then our side of the deal, as knowledge management professionals, is to ensure that these processes deliver value to the projects - considerably more value than the time they took.

    I know this sounds tough, but it works.

    Saturday, 11 July 2009


    Knowledge Management - one among equals, or unique?




    This post from Art Schlussel reminded me of a discussion I had in Stockholm late last year, which was, I think, indicative of two opposing views of KM. Art's blog post brought this back to mind.

    My view, and I think Art's view, is that Knowledge Management is one management discipline among many. It represents a way of managing work, paying due attention to the value and effect of an intangible (namely, knowledge). And it's not the only management discipline which deals with intangibles. Risk management, Quality management, customer relationship management, brand management, reputation management, security management, safety management - all deal with intangibles. For me, the closest of these to KM is risk management. Knowledge and risk are allied - you reduce risk through application of knowledge. Knowledge of risks and how to handle them is some of the most valuable operational knowledge.

    So, in Stockholm, I presented this view of KM as one of many management disciplines. I was speaking in the context of project management, and I suggested that KM could be added to the list of management subcomponents of project management, and therefore added the accountability of the project manager. But after the talk, a young man came to see me and argued very strongly that I was completely wrong, and that knowledge management is unique, and cannot be bundled with other disciplines, as it is quite unlike anything else.

    I suppose in a way he is correct - there are some unique elements in KM - but in another way I would rather not treat KM as a standalone. The great value of treating KM as "one among equals" - as another component of good management discipline along wirh risk management, safety management and the others - is that you can then place it within the same governance framework as you do the other disciplines. You can position it in the same structures and expectations. You can review it using the same review processes (the stage reviews of the project management framework, for example). In other words, you can embed it easily within "normal work".

    Maybe that's a pragmatists approach rather than a theorists or idealists approach, but I would rather go for something that works any day! As Art argues in his blog, sometimes KM has to get over it's inflated view of itself. He says

    There is no doubt in my mind that the impact of KM on an organization can be
    huge. Vast amounts of time, money, and resources can be saved. New ideas and
    innovations can propel an organization faster then ever before. Lives can be
    saved by sharing critical knowledge to the right group at the right time. We
    know this, but this can only happen if an organization can see KM for what it
    really is. If they can see the value of KM, not the hype or the spin, and if KM
    practices are embedded in their way of doing business, not layered on top of
    doing business.


    I agree completely, and would stand by my contention that KM is one discipline among many, and needs to find its place "embedded in the way of doing business". But I would be interested in your opinions!

    Wednesday, 8 July 2009


    Knowledge Management in the oil sector



    Gas Station Pumps
    Originally uploaded by srqpix
    My colleague Tom shared a story with me a while back, which I have been pondering on recently. He told me

    "I was down in New Zealand talking to a company about knowledge management and the relevance to their service organisation. The meeting organiser was summarising the morning's proceedings and I was sipping my coffee and wondering how we would get back to the airport when the question came. "Why are the oil companies so far ahead in this knowledge management stuff?" Now to be very truthful it wasn't a question I had actually considered before".


    You have to wonder of course whether the questioners are right, and whether the oil companies really are so far ahead, but it does seem to be true that knowledge management has found truly fertile ground in the oil and gas industry. We can almost guarantee two or three oil majors in the MAKE awards this year. So why is that?

    I think there are a whole number of factors here. Firstly the oil business is a global business, and the elements of the business tend to be the same wherever you go. So an oil platform on the Northwest shelf of Australia is not that different from an oil platform in the North Sea, and a refinery in Singapore is not that different from a refinery in Texas. The challenges that the businesses face are therefore common challenges, and solutions need to be shared and applied around the globe. Knowledge Management can be a real help.

    Secondly the oil business is a highly competitive business. There is no true differentiation in product - the tank of petrol that you buy from Texaco is essentially no different from the tank of petrol that you buy from Esso, and the companies are not competing on product quality. And they are not really competing on technology either. Drilling rigs are leased from contractors, refineries are much the same the world over, and so are gas stations. Instead the competition is all about the application of technology, and the use of knowledge.

    Then there is a very strong performance drive, and clear metrics. You know when you do a good job, because it is measurable. You can measure how many feet you drilled that day, or how many barrels you produced that month, or how long it took to get the retail station built. And if some other guy did it better and faster, then there’s a real incentive to learn from him.



    Hence the focus on KM from the oil companies.

    The companies use a variety of approaches. The Community of Practice approach is common, and communities are very active in Conoco Philips, Repsol, Chevron Texaco etc. These are very popular and very effective in the exploration end of the business, in knowledge-intensive areas such as drilling, geology and geophysics.

    Another powerful aid to the development of communities is setting up a "people index" or Yellow Pages system. Texaco was a leader in implementing their PeopleNet system, and BP with the Connect system. Chris Collison described Connect as "a new way to access BP's most valuable reservoir -- one million man-years of experience".

    Lessons Learned systems are crucial for delivering performance improvement in the risky and expensive world of the international and offshore megaprojects, and these are applied with a rigor seen in few other places.

    Discussion forums are vital for connecting people in communities of practice, and these can usefully be supplemented by real-time collaboration technologies. The story of the BP "virtual teamwork" project shows how desktop videoconferencing was used to bring global knowledge and skilled to bear on local problems.

    User-populated Knowledge Bases are also proving to be valuable tools here. Schlumberger has implemented a portal strategy embodied in their HUB service on the company Intranet. They use this system both as a virtual workspace for participating teams, as well as a discussion and document forum for their communities of practice. Halliburton has something similar which they say cost them $17.1 million and delivered back $81.9 million in 3.5 years. Shell are developing the Shell Wiki, which is linked to the Shell University, and is rapidly growing to become the one-stop shop for reference material.

    The major benefit that knowledge management has given oil companies so far is "protecting the base", which is oil company jargon for maintaining and improving the core business. This focus is on reducing capital and operating costs, increasing utilisation and up time, and improving market positioning. Knowledge is captured and shared about topics such as increasing success in finding oil fields, reducing maintenance down-time in oil refineries, and increasing the speed of build of gas stations. But as oil runs out, and focus turns to renewables, then the oil majors are going to have to turn their KM spotlight on developing new knowledge, on innovation, and on rapid learning of new skills and new business models. That’s when the winners and losers will be determined by their learning speed and by the efficiency of their knowledge management. That's when we will see whether the oil sector really has staked their future on KM.


    Choosing your web 2.0 technology from the bottom up



    Sweet shop
    Originally uploaded by pedrosimoes7
    There's a lot of interesting and exciting technology out there at the moment, and it's very easy to approach it like a "kid in a sweetshop" - "lets get blogs, lets get wikis, lets get facebook, lets get twitter, lets get youtube - they are very popular on the web, so these social technologies must add value to business".

    I would much rather we took a step back, and asked "what do we need to be able to do in order to seek, share and re-use knowledge, and what technology should we choose to enable and encourage this?"

    In one company I was consulting with recently, we looked at the KM functionality that was required and decided that was needed was

    1. The ability to find people, based on what they knew ("who knows about legal frameworks in Brazil?")
    2. The ability to ask questions of a community of practice ("can anyone out there advise me on this issue?")
    3. The ability for a community (or for SMEs in a community) to create and maintain knowledge products such as guidelines, tips and hints, processes and procedures
    4. The ability to find this community knowledge, quickly and easily
    5. The ability to log new lessons and learnings, for validation and incorporation into the knowledge products (and to be able to track this, to make sure the lessons cycle is being closed)
    6. The ability for an individual project to create, maintain and find its own project-specific knowledge products
    7. The ability for an individual project to log new lessons, for incorporation into the project-specific knowledge products (and to be able to track this)

    We ended up with a toolkit comprising yellow pages, shared learning systems at project and community scale, knowledge libraries at project and community scale, and community discussion forums.

    With hindsight, I would now add

    8. the ability for a community or a community leader to broadcast new knowledge

    You could address these functionality needs in a number of ways

    1. needs a yellow pages system, and one based on a good taxonomy. The free-form approaches of MySpace and FaceBook are designed for easy publishing and for serendipitous encounters, but not for easy search for specific knowledge-holders

    2. needs some bulletin-board or discussion functionality. Facebook and Linked-In provide this, as do products such as Sitescape and SigmaConnect (used by Shell and BP respectively). Ideally there should be cross-links between 1 and 2, and the yellow pages should also provide and index of community membership

    3. needs a wiki. The shell wiki is an excellent example of this. Again, the structure of the wiki needs to match the structure of the communities

    4. means good search.

    5. is a combination of lessons database and action tracker. There are some excellent examples of this in the Military, used to track lessons right through to implementation. This is not web 2.0, but its a crucial component in a KM system

    6. is a good information management system for the projects, plus items such as project blogs. SharePoint could work well at this level

    7. is a lessons learned database like 5, but on a project scale. It could be the same software, but you dont want to clog up the corporate lessons system with project-scale lessons.

    8 is either community blogs, or good tagging and subscription of new knowledge products, or most probably both.

    I haven't included twitter. There was no need in this company for any of the functionality twitter could provide. I could imagine other companies (sales companies for example) where it would have a very valuable place, but I am not going to push technology in where there is no need for it.

    (Which reminds me of a conversation I had in Dubrovnik last year regarding new technology, and someone said "You could use Twitter on an oil rig for example - say you were running a perforating gun into the hole and you wanted radio silence for 10 minutes so as not to set off the charges accidentally when people were nearby - you could send out a twitter alert and notify everyone". Well, you could, but if you wanted to notify everyone, there is a perfectly good existing technology - its called a Tannoy system, and for the required purpose, its actually much more effective than Twitter. Sometimes the old tools work the best)

    Tuesday, 7 July 2009


    Knowledge Management Implementation


    In the video below I describe a staged approach to Knowledge Management Implementation, based on change management principles and a stage-gate Project Management approach. We have used this framework as a basis for all our implementation activity, and believe it to be fully robust. More details here

    Monday, 6 July 2009


    Tacit or explicit transfer - which works the best? Another great exercise


    Following on the theme of KM exercises and games, I was running a Masterclass today on Knowledge Transfer, and we did a little exercise, with some interesting results. The exercise went as follows

    Three teams were given an identical set of 10 Lego pieces (plus a baseboard). For one team, the pieces were already made up into a structure, which we said was the Lego answer to the iPhone - the LPhone (the original LPhone is in the centre of the picture above). This team stayed in the main room, with this original structure in front of them, but hidden from the others behind a table.

    The second team stayed in the main room as well, with their construction hidden behind another table, and were able to converse with the first team (though neither team could see the others' construction). The first team were able to talk the second team through how to build the LPhone, through dialogue and tacit transfer. The second team could ask questions to clarify the instruction they received. In the picture above, you can see the first team's original LPhone in the center, and the second team's "tacit knowledge transfer" version on the left. They are identical.

    The third team were in a separate room. They were not able to talk with either of the other teams. Knowledge was transferred to them, from the first team, in a series of written notes. Knowledge transfer was therefore entirely Explicit - entirely through captured, written knowledge. Not only did the third team take more than twice as long to build their LPhone, the result (on the right of the picture above) was significantly different from the original in many ways.

    SO why did the tacit transfer result in a faster, more effective knowledge transfer? When we debriefed the exercise we identified two success factors. Firstly the two teams (teams one and two) very quickly negotiated a common language to describe the lego pieces, and the orientation of the pieces (left/right, up/down, landscape/portrait). Secondly, whenever there was an inconsistency or ambiguity in the instructions, this could be resolved through questioning and feedback.

    And why did the explicit transfer result in a slower, less effective knowledge transfer? Firstly there was no way to resolve any inconsistencies and ambiguities, so the receiving team (team three) had to use their best judgment (and one ambiguity early on had a knock-on effect on the design). Secondly, the order of the steps was not clear, as the notes which were sent through from the first team were not numbered. Finally there was no agreed language concerning orientation, or concerning the description of the lego pieces, which led to some errors.

    SO what did we conclude? We concluded that knowledge should not be transferred only in written form, if tacit transfer (such as Peer Assist) is possible, though every participant reported that for their company, the default expectation seemed to be to capture the knowledge, rather than transferring it through dialogue. Secondly we concluded that there needed to be very good quality control on any explicit captured knowledge, to resolve any errors or ambiguities which might result in difficulties when applying this knowledge later.

    This was a simple exercise, but with some very graphic learning points. It is one I recommend.

    Sunday, 5 July 2009


    A KM strategy for Ecopetrol



    An excellent story here from Nancy Dixon, on a KM strategy session for Ecopetrol, the Colombian state oil company.

    What I really like about this story, is the section where Nancy says

    The morning of day two was convergent - a search for useable ideas, common ground, and limiting the many options they had heard the day before. These were multiple small group meetings using the world café format and focused around the question “What knowledge do we need at Ecopetrol that we don’t have?” The room was set up with 25 tables with a facilitator at each table with participants. There were several rounds of discussion with people moving from table to table to talk with a new set of people about their ideas. Ecopetrol’s president, Javier Gutie´rrez, participated in the small group discussions.

    The process is impressive, the involvement of the president is even more so, and it was crucial for them to start from the question "What Knowledge?"

    That's a key question for any company, and for me, one of the most important questions you can ask in order to develop an effective KM strategy.


    Bird Island article available for download




    I have blogged here previously about the Bird island exercise (see here and here).

    You can now download an article about the exercise, from the publications page of the Knoco website. You will find our other published articles there, many of them available for download; please contact us if you would like any reprints of the others.

    We hope you enjoy the article - it contains some evidence and statistics that I believe conclusively demonstrate value delivery through application of a simple KM system

    Friday, 3 July 2009


    Learn from mistakes, or learn from success?



    Trial and error, or trial and success? Which is the better learning mechanism?

    A thought provoking piece here, makes the argument that people learn much better from their mistakes, as a result of the emotional charge and the emotional scars that failure brings.
    I know this is true on an individual level, but do we really have to fail before we can learn?

    I believe that on a corporate level, or as a society, we collectively make the biggest learning steps when we finally succeed.

    Think of Edison and his light filament; when did he do the most learning? When he tried each of the 99 options that didn’t work, or when he found the one that did? Now you can argue that he learned from both, but now let’s look at transferring that knowledge. If you were a light bulb maker, which of these two statements would be of most value to you?

    1. You can’t make a light bulb filament out of cat hair
    2. You can make a
    light bulb filament out of tungsten

    It is learning from the successes that are most valuable for others.

    Now let’s look at KM in an organisation, and how an organisation learns. The ideal for an organisation is that it learns from the *minimum of mistakes*. We know that it is human nature to learn best from mistakes, but we don’t want to be at the mercy of human nature*. We don’t want people to have to screw up in order to learn. We don’t want mistakes and screw ups if we can possibly avoid it, because mistakes and screwups can cost money, they can cost lives (in certain cases), and they can cost careers if they are big enough. I know that people find a mistake a powerful learning experience, but KM in organisations must aim at countering this, and giving people access to learning from other’s mistakes. (In fact it is notable that where mistakes are most serious, as in the Military, the greatest attention is given to systematic learning and KM)

    Somehow we need to make that learning as powerful as possible. We don’t just want to say “do X”, we want to say “Do X, because you can get into real trouble if you don’t”. Or even “Do X – I didn’t, and let me tell you what happened”. Ultimately, if X is definitely the right thing to do, we might want to say “Do X. That’s the company way. If you work here, X is what you do”

    Basically, we cannot afford to let people learn from mistakes when mistakes are avoidable. The first time a mistake is made, it can be a mistake only in hindsight – at the time it might have been the best option based on the knowledge available at the time. It may have been a justifiable risk. The second time that the same mistake is made, is a failure of KM. The new knowledge available should have warned of the probability of the mistake. The hindsight from the first mistake should become foresight to avoid the second.

    An organisation should learn from its mistakes, but only once! The best approach is to learn once from mistakes, and many times from success.

    *in fact most management systems are attempts to guard against human nature.

    Thursday, 2 July 2009


    We only learn when we don’t know what to do



    Nobody will look for knowledge from others, if they think they already know what to do.

    Instead they will just rely on their own knowledge (after all – they know its provenance, and they trust it more than they trust anyone else’s knowledge.
    This means that the best way to promote learning and re-application of knowledge across an organisation, is to give people challenges they don't know how to meet. To push them out of the comfort zone of “I know how to do this”, into a zone of “this is tough – I’d better see what knowledge is out there that can help me”. Then they will look for knowledge from others, to help them solve the problem.

    It's a question of receptivity. You can't transfer knowledge unless the recipient is receptive. To be receptive, they need to have feel a need to learn learning. They need to feel that they need to know. If they feel they don't need to know, they won't be receptive. (There's an ancient greek quote that expresses this better than I can, but I can't locate it at the moment).

    John Browne (the BP CEO in the 90s and early 00s) did just this in BP. He expected every project to deliver better than the previous project (often radically better), and his budget allocations and performance targets reflected this. He forced continuous improvement in delivery and cost, and the only way to continuously improve was to continuously learn. For the project manager, these "stretch goals" were seriously uncomfortable ("How the h*** does he expect me to cut the budget by another 20%?”) and it pushed them to seek advice, look for the best of the best, and build upon the entire knowledge base of the organisation. As a result, these stretch targets were drivers of innovation, knowledge management and continuous improvement.

    Ford did this as well, in the days of the Ford Best practice Replication System. Through applying continuously decreasing operating budgets, they forced their plants into a situation where they had to learn in order to deliver.

    In both cases, they strong delivery push from management was coupled with the systems, processes, accountabilities and technologies that made knowledge management possible. Just increasing the pressure without providing systems for learning would not have worked – it would have added stress to the organisation. Increasing the pressure while also providing the learning systems, on the other hand, provided the incentives for knowledge to flow around the system to where it was needed (driven by “demand Pull”), and fuelled continuous performance increase over a number of years.

    So remember, if you want to promote a knowledge seeking culture in your company (and a knowledge seeking culture is a far better driver of KM than a knowledge sharing culture), then you and your senior managers need to push people out of the comfort zone where they can rely on what they already know.

    Wednesday, 1 July 2009


    KM and the first ascent of Everest





    Everest and Lhotse
    Originally uploaded by MacCookie
    Here's an excellent blog post, explaining how the successful first ascent of Everest was only possible through a program of knowledge acquisition over many years, and knowledge transfer between international climbing teams.

    He includes this quote from the team leader, John Hunt, which explains the attitude to knowledge sharing that made the ascent possible


    The mission we undertook was not, in our eyes, in the nature of some competition on a giant scale in which we vied to outdo the efforts of previous expeditions, dramatic and popular as such a concept might be. Indeed, prolonged attempts to climb a difficult mountain are, or should be, essentially different from those of a competitive sport. A possible analogy, however, might be that of a relay race, in which each member of a team of runners hands the baton to the next at the end of his allotted span, until the race is finally run. The Swiss last year received that baton of knowledge from the latest in the long chain of British climbers and they in turn, after running a brilliant lap, passed it on to us. We chanced to be the last runners in this particular race, but we might well not have succeeded in finishing, in which case we would have handed on our knowledge to our French comrades who were preparing to take up the challenge.


    The idea of a baton race of knowledge is something we can apply in our own organisations, to our own projects and programs.

    Blog Archive