Knowledge with shelf life - Inside Knowledge

Feature

posted 1 Jul 1999 in Volume 2 Issue 10

Knowledge with shelf-life

Every company should automatically learn from mistakes and past experiences, but what happens when memories fade, employees leave the company or the knowledge passes its sell-by-date through being badly recorded or not even recorded at all? The value of retrospect cannot be underestimated, and in this article, Nick Milton shows how BP Amoco is mining the past for investment in the future. Nuggets of knowledge are recorded and stored in a knowledge bank in a practical format. The knowledge assets retain their shelf-life as new people re-approach similar subjects and add their new insights and experiences.

Knowledge Management (KM) involves making maximum business use of what your organisation knows, so that every decision can be made in the light of the full knowledge base of the company. This means that everyone, everywhere, must be able to access not only the information and data they need, but also they must be able to tap into experience and expertise from other people, whether those people are available in person or not. This needs to be done systematically and routinely; only by being systematic, and by embedding knowledge work in the routine of the organisation can you claim you are truly managing knowledge. The ideal end result of systematic routine Knowledge Management - the vision to aim for - is that mistakes are never repeated, blind alleys never re-explored, wheels never reinvented, and that every decision is made in the light of the full knowledge of the company. This is the end-state of collective intelligence, towards which KM systems strive.

This paper describes one step towards this goal; an advance we made in BP Amoco towards enabling the storage and far transfer of knowledge by use of 'knowledge assets'. It describes some of the principles involved, and is illustrated by a case history of successful knowledge transfer.

So what do you need to know?

It is pretty obvious that it will take time and effort to reach the ideal end-state described above, and it is also pretty obvious that if we try and apply KM to absolutely everything we do, down to the very smallest decisions, then we will exhaust ourselves. We don't need to tap into the collective intelligence of the organisation every time we make a jug of coffee, or every time we order paper clips. KM, like any other organisational process, needs to be aimed towards where it can have the greatest effect. KM needs to have a purpose, it needs to be aligned with the business strategy, and it needs to be focused. Primarily it needs to be focused on knowledge issues - i.e. business issues where the capture, development, retention or application of knowledge is critical to business success.

In BP Amoco, the major focus of KM to date has been on operational efficiency. By applying a well-developed and road-tested process of KM to key aspects of the business, such as drilling wells, building service stations or shutting down refineries for maintenance, we have been able to cut costs, reduce down-time, increase construction speed, reduce accidents and decrease environmental impact. Much of our activity is based around units of work such as projects or tasks. A service station build, a well or a refinery shutdown can be considered a 'project'. A recognition of the project nature of our business set the tone for the BP Knowledge Management initiative, and was stressed by Sir John Browne as follows: 'Most activities or tasks are not onetime events. Whether it's drilling a well or conducting a transaction at a service station, we do the same things repeatedly. Our philosophy is fairly simple: Every time we do something again, we should do it better than the last time'. (Prokesh, 1997).

The KM process we apply is entirely straightforward, and involves using simple but incredibly effective processes to learn before, during and after each project or each 'chunk of activity'. At the start of the project, the team calls a 'Peer Assist' to import knowledge from others, and from past projects. During the project, regular After Action reviews are held, to make knowledge conscious, and to keep it current. At the end of the project, a 'Retrospect' enables the team to make conscious, capture and codify their knowledge, for use by future teams working similar projects. The knowledge than passes through a validation step with the community of practice, before being stored in the corporate knowledge bank. The future team can make a withdrawal of knowledge from the knowledge bank, and bring this into their 'peer assist' process for the future project. Thus the loop is closed, and the future team can 'do it better than the last time'.

Transferring knowledge through time and space

However there is a key question here - what is the nature of the knowledge bank, and how is knowledge best stored in the bank? That question can be answered in three ways, depending on how the knowledge needs to be transferred through time and space.

In some cases the projects run one after the other in a single location. Here, knowledge needs to be transferred through time, but not space. For example, in BP's Houston office a series of wells was drilled in very deep water - a situation that requires specialist knowledge and experience. Because these wells are drilled from a drilling rig that is leased at high day rates, there is tremendous value to the company in drilling the wells as quickly as possible, while still fulfilling the well objectives. For each well, the team needs to learn as much as possible from the previous well, in order that they may drill faster, more safely, and more effectively. In this case, the 'retrospect' for each well could be followed immediately by a planning session for the next well - 'learning after' leading straight into 'learning before'. The increase in efficiency led to a saving of between $10 - $14 million per well. The knowledge bank in this case comprised the well plans, each of which represented the current state of knowledge for drilling these deep water wells. We call this sort of knowledge transfer (from one project to the next at the same location) serial knowledge transfer.

Another example is where the same sort of projects are running at the same time, all over the world. Here we need some sort of synchronous knowledge transfer, so people can learn from each other in real-time. An example from BP would be the projects involving construction of 3D computer models of underground oil and gas fields. These are highly complex technical projects, which have the potential to consume a lot of time. In this case, the synchronous transfer is facilitated by a very effective community of practice, supported by a communication infrastructure and a live on-line knowledge base.

The third case, which will form the basis for the rest of this article, is to consider projects that happen sporadically in time and space. They are a series of one-offs, which happen at intervals in different places. They might be projects like constructing a pipeline over mountains, or entering a new retail market, or acquiring a new refinery. These are projects that happen once at any one location, and are sufficiently unusual that you don't have several happening at once. Here knowledge transfer is crucial, as each project is a new and unusual event for the project team, and there is tremendous risk of reinventing the wheel (in fact the traditional default is to re-invent). And at the same time, knowledge transfer is a real challenge, as knowledge has to be transferred through time and through space. Knowledge needs to be captured from a project team, and packaged and stored so that an unknown team, at an unknown location, at some time in the future, can access it, understand it, relate to it, use it, and benefit from it. This sort of Far Transfer of knowledge is difficult, but possible. What it needs is some way of giving the knowledge a decent shelf-life.

Speaking to the unknown user

Before we move onto the ways of packaging knowledge, it is worth confronting one of the biggest challenges that faces knowledge management, and that is the challenge of awareness, or consciousness. Knowledge is derived from action and experience, but most of it remains unconscious. We learn, we are able to do things better, but we are often not aware of what we have learnt. We do not know what we know. The tools and techniques we have developed and applied in BP Amoco for capturing knowledge are specifically designed to get at the unconscious knowledge. By applying these techniques, we can populate the knowledge banks with quality knowledge. We do not rely on people populating the knowledge banks themselves, as experience has shown us that you end up only with the superficial knowledge, never the real deep knowledge - never the voice of experience.

However, the other side of the coin is that the customer for the knowledge, the future project leader, is unaware of what she needs to know. She does not know (or is not aware) what she does not know. You cannot rely on her interrogating a database to find the knowledge she needs, when she is blissfully unaware of what she needs. She could not search for it, as she does not know what to search for. The knowledge she needs has to be presented to her in a packaged form, so she can learn what she needs to know. The way in which knowledge is stored in the knowledge bank is crucial. If it is not customer focused - if it does not give the future knowledge user what you are sure she needs to know, rather than what she thinks she wants to know - then the real knowledge does not get transferred, and so does not get applied.

Models for a knowledge bank

In the BP KM team, our concept of the structure of the knowledge bank evolved through time, and through a process of trial and error. I shall describe three knowledge bank models, and illustrate them with the analogy of going to the shops to get the ingredients for a pizza. Imagine 'going to the shops so we can have pizza for supper' as an analogy for 'going to the knowledge bank so I can find knowledge to help my project'.

The first knowledge bank model we experimented with, I shall call the 'Teenager's bedroom' model. This is a model where you dump everything in an unstructured bank and rely on a good search engine, and/or good metadata labelling to be able to find it again. It is like my son's bedroom; he knows where everything is - it is all on the floor! He can search through the pile of stuff and find what he needs. In the shopping analogy, this is like our grandparents going to an old-fashioned grocers store, with sacks all round the walls, and hams and salami hanging from the ceiling. If you want the ingredients for a pizza, you ask the grocer (the 'search engine') and he finds them for you. You go home and make the pizza. Those of us who have tried findings things on the Internet know how frustrating this model can be, and you will never find the things that you don't know to ask for - the things you don't know you need to know.

The second knowledge bank model is one of storing the knowledge in some sort of framework. However it is hard to create a framework which has longevity, and which can be understood by all users. In the shopping analogy, this is like the supermarkets our parents went to. Everything is on shelves, and when you get to know the supermarket, you know where to find the flour, the olive oil, the canned tomatoes and the mozzarella. The drawbacks of this model are that the onus is still on the user, the shopper, to find the ingredients. If you don't know your way around the shop, or the knowledge bank, it is easy to become frustrated and if the items are moved form one shelf to another, you need to search the whole store again. People generally will not look for knowledge for very long, and if they don't find it quickly they will reinvent it. And once again, you never find the things you don't look for.

The third model is one where the knowledge is pre-packed for the benefit of the end user. The knowledge bank then contains a whole set of bundled and packaged units of knowledge; units that in BP Amoco we call 'Knowledge Assets'. Each knowledge asset is designed to give the 'knowledge customer' everything they need to be fully briefed before their project. In the shopping analogy, this is like you or I shopping for a pizza for supper. We will go to the supermarket, head for the freezer counter, and pick out a frozen pizza already prepared. Or perhaps we will place an order by phone and have a pizza delivered to our front door. We have found this third model (where the knowledge bank is full of pre-packaged knowledge) to be far and away the most effective. It places the onus on the creators of the knowledge to do the packaging (and the Retrospect process leads naturally to packaged knowledge) so the knowledge user is given what they need to know, whether they are aware of that need or not.

Knowledge Assets - the 'Frozen Pizzas of knowledge'

Knowledge Assets, as the packaged components of the BP Amoco knowledge bank are becoming a proven mechanism for deriving sustainable long-term benefit from BP's experience. They provide a focal point where teams across the federation can pool their knowledge for local and global gain. The context and histories that make up our Knowledge Assets provide a common framework to facilitate re-use of knowledge.

The contents of a Knowledge Asset are derived by asking the question 'what does the knowledge customer need?' Firstly they will need some sort of advice, that will help them with their project. They need help and guidance in making decisions, and they would appreciate this being structured in a helpful way (such as a checklist for the project, in chronological order). Secondly they need some context. They need to know how much they can trust this material, and they need to know what it is based on. They need access to the stories, quotes, and background history that will make it 'come alive' for them. Thirdly they need a mechanism to follow things up, whether this is contacting the people involved, or reading background materials.

So the BP Amoco Knowledge Assets contain:

Guidelines or checklists, representing the current understanding of best practice

Illustrations from past history; stories or quotes to bring colour and engagement to the guidelines

Names of the people who hold the experience, and who can provide additional context and insight

Artefacts and records of relevance, such as project plans, examples of solutions, photographs, video clips, etc.

These Knowledge Assets are compiled and distilled from the experiences of many projects, and so tell the stories, and give the advice with multiple voices. This is important. Nancy Dixon (in press)¹, who studied the use of BP Knowledge Assets for Far Transfer, concluded 'what is necessary for Far Transfer is some form of interpretation that blends many voices without losing them. The multiple inputs are used to create a synthesis of knowledge but also to illustrate, amplify, verify and continually challenge it.'

An example of how a Knowledge Asset is extremely effective for Far Transfer, and how a Knowledge Asset can go through many cycles of use is provided by the Asset on Business Restructuring. This was one we prepared for BP Colombia in 1997, which has proven its value in repeated re-use across the globe.

Business Restructuring in Colombia

Oil fields, as business units within an exploration/production company go through a life cycle. When oil is discovered in an area, a phase of rapid business growth and investment follows. The area is explored, and the infrastructure (platforms, pipelines, offices) is constructed. Once the field is on stream, the focus shifts to efficient production, maximising flow rates and good maintenance of the asset. Once the field begins to decline, the focus is on extending field life while still remaining profitable. Finally the field will be shut in when no more production is possible. The office reorganisations that naturally accompany these life cycle transitions are primary candidates for far transfer of knowledge - they are intermittent, and occur globally.

At the end of 1997, BP Exploration Colombia was facing a transition point in the life cycle. In addition, the rapid fall in global oil price was forcing a critical appraisal of the cost structure of the business unit. It was obvious that a major reorganisation was needed - to simplify the organisation, reduce complexity and cut costs. As always, such a reorganisation carries risk. Uncertainty can be a major distraction to employees. There is increased danger of inefficiencies, poor decisions, accidents and environmental damage. A small team was set up to deliver the restructuring, headed by a Scot called Mike Davidson. One of the very first things Mike did was call the Knowledge Management team, to ask 'What does BP know about Business restructuring?' We promised to compile a knowledge asset for him.

At that time there was no compiled knowledge on restructuring available in BP, although there were a number of paper reports on various shelves around the globe. I started calling people, collecting past reports, and conducting interviews. Pretty soon I had compiled a knowledge asset for Mike, which I continued to refine over the next few weeks. Mike and his team made significant use of this in the planning stages. He said:

'Getting that collective experience was very valuable, in that it allowed us to consider our decisions, and in the end we tried to pick up elements from the experience that had happened across the company. We very consciously used that experience in terms of our design - how we would go about things in Colombia. There is great value in having the collected experience of the company gathered in this rather simple way, so it is accessible to people before we embark on tasks such as this, which fundamentally change the lives of many of our employees'.

Mike's team was so pleased with the smooth running of their restructuring programme, that they offered to help update the knowledge asset. I flew down to Bogota for three days of intensive knowledge capture, and was able to collect a massive amount of addition learning, resulting in a major upgrade of the Knowledge Asset. Not only had the Asset added value to Colombia, Colombia had also added value to the Knowledge Asset.

Transfer to Venezuela

The next business unit to face a life-cycle transition was Venezuela in 1998. They also set up a team to re-organise the business, giving themselves just seven weeks to complete the transition to the new organisation. The team realised that meant they would not have time to "reinvent the wheel". They would have to learn what they could from Colombia, so they began calling their contacts there. They found this way of accessing frustrating. People were often away or distracted, or were unable to recall the details of the Colombia project from a few months previously. However, fairly soon someone gave them a link to the Knowledge Asset, and this gave them access to a completely new level of knowledge.

To start with, they used the overview section of the Asset to guide their thinking, and to give them specific names of people to call for detailed advice. They gained a 'big picture' of the Colombian project, the elements involved, and the major lessons they had learned, all of which helped them start off on the right track. Later, as they began to work their project in detail, they were able to make use of the examples and specifics, most of which were indexed in the knowledge asset, but lay on the Colombia website. This level of detail was a great time saver for Venezuela.

According to Nancy Dixon, who made a study of the knowledge transfer to Venezuela, 'the most benefit often came from when the Knowledge Asset outlined the several options that the Colombia team had considered, and explained the reasons why Colombia chose one over another. In fact, as the Venezuela team put their own plan together, they often chose a different option than Colombia had selected. It was not so much what Colombia did, but why they did it, that informed the thinking of the Venezuela team. The Knowledge Asset often provides differing opinions on a subject, which the team found a much richer source of information that a more typical end-of-project report that only provides the agreed upon final solution.' (Dixon, in press)

Packaging is a skilled job

I had created the Knowledge Asset for Colombia, which they had used, found valuable, and updated. It was passed to Venezuela, who had also used it, and I was expecting that Venezuela would also update the knowledge asset with their own experiences. However time went by, and they never seemed to be getting round to it. According to Nancy Dixon:

'The Venezuela change team found this Knowledge Asset of considerable help. They recognized that without it they might well have not met the ambitious time line they had been given. Yet, when I asked how the Venezuela team was planning to add to the Knowledge Asset, the team leader said he was unsure as to whether they even would. Their own experience had led them to become conscious of the great difference between the kind of end-of-project report they knew how to write, and the more useful and sophisticated Knowledge Asset of which they had just made use. Without considerable assistance from someone more experienced in knowledge construction than themselves, they feared that any report they constructed would be of little use to others. Their hesitancy could not be attributed to a desire to hoard the knowledge they had gained, nor to an unwillingness to share. Rather their reluctance came from their heightened awareness of the level of skill required to construct useful knowledge for others'.

For me, this came as a surprise. I had been collecting, compiling and packaging knowledge for so long that I had become unaware of the level of skill involved; a level that others did not possess. I was unaware of my own level of knowledge - I did not know just how much I knew! Further experience has reinforced this opinion; that the collection and packaging of knowledge, if it is to be done well and effectively is a skilled task. Training is needed, skills need to be acquired, processes and techniques learned, time invested. However the success of the Knowledge Asset in the far transfer of knowledge, as part of the BP KM process demonstrated just how important it is to acquire the skills, develop the processes and invest the time. Two knowledge managers from the Venezuelan office have now gone through training in knowledge capture and packaging, and the creation of knowledge assets, so the skills are now in place in that part of the business.

The current state of Knowledge Assets

The Knowledge Asset on business restructuring has now been applied at several more locations around the globe, and was offered to all offices during the BP Amoco merger. Very many other Knowledge Assets have been constructed, covering topics such as shift hand-over, human rights, mergers and joint ventures, entering new markets, building service stations, refinery turn-arounds, plant reliability, and so on. All of these Knowledge Assets are linked to communities of practice, who have the responsibility to keep the knowledge living and growing.

By focusing on the areas where knowledge is crucial to BP Amoco's business, and by packaging the knowledge for the benefit of the end user, we are populating the knowledge bank with knowledge which has applicability, and which has shelf life - knowledge designed for far transfer. At the same time we have been developing the skills within the organisation, through a programme of training to enable the communities to construct and maintain their Knowledge Assets.

All the time we are getting closer to Sir John Browne's vision that 'Every time we do something again, we should do it better than the last time.' (Prokesh 1998)²

Nick Milton is a managing partner with Knowledge Transformation International. He can be contacted at: Nick@miltonn.demon.co.uk

¹ Dixon, N, in press. Transferring the knowledge of experience (working title). Harvard business school press.

² Prokesh, S.E., 1997. Unleashing the Power of Learning, and interview with British Petroleum' s John Browne. Harvard Business review, September - October 1997.