Knowledge Bases…Where is Your “Way of Doing Business” Knowledge?

Home/Publications/Best Practices Newsletter/2001 – Best Practices Newsletter/Knowledge Bases…Where is Your “Way of Doing Business” Knowledge?

CIDM

April 2001


Knowledge Bases…Where is Your “Way of Doing Business” Knowledge?


CIDMIconNewsletter Susan Harkus, Web Content Specialist, XT3 Internet Integrator

“You’ll gradually learn the ropes. May take about a year but over time, you’ll come up to speed.”

“The ropes” referred to in the preceding observation are the way you need to do your business. The “coming up to speed” is the time it takes before your worth to your organisation is equal to or greater than what your organisation is paying you.

Organisations are adopting knowledge bases as a way to short circuit learning “the ropes,” but the same knowledge bases that are rich with reference and historic information, such as client profiles or project histories, hold few items that capture the nous, the savvy, the business “smarts” that differentiate your proposal or product.

Traditionally…

Organisations have traditionally captured “way of doing business” knowledge in two ways:

  • Through process and procedure documentation
  • Through document templates and examples

Templates and examples embed some business acumen but are frequently only references for the products or results of business activity.

Process and procedure documentation, like quality system documentation, only partially captures business “smarts.” Good processes reflect what the business has learned about performing business work, but processes don’t capture the tacit knowledge that business people apply when they make decisions or evaluate options.

In Search of Tacit Knowledge

In our highly competitive markets, most organisations readily acknowledge the strategic value of tacit knowledge: the “silent” knowledge that people keep in their heads.

When someone leaves an organisation or changes roles, organisations usually mandate a formal handover of tacit knowledge from one business performer to another.

I would suggest from observation that handovers simply mark the beginning of “coming up to speed.” They mostly fail to achieve their purpose of a rapid transfer of skills and knowledge whether knowledge is passed interactively or as documentation.

Why do handovers do so little to reduce the timeframe of “coming up to speed”? Simply because the information is delivered out of context. It isn’t knowledge; it’s just information. The new account manager can be told when to apply a particular insight about a client, but the reality of applying the insight hasn’t yet arrived. By the time a similar situation arises, the new account manager will probably have forgotten what is relevant to the client relationship.

Descriptive narratives that document tacit knowledge are invariably doomed. I recently watched a team of developers struggle to implement extensions to a technical architecture that had been developed by a former employee. There had been an interactive handover before the employee left, and the employee had also left comprehensive documentation about the architecture.

The project manager was at a loss to understand why the new team of talented engineers was having such difficulty implementing additional functionality. Why did the tacit knowledge transfer fail?

Tacit knowledge transfers fail for any number of reasons:

  • A handover is always out of context unless the new role player has significant experience of the new role before the handover.
  • Descriptive narratives will probably never be read with the application required to “get inside the head” of the person transferring the information.
  • Descriptive narratives are a dump of what one person knows rather than information that is designed to answer the questions of future practitioners.
  • Practice experts who share their tacit knowledge fail to explain the concepts that underpin their insights because that understanding is implicit in everything they think.

In the case of the knowledge transfer about the technical architecture, the knowledge transfer failed for the last reason: the interactive transfer and documentation focused on what and how. When the new engineers were faced with extending the architecture to include new functionality, they needed to understand why.

Don’t Describe, Embed

We work; we gather suggestions from colleagues; we collaborate with clients; we deliver products and services. Every action is supported by our “way of doing business” knowledge. Is there a way to capture such tacit knowledge to ensure that the knowledge becomes an active attribute of the knowledge collateral and is not presented as a learning or reading burden?

In an attempt to find a practical way of capturing and managing “way of doing business” knowledge, I have evolved a method that I call “product-driven analysis.” I’ve used the method with two business areas of our organisation.

We have been able to embed insights and experience in the techniques, tools, and templates that are used to produce products, whether products are software, documentation, or a pitch to a client.

The greatest breakthrough was discovering how easy it was to make “business smarts” available to colleagues through sets of heuristics that are specific to particular business activities.

A Word about Heuristics

I quickly discovered that the word heuristics is familiar to many but is rarely understood. It is a word worth understanding because heuristics provide a practical option for capturing “way of doing business” knowledge.

Let me explain heuristics through a simple anecdote.

In Australia, the motorist’s behaviour at a roundabout is mandated by rules. Not so in the Indian sub-continent where my daughter and her husband spent their Christmas holidays.

When Indian motorists arrive at a roundabout, large vehicles join the roundabout irrespective of whether they have right of way. Small vehicles never demand right of way even when they have it. Vehicles that enter the roundabout near their target exit road travel to the exit road against the direction of the traffic flow if the way is clear. The Indian motorists have developed a set of heuristics (informal processes) for navigating a complex driving situation. They choose not to follow a formal set of laws.

In Australia, motorists apply the formal rules automatically. There is no leeway for assessment and decisions. In India, motorists apply their own set of rules, heuristics. Their behaviour depends on the situation that they encounter and the heuristic they choose to apply.

Some call heuristics, “rules of thumb.” Whatever you call them, heuristics can be used to capture some of your most valuable business knowledge.

Most experienced businesses and experts have developed their sets of unspoken rules. They are the best practices that rarely get written down.

Back to Product-Driven Analysis: How to…

Product-driven analysis starts with what you produce rather than what you do to produce.

Manage the analysis on a business group basis to ensure that the “you” and “your” of the following steps become “you, as a discrete business area or function.”

Use a facilitator
Product-driven analysis is best managed and implemented through facilitated meetings and workshops. You are striving to get through to knowledge that most practitioners don’t recognise themselves because the knowledge is implicit in all that they do. Facilitated analysis will give you a better chance of achieving your knowledge-capture objectives.

Who should facilitate? First, look internally. Many information design professionals have good facilitation skills, as do many user interaction analysts or business analysts.

But take care! A job title does not ensure that the title bearer can make your knowledge capture happen. If the capture of practice knowledge is urgent, you may choose to seek facilitation skills from outside your department or organisation.

Step 1: Develop a list of your products
A product can be something tangible like a document, a graphic design, or a piece of software. A product can also be a consultancy session or the pitch you deliver to a client.

Step 2: Identify your work components
I use the term work component to identify a way of producing a product. I needed a term to encompass a set of activities because products are not produced by a single activity. For example, if you make your client pitch as a presentation, the presentation delivery is just one step in the work component technique.

All or some of the following activities will also be required:

  • Preliminary meetings on pitch strategy
  • Preparation and review of the presentation
  • Liaison with the client on meeting times and personnel
  • Pitch delivery
  • Management of follow up actions
  • Debriefing with the business development team

Alternative work components
When you are identifying work components, you will often find that you identify alternative ways of producing a product.

For example, a pitch may be delivered to the potential client as a presentation. A pitch may also be delivered in a two-step process: discussion with the potential client followed by a document that matches your offering to the client’s profile. The box below provides an example of the choices that may influence how you deliver a pitch to your client.

Step 3: Identify your knowledge collateral
For each work component

  • Gather and list the documents that are produced and used.
  • List the situations where you make decisions, give advice, or evaluate options.

Now you can identify your knowledge collateral:

  • The “way of doing business” knowledge that underpins documents from meeting agendas to reports can be embedded in techniques, tools, and templates.
  • The “way of doing business” knowledge that enables decisions and evaluations can be captured in heuristics.

Focus on the documents that you produce.
Most organisations have started down the path to techniques, tools, and templates but have unclear criteria for organising such valuable collateral. Templates are frequently saved to the tool template area. For example, does your word-processing template directory hold everything from report templates to leave application templates?

When tools and templates are not organised to match practice work components, a business practitioner has to have independent knowledge of what to use.

Understand decisions and evaluations that are made.
Few organisations are leveraging the accumulated knowledge that enables decision-making and evaluation.

If you make a pitch to an external client or a client group within your organisation, where is the list of rules that enables you to assess and select the way you will go about your preparation? Where is the set of rules that provides guidance for tailoring your delivery to your audience? Where is the set of rules that gives you options for managing outcomes?

By associating business “smarts” with the actual work component step, you enable your business performers to pick up and apply manageable sets of practice knowledge. There is no pain or cognitive overload in applying the “way of doing business” knowledge. A practitioner just seems to be using some “good ideas” to achieve an outcome.

Step 4: Develop your practice knowledge base
Now that you know what you have to do, work to build your techniques, tools, templates, and heuristics.

Distribute the development effort
Give members of your team responsibility for developing your knowledge collateral, because ownership is the key to enhancing the value of the collateral through new learning.

Divide up the development work

  • By product
  • By work component within product

Draw upon the talents of your team to have specialists or competent performers develop your knowledge collateral. If you have identified several work component alternatives for producing a product, assign each work component to the appropriate performer. Involve new or less experienced team members as assistants.

Use facilitation during development
You may miss recording half the practice knowledge that your team holds if you just rely on each team member to go into a corner and write.

Set up buddy or professional facilitation to ensure that the knowledge capture is comprehensive. You will still fail to capture some important insights, but facilitation will reduce the knowledge loss. Later, your strategies for evolving practice knowledge will trap insights and experience that slipped through the initial analysis.

Step 5: Implement your practice knowledge base
Your product-driven analysis will give you a meaningful structure that can be adopted as the structure of your practice knowledge base.

The partial table on page 35 is an example of part of a practice knowledge base. The first work component has been developed in detail.

Use a hypertext medium, such as Help or an intranet, to link document files directly to your work model. I have added an explanation to each entry to aid you in reading the table and interpreting the document links.

The simple tabular format enables your practitioners to browse the table by product and work component. A specific product and work component combination identifies the set of knowledge collateral that supports part of your practice. Practitioners open the documents they need and save them as copies for their current work.

Step 6: Set up strategies for evolving practice knowledge
Now that you have captured your practice knowledge, work with your business group to establish a knowledge evolution culture.

Discuss the way you will collect new ideas such as alternate or replacement technique steps. Knowledge bases quickly become stale repositories if your organisational culture does not support the evolution of knowledge through continued learning and sharing.

The following two-step approach offers one option for evolving your practice knowledge base:

1    Assign product or work component owners who will collaborate with the group to manage updates to knowledge base collateral.

2    Encourage all practitioners to buy into increasing the value of the collateral they use by passing insights on to the product or work component owner.

All items except the practice knowledge home page are in standard document formats such as Microsoft Word or Microsoft Excel. Knowledge base updates can be managed by taking a copy of the existing item, making the agreed changes, and returning the updated document to the knowledge base directory.

Where is Your “Way of Doing Business” Knowledge?

I have outlined the high-level process that I am using to help colleagues capture critical business knowledge-knowledge that is so often lost when staff leave or move between departments.

I have my own techniques for facilitating product-driven analysis and for assembling the sets of collateral. You will have techniques that you are already using for similar activities.

Perhaps what I have learned will move you forward in your quest to capture your practice knowledge. CIDMIconNewsletter

Practice Knowledge Base

Products
Work components
Techniques, tools, templates, and heuristics

Pitch to potential client

(definition of product)

Deliver pitch at client meeting

What? (description of the work component, roles, alternatives, inputs and outputs)

How? (technique for performing the work component)

Agenda for strategy meeting (tool)

Customizable pitch presentation (template)

Pitch development guide (heuristics)

Meeting invitation email (template)

Pitch meeting agenda (tool)

Follow up guidelines (heuristics)

Debriefing checklist (tool)

Deliver pitch through document

<related collateral for delivering a pitch by discussion and document>

<next product>

<related work component>

<related collateral>