Sharing our “expert knowledge”

How do we share knowledge amongst our team? This sounds like a simple enough question but the answer is important because it guides us when we are building our project structures and processes to facilitate open and useful knowledge sharing. This matters, because it highlights an important point for our project planning – we need to build an environment that encourages and supports the sharing of this knowledge.

McKenzie (2004) studied this question by using a qualitative case study to look at how consultants source, exchange and apply specific knowledge within a medium-sized Australian consulting firm to solve client problems.

McKenzie identified an eight-stage model of knowledge exchange between team members (“interpersonal knowledge exchange”). The model itself seems uncontroversial but what makes it interesting is why the people in the study preferred to use it, and the steps we can take to put it into action.

OK. The starting point here is to recognise that our teams carry expert knowledge that has accumulated through different people over time. Personal experience, documents, databases, etc. This knowledge is available to the team, to help solve new problems, if team members know how to access and use it.

Working in a “shared space”

McKenzie’s work tells us that team members access knowledge through a “shared space” – this can be common language, social etiquette and cultural norms that are specific to the team. They de-construct the knowledge into basic, anonymous information and then re-construct it into a form that can used in a new context.

We share this knowledge with our peers using the “shared space” – in other words, we have a common language or environment within which we can share and discuss information with our colleagues – this “shared space” could be a physical space like a SharePoint site, or something more intangible like a Project team meeting. Regardless of the form of the shared space, it gives our team members a common, shared context within which to share the information.

When a team member’s knowledge is collected and shared, 

…it becomes a part of the collective wisdom of the firm (i.e. organisational knowledge). Organisational knowledge accumulates over time. It is largely dependent on the development of personal knowledge, but may also decay from obsolescence. It may be explicit, in the form of databases or documents, or tacit, expressed by action

Rich and Duchessi (2001)

8-Step Model for Knowledge Exchange

McKenzie’s 8-Step model gives us a simple way to understand how knowledge is de-constructed and repackaged in a new form, to help solve a new problem. Let’s walk though the model using an imaginary case of Team Member Joe, who needs information to answer a question about testing outcomes for a client deployment.

Step 1: Knowledge need identified | Joe identifies a need for specific knowledge, to answer a query about software test outcomes for a new client on-boarding project.

Step 2: Initial Self-Resourced Search | Joe starts by searching through the company archives for information to answer his query. If he finds what he needs, the process ends here. If he cannot find what he needs, he reaches out to team members to ask for advice.

Step 3: Pointers sought | Joe then moves to different team members until he finds someone who has the information that he needs and is willing to share it.

Step 4: Request Negotiation Process | Joe enters a cyclical negotiation, translation and adaptation process with the other team member – he uses the team’s “shared space” – language, norms and practices – to deconstruct his complex information requirement into a form that the other team member can respond to, and understand the context for.

A negotiation process then follows, where Joe and the team member agree on what is needed, the context of the request and how the resulting knowledge should be provided. Joe uses the “shared space” to fine tune his knowledge request – to be very clear about what he needs, and why he needs it. The other team member also gets clarity around exactly what and why the knowledge is needed.

The negotiation may include discussion around when the information is required, the priority of the request and any related cost/effort.

Step 5: Source agrees to participate | The team member uses their discretion and decides when/how to participate.

Step 6: Knowledge Handover process | The knowledge is then handed over to Joe in an agreed form, based around the “shared space”. The team member will have specific experience or expertise – this needs to be channelled to Joe in such a way that its meaning can be clearly understood.

Step 7: Translate to Current Context | Having received the required knowledge, Joe needs to deconstruct the information that his team member has provided and re-package it so that it helps him with his client query.

Step 8: Recipient Implementation | Finally, Joe is able to take the information and apply it to his specific context, and add it to his own tacit knowledge base.

What I like about this process is that whilst it seems simple (and maybe a little boring), it is an important step in building the team knowledge base. The negotiation and knowledge construction/de-construction is all carried out within the team’s “shared space” – this is important for two reasons.

1. The process builds up the level of tacit knowledge within the team. Joe’s knowledge “adaptation” will add to the knowledge held within the team, and will be available to other team members who may approach Joe in a similar context.
2. The knowledge exchange stays within the team, which acts as a “community of practice”. This provides the important context, that sits within the “shared space”. Joe could get information from Google, but the “shared space” helps him set out the context and talk with his team members in a far deeper and more specific way.

Why do team members prefer to use this model?

McKenzie road-tested this model with 40 consultants and in the process, unpacked an important question. Why do consultants prefer to participate in (this process) over the IT based codification system that existed at the firm? Why do people prefer to look up other team members and work through the process face-to-face, rather than reading manuals or look up databases?

In essence, respondents prefer the face to face communication because it allows them to exchange context specific knowledge that cannot be expressed or stored in an explicit form.

Don’t want to waste time reading rubbish. At least in the face-to-face system you get to validate your knowledge of the person and their standing in the community…You can take into account the rigour and credentials of the person giving you the knowledge.

hayden (respondent)

Six specific benefits of the interpersonal approach were identified that, in the eyes of the respondents, could not be delivered any other way.

1. Saves time when exchanging complex and context-specific information. Manuals and artefacts are often pitched at a general level. Face-to-face communication allows us to get specific and discuss nuances that documentation might overlook.
2. Encourages people to share the artistry associated with implementing the knowledge. Talking face to face allows people to share the “unwritten rules” of the game, the lived experiences that can help you get what you need.
3. Allows people to confirm their own knowledge against the community of practice, and make sure their understanding is correct and up to date.
4. Enables team members to learn and enact the subtle, social etiquette that resides within the team. Talking face to face helps team members understand how the workplace hangs together, and how to move around successfully.
5. Requires participation and engagement with the social etiquette of the team.
6. People engage in a continuous process of updating their own knowledge and sharing it with their community.
7. Sharing information with team mates is social, engaging and fun. Gathering information from repositories is never seen as fun. If someone says it is, they are telling a fib!

What does this mean for Project Managers?

McKenzie’s message is clear. While there is a place for documenting a team’s knowledge, the coolness happens when team members are able to engage with each other and share information and experiences, face-to-face.

Step 2 is the key here.

When he realises that he needs information, Joe’s first reaction is to check the company archives and see if the knowledge is captured somewhere. However, if it is not, he reaches out to his peers for help.

The challenge for Project Managers is to build a solid, transparent process for face-to-face knowledge sharing, and make sure that the team and stakeholders are aware of it. This process could take a few different forms:

1. Change Request process – do you have a process where Subject Matter Experts can review a client request to change the scope baseline, and assess the cost/time/quality impacts?
2. Service/Support process – do you have a list of contact points for designated Experts across your Program? This could be a simple document that lists nominated SMEs that can lead discussions on specific queries/areas.
3. Informal team meetings, knowledge sharing sessions – do you have regular, planned sessions where the team discusses an issue or area of common interest?
4. Knowledge Base – do you have a central repository of SME knowledge for your team? Say, a SharePoint site or similar? If so, do you have regular sessions with your team to walk through new additions, updates or refreshers?

The key points are important to remember and apply in our own practice:

We have a wealth of knowledge across our teams

Our team members will look for knowledge, to help them answer specific questions and client requests

We need to make it as easy as possible for our team members to access, add to and share knowledge.

Our team will share knowledge in a “shared space”, using a common language and set of behaviours, etiquette and social norms

Our team members will get the best knowledge sharing outcome if they are able to access the expert knowledge within the team.

Our challenge as Project Managers? To make it as easy as possible for team members to access this expert knowledge, face to face.

---

Reference: Kevin McKenzie (2004). Transferring Expert Knowledge: Interpersonal Knowledge Exchange between Extreme Knowledge Workers. Journal of Information and Knowledge Management 3 (2), pp 127-134.