Friday 14 March 2014

A week in the life of a Knowledge Manager

Classy Dark Formal Calendar PSD by Zack D. Smith
Classy Dark Formal Calendar PSD, a photo by Zack D. Smith on Flickr
Back in 1999 I contributed a chapter to the book called "Leading Knowledge Management and Learning" in which I wrote a chapter on the Knowledge Manager role I had played in BP's Norway office in the mid 1990s.

As part of that Chapter I included a section called "A week in the life of a Knowledge Manager," reproduced below, which reminds us of how KM worked 20 years ago, when the bulk of our activities were face to face. In many small companies, where face to face interaction is a daily occurrence, most Knowledge Managers will continue to work this way, although the Office Noticeboard would nowadays be replaced by the Department Wiki..

A week in the life 
It is quite hard to describe a typical week in the life of a knowledge officer in a small site office like Norway, as no two weeks were ever the same. However, there were many tasks I did on a frequent and regular basis, which accounted for most of my knowledge work. To begin with, I needed an overview of the project activity, so I could make sure each project manager was maximizing their use of knowledge. Every month I would make a round of all the project leaders, and ask them for the details of their active projects, were they still active, or had work ended? Were any new projects underway? I would take all this information, and update the project chart.
 All our work was divided into projects, each with a project leader, a team, a defined internal customer, and measurable objectives. At any one time there might be 60 to 100 projects running in the office. The project chart was a useful document that showed at a glance how the activity of the office was arranged, and how it all fell into place as a means of delivering the performance promises that we had made to the management of the group. If a project had finished, and the team leader had not scheduled a Retrospect, then it was time for me to exercise my influencing skills, and persuade him/her to invest the time needed to call the team together to capture and document knowledge they had generated. There might be some new projects starting up. I would go and spend some time with the project leader, and try to identify areas where they could reuse knowledge from previous projects. One good example of this was in the use of summer interns. These bright young people can be a tremendously valuable resource, if they are managed properly. We learned many lessons every summer about the ideal way to manage interns, and the next summer I would seek out the intern supervisors and prompt them to read through the lessons, and apply them to their own intern project. 
In some cases there would be other teams in the BP group who done similar projects before.  We would schedule a Peer Assist, which was  a special type of structured and facilitated knowledge-exchange meeting where  people with relevant experience could come in and share what they knew with the project team. For example, one of our discoveries was a gas condensate field (gas condensate is a single-phase reservoir fluid which is problematic to produce) buried very deeply under the  northern North Sea. Developing a field such as this is difficult and costly, and it is easy to make wrong decisions and costly mistakes. We had never developed such a field before, but there was a team in Aberdeen who had just completed a similar project. We asked them to visit, and held a two-day Peer Assist where they shared with us all the knowledge and experience they could, and set us on track for a successful development decision. We would probably have two or three Retrospects scheduled per week. These meetings might take anywhere from 20 minutes to three hours depending on the scale of the project.  I would act as facilitator for the Retrospect, also taking notes of the meeting.  Afterwards I would re-write these notes to extract the knowledge, and write these out as Lessons Learned for the future.  Once the meeting participants had agreed that the lessons were valid, I would pin them up on the main notice board for everybody in the office to read, and also update the lessons  database.  Then perhaps I would spend half a day working on the explanatory manual for the project management system, or doing some work on the Web site, or doing an introductory run-through to the system for someone new to the office. Or perhaps I would be sitting in with the management team at one of the high-level meetings to look at the performance of the office, to look at the risks and opportunities, and decide the ways forward.
 Many of my activities were to do with perfecting the PMS system [this was our project management system, which had a strong KM Framework within it], monitoring its use, and prompting, coaching and facilitating people in their KM activities. I am convinced that a role like this is needed, and that without someone playing this role, the system will fall into disuse. Knowledge management is seen as important, but not always recognized as urgent when compared with operational activity. A key part of my role was to give urgency to knowledge management. Occasionally there was resistance from people who felt they were too busy for KM, and this resistance was strongest from people who were new to the office. Most of the people who had experienced the PMS system realized that a short-term investment of time to capture knowledge would lead to long term time savings when the knowledge was re-used. Because the PMS system was run entirely within a single office, we faced no problems of inter-office rivalry, or the "not invented here" syndrome. In fact, at that time there were no other offices in the BP Group running anything similar, so the opportunities to access knowledge from elsewhere were few.  Looking back at the Knowledge Manager role in the BP Norway office, one of the things that helped to make it work was where it was positioned on the organisational chart.  I was not part of the line management structure; I reported directly to the Business Unit leader, with no direct reports of my own.  This meant that I did not influence the staff appraisal system.  I could work knowledge issues with the office staff, looking at things that had gone wrong and how they could be improved, as well as looking at things that it gone well and how they could be repeated, without anybody worrying about how this might impact their promotion. 
In hindsight, this positioning was crucial.  People can have a great reluctance to share a their fears, even to analyze their failures in order to draw out the knowledge, just from a general fear of showing weakness or exposing mistakes which might impact their career.  The knowledge manager working with these people has to be in a position of trust.  He or she has to be trusted and respected, even liked. You couldn't run a knowledge management system with a CKO or knowledge manager that people didn't know, didn’t respect, didn't trust or didn't like.  The exchange of knowledge is predicated on trust. Removing the knowledge manager from the line structure meant that people could be open and honest, without worrying that it might affect their pay grades. 
 I see knowledge management as something that needs an even-handed application of people, process, technology and governance issues across all aspects of the business, and my advice would be to keep it as a separate function, with the CKO or local Knowledge Manager reporting directly to the leadership.

No comments:

Blog Archive