A Knowledge Management (KM) Primer

https://www.dtra.mil/portals/61/Images/AllNew/Mission_banners_jpegs/IT-header.jpg?ver=2019-04-28-194212-710
Image Credit: DTRA

Posted: February 10, 2016 | By: Dr. Mark Addleson

Two approaches to knowledge management

It is important to understand the relationship between knowledge and information, because this has a bearing on how organizations approach KM and it also explains why many KM initiatives fail to live up to expectations.

Organizations undertake KM initiatives in order to improve efficiency, because they see KM as a way of becoming more competitive, of reducing costs, and so on. KM will have these benefits if it enables people to be more creative, to work smarter, to be more productive and, generally, to do better work. Earlier, I said that in order to make sense of KM – to appreciate what it is about and also to understand what works and doesn’t work – it is necessary to keep an eye on the relationship between work, knowledge, and information. Now, we can begin to see why.7

The nature of knowledge-work

Here are a few examples of knowledge-work

  • Organizing and coordinating teams designing the hardware for the navigation system of a surveillance drone.
  • Deciding what kind of information to extract from a huge database of customers’ purchases collected by a supermarket chain, then writing algorithms to extract the information.
  • Tracking down the people responsible for committing a bank robbery.
  • Assisting customers who are subscribers to your cloud-based hosting service to set up their sites.
  • Designing a guidance system for an air-to-air missile.
  • Developing a training program for employees in your HR department.
  • Testing the security of a large government agency’s information systems.

Now, here are a few of the characteristics of this kind of work:

Many people are involved in getting things done: employees of the organizations, their customers and clients, contractors, suppliers, and so on.

Typically, much the work is done by an assortment of project groups or teams. These may be comprised of people with different skills and technical qualifications. From time to time teams need to interact with other teams, both from the same or different organizations, who may be spread out across the globe.

The problems people deal with in order to get things done are often ill defined. They don’t have clear-cut objectives, a predetermined time-line, and in some cases they don’t even know who they are going to work with, as people are assigned and reassigned while the project or task is in progress.

Even before they begin to ‘solve problems’ their work involves ‘setting’ the problem: deciding what they are doing or what issues they are dealing with, then deciding what they’re going to do about the situation and who should be involved, setting schedules, and getting commitments (Schön. 1983).

This work is what we call ‘organizing’. Knowledge workers spend a lot of time organizing.

They do this by interacting and talking to one another on the phone, in person, and by email. In fact, much of their work consists of conversations. Before a defense project is funded there are rounds of discussions and negotiations, among a multitude of stakeholders, including potential contractors, politicians, and senior officers, offering proposals, doing evaluations, and providing counterproposals. At different times these groups draw on individuals with a variety of skills, from negotiators to cost estimators to proposal writers. And, with the object of deciding what comes next as well as assessing what’s been done, the pattern of sharing knowledge – talking, asking questions, offering advice, listening to what clients and colleagues have to say, getting commitments, providing updates on what they have accomplished, and so on, continues throughout the project until the contract is eventually put to bed, perhaps a decade or more later.

From these few points we conclude that:

  • Work is very social. It involves people continuously interacting with one another.
  • Knowledge-work is also cooperative in the sense that people need to collaborate in order to define and solve problems together.
  • Conversations are central and, when you observe them at work, you realize how much time knowledge workers spend on the phone, on email, or talking to others in conference rooms and corridors. They can get little done unless they talk to each other, sharing their knowledge; and unless they are willing to collaborate they won’t share knowledge. By talking to one another they find out what the issues are, what has been done so far, what needs to be done, what kinds of problems people are experiencing, and so on.

Now, these behaviors – working together collaboratively and talking to one another, sharing knowledge, are not the norm in most organizations. Under ‘old’ rules of management, which evolved in the factory system:

  • Competition, rather than collaboration, is expected. People compete with one another in order to climb the ladder to the top or to earn bonuses and bigger paychecks.
  • Action is valued more than talk. In fact, employees are generally discouraged from talking.
  • Employees are expected to work alone, rather than cooperate.

The design of office space illustrates the last two points. You find employees sitting behind cubicle walls, isolated from each other.

KM version 1

One approach to knowledge management says the real purpose of knowledge management is to correct the deficiencies of conventional management practices. Knowledge workers can’t function effectively in a factory-management culture. People need to talk to one another, they need to cooperate (collaborate) more than they need to compete, and as it takes a team (even teams of teams) to do the work, we should be rewarding team-effort rather than individuals.

From this standpoint, the fact that they are doing knowledge-work, not assembly-line-work, changes everything (Allee, 2000). KM, viewed as any and all actions that encourage and enable people to collaborate and, in the process, co-create and share knowledge, should be as ubiquitous, necessary and natural for organizations as breathing is for humans.

Adopting KM version 1 means recognizing that knowledge management is potentially deeply subversive. Its purpose is to change the way we manage work – making any and all changes necessary to ensure that knowledge workers are able to do and produce good work. In the interests of creating a culture where teams really do work as teams, where people are able to leverage their combined knowledge to solve wicked problems (Conklin, 2006; Marshak, 2009; Rittel and Webber, 1978), produce good software, or deliver excellent services, we need to examine every practice to see if it stands in the way of generating and sharing knowledge. Nothing should be sacred.

KM version 1 begins with questions like:

  • Our work depends on collaborating and sharing knowledge, what does it take to do it well?
  • How well are we doing and what are the obstacles?
  • How do we deal with them?

Only when people understand the relevance of these questions and have good answers should they address more ‘technical’ ones related to ‘intellectual capital’ and ‘talent management’ such as:

  • What kinds of knowledge/experience do we need?
  • Who has this knowledge?
  • How do we ensure that the people who have it are connecting with those who need it and vice versa?
  • What kinds of tools will help people collaborate and, how do we encourage people to use them in ways that foster collaboration? (see Wenger, White, and Smith, 2009)

KM version 2

A fundamentally different approach to KM, which is very popular, KM version 2 focuses on tools and data (or ‘content’) more than, and in many cases instead of, people and practices. Most organizations with KM initiatives actually do KM version 2, even if they talk as though they are doing version 1. There are probably two reasons for this. First, KM version 2 is not subversive. It fits well with conventional management practices. The other reason is that people who are responsible for KM often have not thought deeply enough about knowledge and work and haven’t asked the deeper questions, about why they are doing KM, what they hope to accomplish, and what it takes to get there.

It is fairly easy to tell whether organizations are doing KM version 1 or 2. Version 2 is characterized by a highly technical KM language and by budgets that are heavily oriented to IT, to technologies like portals, databases, and search engines, and to activities like ‘knowledge engineering,’ knowledge capture and retrieval, information retrieval, enterprise architecting, data mining, and categorizing information (creating taxonomies or developing ontologies). KM version 2 is an approach that tends to see and treat knowledge and information either as completely separate (and to focus on information, mistaking it for knowledge) or to blur their differences. So, when people doing KM version 2 talk about ‘collaboration’, they often mean moving information or data around, rather than people interacting and sharing knowledge as they make meaning together (Addleson, 2013).8 KM version 2 should probably be called ‘information or data management’ rather than KM.

Why it is necessary to keep these two approaches to KM separate

At the end of the day, doing knowledge-work well – producing good results – depends on people collaborating and sharing knowledge. This is the bottom line of knowledge-work and the object of KM version 1. People need to share knowledge and, no matter how sophisticated your technology, no matter how good your search engines, or how detailed your taxonomies (i.e. no matter how hard you pursue KM version 2), if they won’t share knowledge or don’t do so effectively you have a problem: your teams and project groups become dysfunctional and projects run into trouble and fall short or fail.

Most organizations struggle with the problem of sharing knowledge, but few are tuned into the reason for the struggle; they manage knowledge workers using outdated, high-control factory-management practices and KM version 2 is compatible with these practices. For example, knowledge workers need to network – and networks are loose and flexible – but organizations rely on rigid, top-down reporting structures. Instead of paying attention to these issues, to the culture the enables people to organize their work in fluid networks, with flexible plans (and deadlines if necessary) and agile practices – clearly this is a tough nut to crack because it requires everyone to think and act differently – organizations focus attention on KM version 2, opting for ‘technological fixes.’ Here, they get assistance from vendors who claim, misleadingly, to sell KM in a can (i.e. a computer/server). When they install this software, purchase this search engine, create a portal, build the right workflow processes, and so on, ‘information rich,’ employees will work smarter, quicker, be more productive, and organizations will be more innovative, more competitive, and more profitable.

Community of practice or community of interest?

Alongside portals, document repositories, directories, and search engines communities of practice (CoP) are an integral part of many organizations’ KM initiatives. There is good reason to be pleased that word about CoP spread quickly (the term was coined by Jean Lave and Etienne Wenger in 1991) but there is a downside too. CoP is an over-used buzzword. What organizations call ‘CoP’ are often communities of interest (CoI). The difference is significant, as I will explain.

Knowledge-work is collaborative, creative, and synergistic. Knowledge workers get things done by interacting and sharing knowledge, when they draw on their experience to answer colleagues’ questions or give advice, when they swap stories or try to fathom out – together – what is going on, what they need to do and how to do it. Communities of practice, as the name suggests, have to do with the way people do their work (i.e. with their practices) but, to appreciate what makes a CoP and why they are important for KM, the words ‘community’ and ‘practice’ must carry equal weight.

The word ‘community’ suggests a group of people who are quite intimate with one another; connected not only by intellectual interests (e.g. rocket scientists who design missiles) or formal work requirements (e.g. individuals designated as ‘members of the “Blue Team”’) but also by interpersonal relationships like friendship and/or loyalty and/or collegiality. Perhaps they show genuine affection for one another, with each one caring about what the others do or don’t do. When people ‘live in community,’ they tend to see each other quite often, know quite a lot about what the others are doing, and be generous in helping and supporting one another when they need it. This describes the relationships among people in a CoP.

Turning to practices, Etienne Wenger identifies three elements of their work practices that give members of a CoP a sense of belonging to and participating in a shared enterprise (Wenger, 1998. 72-85. See also Wenger, 2004; Wenger et al, 2002).

  • Their ‘mutual engagement,’ or the fact that they are actively involved in doing the work together.
  • The fact that they see their work as a ‘joint enterprise’ and, as they interact, continuously discuss and clarify what they are doing, what constitutes ‘good work’ and whether what they’ve done is up to standard, and so on.
  • A shared repertoire’ of resources in the form of shared routines, artifacts or tools, a common vocabulary, and, perhaps, similar ways of thinking, even dressing.

Julian Orr (1996) and others have written detailed accounts of CoP, explaining how they work and what makes them different from regular teams and the kinds of interactions people typically have in organizations. Some of the characteristics of CoP, which you might expect in a community, are:

  • Limited hierarchy. Members treat one another as peers. Authority is based on age, experience, and expertise rather than rank.
  • Limited competition. Relationships are collegial and cordial and competition is friendly (e.g. demonstrating problem-solving skills rather than rivalry for promotion).
  • It is seldom ‘strictly business’. When members chat they will talk about their families, share their concerns about bosses or colleagues, and so on.

From the standpoint of KM, CoP have virtues that are particularly important. One is that participants readily share knowledge. CoP are good – some might say ideal – knowledge sharing contexts. The other is that they are to a large extent self-organizing. Rather than compliance, relying on instructions and rules from above, it is participants’ accountability to each other, as well as their mutual commitment to their ‘joint enterprise,’ that ensures the job gets done and gets done well. Self-organizing is a particular virtue in environments where things are constantly changing and experience is paramount. Rigid rules and formal structures impede rather than assist people in getting the work done.

As you might expect, organizations that understand and practice KM version 1, emphasizing flexible work processes, with groups sharing knowledge and organizing themselves, are generally better at supporting CoP. Sharing knowledge is everyone’s business. This means a culture of openness. While CoP can emerge in all kinds of environments, they are more likely to thrive when there is openness rather than top-down control.

You’ll often find groups called ‘communities of practice’ in organizations that have adopted KM version 2, emphasizing tools and technology ahead of people and practices. Most of the time, however, these are, at best, communities of interest (CoI). Members of CoI are interested in the same ‘body of information’ – not necessarily work-related – and, often, have little else in common. They may be members of the same profession (e.g. lawyers; scholars) and/or have a similar domain of expertise (tort reform; medieval religion). Sometimes a CoI is comprised of individuals with the same hobby such as sci-fi, model trains, or gardening.

As these examples suggest, the participants need not be in the same organization and CoI are often virtual groups of people who only contact one another online, as members of a user- or interest-group. In common with members of a CoP, sharing their ideas, knowledge, or information (in the form, say, of articles, drawings, or URLs) helps CoI members get things done, whether at work or play. This is valuable but, when it comes to KM, it is only part of the story. It is ‘cooperation’ rather than ‘collaboration,’ which means ‘working together’.

Members of a CoP generally work together closely and, as joint contributors to the work, co-create the results, whether this is a PowerPoint presentation or a piece of software. To understand the difference and why collaboration is highly desirable, you need to appreciate that knowledge-work is deeply creative. When software developers start a project, for example, they seldom know where they will end up. Their ‘product’ comes to life and evolves while they work, in the work, as they interact and talk among themselves and with their clients. Without the back-and-forth, the meetings, conversations, and networking, little would be accomplished.

The bottom line is that CoI are necessary, but not sufficient, for people to do good knowledge work. When a KM initiative is mainly tools and technologies (KM version 2), the IT department that takes the initiative in setting up SharePoint sites for team members to share ideas or ask for advice is helping the cause of KM; but by how much depends on a variety of factors. If the organization is hierarchical, their online contacts should help people work around the barriers to knowledge sharing (e.g. between superiors and subordinates) created by hierarchy. Yet, you can do this without affecting the culture and ultimately it is the culture (whether people do or don’t want to share knowledge) that matters.

If, for example, their business involves working with ‘big data,’ or if they have highly sensitive information that needs to be secure, organizations surely must have a heavy IT focus (i.e. KM version 2). Focusing on IT, however, is never the end of the story in terms of getting work done. In fact, in most cases it is just a small part of the story. Knowledge-work means people getting together, interacting, talking, sharing knowledge and creating new knowledge in order to solve problems, deciding what to and how to do it, then guiding and assisting one another in actually doing it. Making this happen takes KM version 1. Organizations that are mainly doing KM version 2 won’t get the results they want. Poor knowledge management practices and limited collaboration will consistently hamper them. It is worth thinking about your organization’s stance on KM? Are you doing KM version 1, version 2, or both? And, how well does KM serve you?

To answer the question, how should we organize knowledge-work, you need look no further than Agile methods, like Scrum (among many sources of information on Agile, see the articles on Ken Schwaber’s website http://www.controlchaos.com and Mike Griffiths’ blog, ‘Leading Answers’ at http://leadinganswers.typepad.com/leading_answers/). Although they are associated with software development and project management, agile methods should serve as an example for all knowledge-work. As the name indicates, these methods have evolved with flexibility at their core. Agile recognizes tacitly that, in spite of their best efforts to do so, people may not be able to see and plan very far ahead. Instead, they figure out what to do (and, possibly, where they went wrong) while actually doing the work – discussing, planning, designing, and building – with one another, with other teams, and their clients. So, Agile practices rely on stakeholders interacting (i.e. cooperating and collaborating) frequently, sometimes daily (even if only for a few minutes) to share knowledge; and they rest on the premise that, as those doing the work know better than anyone what is going on, it is best for them to organize themselves (see Addleson, 2011).

The Team Software ProcessSM embodies many of the best practices for supporting knowledge-work including: coaching, team building, collaborative planning, and regular meetings to assess and report on the status of the work and to revise plans. Watts Humphrey (2000), the developer of TSP, says it was clear, early on, that the success of TSP depended on management providing broad support for the process. This is true of KM in general and, as good KM practices frequently run counter to ‘old’ management practices, letting go of the old ways may well be the main obstacle to implementing a successful KM initiative.

Want to find out more about this topic?

Request a FREE Technical Inquiry!