Expert Map

Here's a true story: During a knowledge needs mapping process we conducted at one of Israel's largest high-tech companies, one of the managers presented us with a significant challenge he had to face. The company, bidding on a very large tender, needed to provide evidence of prior knowledge in a specific field that the project team members would bring. Much of their revenue depended on properly responding to tender proposals, so this issue was particularly important to the manager. After finding no employee meeting the requirements in his division, he submitted the tender response. Unfortunately, the company did not win the tender, but about three months later, the manager accidentally discovered that an employee in a parallel division had exactly the required knowledge. The manager noted that he would have been very happy if he had had a table mapping out the areas of expertise of each employee.

This story beautifully illustrates a need that more and more organizations face: the need to locate experts or knowledge holders within the organization. The expert map is a solution meant to address this need.

So what is an Expert Map?

An Expert Map doesn't include knowledge but points to those possessing it. Some might view it as an organizational index or "Yellow Pages." The main purpose and notable advantage of the Expert Map is its ability to identify knowledge holders in the organization precisely, so any employee can reach the most relevant knowledge holder with just a button click.

The Expert Map has two clear advantages over knowledge repositories. First, not all knowledge can be managed (conceptually and practically), so knowledge repositories will always be somewhat incomplete. An additional advantage is that, as far as we know, responses from knowledge holders are always the most up-to-date.

An example of these advantages could be from an industrial organization's research and development department. In this organization, each researcher maintains a "research notebook" containing interim records of experiments and successes at different stages of research. Some of these records make their way into the final report. Still, some remain in the notebook for practical reasons (a long research report isn't efficient or readable) and methodological reasons (the need for this information isn't clear when writing the final research report). Let's say that a researcher specialized in a specific research area after conducting several experiments. Using the Expert Map would allow interested parties to reach them as a primary information source. Based on their experience, they can decide whether to direct the inquirer to information in the research notebooks that didn't seem relevant when writing the final report, and they can also update the inquirer about additional information that has accumulated over time and exists only in their head based on their experience.

After demonstrating what an Expert Map is and its inherent advantages, let's take a step back and ask ourselves who exactly is an expert? The Babylon dictionary defines it as "professional, specialist, professional authority, knowledgeable, experienced, skilled, best." The Milingua dictionary adds another layer referring to the experience dimension: "expert in something, specialist in something, excelling or skilled in it, understands or is well-versed in it, primarily due to extensive experience." These definitions teach us that every employee has a load of skills, capabilities, and connections accumulated and developed throughout their life. In the organizational context, this load includes:

1. General skills and capabilities (such as technological knowledge, language proficiency, etc.)

2. Specific professional experiences (using the R&D department example, professional experience could be working with a specific family of materials or employment experience at a competing company)

3. "Soft" information about the industry or environment in which the organization operates (customers, competitors, etc.)

One of the issues that needs to be considered is that expertise is inherently an evolving motif. An employee who joined the organization without expertise in a certain field could be considered the most significant expert after several years of work due to accumulated experiences. Therefore, an expertise map will always be dynamic; there's a need to maintain significant skills and connections according to their pace of development in the organization. In this context, it's also important to ask ourselves whether an Expert Map with a very dynamic pace of development justifies the activity, as we'll always find ourselves "chasing our tail" in attempting to document it.

In which organizations would creating an Expert Map yield the highest returns?

1. In distributed or large organizations where knowledge holders aren't necessarily known

2. In organizations with complex and diverse fields of operation

3. In organizations where the nature of knowledge complicates documentation due to its depth.

Generally, Expert Maps can be divided into two main types: open maps and closed maps. Let's now review the advantages and disadvantages of each.

An open map is one where employees freely enter their list of skills without any limitation or structure. The advantage of this type of map is that employees can enter information as they see fit; they don't feel restricted and some information that might not seem important at present might serve the organization in the future, in the spirit of "cast your bread upon the waters." This type of map has two disadvantages. The first is the searcher's ability to navigate the "sea of knowledge" that exists. The second, and no less important, relates to the added value the map provides to the organization. Suppose the map is meant to serve business needs. In that case, we want the areas of expertise defined in it to be clear, uniform, and of interest to the organization (experience with a certain type of technology would likely interest the organization more than the fact that the employee knows how to play piano).

A closed map is essentially the mirror image of an open map. In this type of map, the areas of expertise that interest the organization are well-defined and structured, and the employee or organization "pours" their experience into these templates so that only information relevant to the organization is expressed. In this case, the disadvantages of the open map become the advantages of the closed map—searching becomes easier and more oriented toward organizational needs.

We'd now like to focus on the architectural infrastructure that distinguishes between these two types of maps.

The base object of an open map is the employee, and relevant areas of expertise are "fitted" onto this object. In contrast, a closed map is one where we separately manage two types of objects: employees and expertise. Let's now demonstrate this point:

The expertise object can be managed as an "expertise tree" where each expertise stems from a higher expertise or as a network of interconnected areas of expertise. For example, in the field of lessons learned, several sub-specializations are derived from the main specialization.

Subspecialty	Specialization
Classic Investigation	Lessons learned
Peer Learning
Workflow integration
Gradual production
After Action Review

The basic assumption is that any employee can be specifically linked to any level in the expertise tree. An employee can be defined as an expert in classical investigation, but this doesn't mean they are an expert in the entire field of lessons learned, which includes additional sub-fields.

Let's demonstrate this with the following diagram.

In the example, Employee A is an expert only in classical investigation, Employee B is an expert in both classical investigation and Peer Learning and at the overall Investigation level, and Employee C is not an expert. Thus, no connection was made between the employee and expertise objects.

So where do we begin?

First Stage: Defining criteria for expertise in the organization's view

Second Stage: Defining the solution type, whether an open map or closed map

Third Stage: Preliminary interviews to identify possible expertise and process anchors. Let's expand on this issue. Organizations likely have knowledge repositories from which information about employee expertise can be partially drawn. Such repositories could include employee files in HR containing their resume with experience information, a list of training completed within the organization, a phone directory listing their current role, etc. Another example of an information source could be a project management system from which we can derive and likely classify the types of projects the employee has been exposed to.

Along with identifying anchors from which employee expertise can be inferred, we should also try to identify organizational processes within which we can incorporate to encourage the use or maintenance of the Expert Map. An example of a process encouraging map use could be new employee onboarding, where we can ask the receiving department to guide the employee about the map's existence and enter their areas of expertise together. An example of a process encouraging map maintenance could be a project, the Gate transition process, where the baton passes from one unit to another. At the end of such a process, there's usually a review of completed activities, and we can easily add a request to review new expertise areas learned to the template. Another example could be the employee evaluation process conducted in most organizations annually. The advantage of adding newly learned expertise areas to the evaluation form or verbal discussion is that we're not creating an additional work process for the organization, and the spotlight and thinking are already directed toward the employee. The disadvantage of anchoring in such a process is that it's already emotionally charged, and asking the employee and manager to focus on newly learned areas could be seen as an additional source of friction.

Fourth Stage: Defining expertise axes and levels relevant to the organization on a disciplinary, technological, or process basis. At this stage, the intention is not to produce expertise levels but only the axes on which we'll determine the levels. Taking an example from the familiar knowledge management world, areas of expertise can be on a process stage axis (such as activity initiation, mapping, characterization, building, launch, implementation, etc.), on a solution type axis (such as expert maps, insights repository, knowledge community), on a technological axis (portal systems, document management systems, etc.) and so forth.

Fifth Stage: Defining expertise levels - yes, these are the expertise levels mentioned in parentheses in the previous section. At this stage, the expertise levels should be validated with as many users as possible.

Sixth Stage: Preparing detailed specifications and a presentation and getting management approval. As is customary with any knowledge management solution, seeing is believing...

Seventh Stage: System setup. Both technical setup by technology people and content setup means collecting and entering expertise data for all employees, and validating them with the expert/manager.

Eighth Stage: Maintaining the map and encouraging solution use while incorporating it into operational anchors as mentioned in the third stage. If possible to integrate the Expert Map into an existing comprehensive solution such as a phone directory or organizational portal, all the better. In this context, we want to remind you of the failed attempt by many companies a decade ago to establish organizational "Yellow Pages" which were unsuccessful. Both because they struggled to maintain updated content, but no less because people didn't use the information. Anchoring an Expert Map is not trivial, but it must be considered and invested in with effort and resources; otherwise, the entire solution will go to waste.

Challenges in the Process

Defining and implementing an expert map brings with it a number of organizational questions and challenges the organization will have to face. The first is the definition of what the organization perceives as expertise, one of the fundamental questions for which the answer is not trivial. Is an expert anyone who knows something about a certain field? Is an expert necessarily someone who knows more than others? Should different levels of expertise be defined? Another challenge is determining who defines the specialization - the employee or the organization? How do you deal with employees who define themselves as experts in several fields when it is clear they are not? Such a thing could damage the tool's reliability and even create cynicism among users. How do you deal with all the employees who are not defined as experts? How do you communicate the subject so their sense of professional worth is not damaged?

Additional questions that arise relate to maintaining skills and connections, encouraging usage, and obtaining the commitment of experts to provide quick and quality responses.

Not all questions have clear and unambiguous answers, and the organization's process involves a lot of trial and error. Still, if we succeed, we can certainly pat ourselves on the back and maybe even designate ourselves as experts in "creating expert maps."

---

Want to learn more about KM strategy?

Here are some articles you might find interesting:

• Knowledge Management Best Practices

• Decision-making in the new world of collaboration

• How establishing a knowledge management system improved service at the call center