Author: Tom Kendrick
This is not strictly speaking about Knowledge Management but it applies to the work of knowledge managers. The Knowledge Managers down in the trenches and even the Chief Knowledge Officers up above may have limited direct authority, no or limited budgets of their own. If they are having an impact, it is through influence and persuasion rather than through command-and-control mechanisms.
While the book focuses on a project environment, the main principles apply beyond the context of projects. In fact, knowledge managers may be working WITH project managers and provide knowledge services TO projects rather than implementing KM projects of their own.
The book also uses a strong PMP-style framework which can be adapted to different contexts. I could take each chapter of the book and adapt key principles to my context or prior experience. Here's how it might work.
Chapter 2: Control through Process.
I don't approach projects from a KM perspective with a big stick, telling them there is a requirement for them to document lessons learned at regular intervals and informing them that I'll come to check on their progress in that regard. My big stick would look like an inflatable toy. They might laugh me out the door. In most cases, I don't emphasize the "requirements" aspect of it until they ask. And they will ask. "Is this a a requirement?"
I approach projects with the end in mind. I am here to help them learn as a team. That is always the primary objective. Whether we manage to check the requirements box with some documented lessons learned is almost secondary. There is no point in documenting lessons to check the requirements box if the team didn't really learn anything. Which is why the team conversation is so critical (See Nancy Dixon's recent LinkedIn article about Authentic Conversations).
I approach projects with a simple process, the group reflection session. It needs to be perceived as relatively simple and easy to execute by the team (team management in particular). Yet it can be challenging depending on the team and nature of the issues to be discussed. That could be discussed further elsewhere (next post). The point is that project teams don't want to be reminded that they are required to document lessons learned, but they might welcome someone coming in to help with a simple process that will allow them to do just that AND learn at the same time.
The only way I can "control" to some extent what project teams do in terms of knowledge management is by providing a process for integrating knowledge management activities in their project world. The project environment is very process oriented to begin with. The key is to embed as much as possible and not create too many "new" processes. Rather than bringing in a rigid process, I am able to tailor that process to the team's context and needs. Tailoring can be done around the format of the group reflection sessions, attendance, and scheduling. That's also where I can exercise some control by insisting on certain principles. For example, the project manager cannot hand me a PowerPoint with HIS/HER lessons learned and be done.
- Try to put the project learning process in the ITTO (Inputs, Tools, Techniques, Ouputs) PMP framework.
- Integrate a "results without authority" module in training materials.