Blog Archives

Repositories are for sharing, not storing

A recent thread on actKM.org caught my eye. The problem of getting people to read documents got me thinking about some of the situations we are currently dealing with and I felt the urge to share.

My first response to the question from Jim Brander:

“Jim,

I would say assuming people will read your document is what gets people into trouble. It is also an assumption that just producing a document is enough.

We are looking at a few things related to this at the moment.

Firstly we communicate a clear message through our induction modules/sessions, intranet and workshops that storing a document is only half the job. You have to make sure that the document gets to someone who will generate value from you knowledge. This may require extra effort in either adding metadata or notifying a relevant COP of it’s existence. Repositories are for sharing, not storing.

Secondly we are dealing with assumptions that because I documented findings from a lessons learned exercise and filed it that others a.) will look for it b.) will find it c.) will read it and d.) will interpret my findings correctly.

We now work with the project on developing a communications plan to figure out who needs what message through which best channel. In some cases this may mean a practice note drafted, issued and communicated or in others it may mean sending a team of three people on a 3 week road trip to run workshops with everyone in the discipline to make change happen.

The third relates the wonderful assumption people have that a.) they will receive an email you send them b.) they will read said email and c.) that the recipient will interpret your meaning correctly.

If you want the information/knowledge to get read then you need to look at a whole change management approach, not just restrict yourself to the good old fashioned way of doing things.

A different interpretation of your point is also around the quality of documentation that people produce. These sorts of documents should always go through a rigorous editing, review and approval process. I would suggest this include some user acceptance testing. Far too often the document is written for the authors peers when the actual audience may not be as knowledgable on the topic.”

Here is a followup post:

“Another way I have tried to get this challenge across to people is talking about ‘the gap’. The gap between sender and receiver.

The sender cannot assume that the receiver will close the gap where the sender has left off (publishing a document).

More and more we are seeing efficiency drives to reduce the amount of work, time it takes or cost in providing something. This has in most cases resulted in the work required to close the gap having to be undertaken by the receiver (self service).

A classic situation I have experienced recently is some processing work that was previously undertaken by our finance area has now been moved onto staff to achieve a cost reduction in the finance area, yet has increased the workload of frontline staff and could impact on capacity and even utilisation/billability.

We need to be aware of the gap and give ourselves the best chance of success by working out the most effective way to close it, from both sides of the chasm.”

If you want to make sure you successfully communicate your message, get your point across or transfer some knowledge then you need to do a lot more than draft a document and upload it.

Thanks

Cory

KM Program Comparison

I have just been through a exercise with the Knowledge Management Roundtable in Victoria. It worked out quite well so I thought I would share.

It is a combination of Sense making, Knowledge Market, Speed Dating and Maturity Models.


Step 1.

Get people to write on sticky notes the various activities/initiatives/services that their organisation is undertaking/providing that are related in some way to KM.

Also write your organisations name on them.

Step 2.

Get everyone to put their sticky notes on a large wall.

Step 3.  

Invite the group to then cluster the sticky notes into groups.

Step 4.

Name the Groups. The names this group came up with were:

  • Knowledge Strategy & Implementation
  • Organisational Development/Learning & Development
  • Knowledge Sharing Culture
  • Intranet/Portals
  • Information Management/Library
  • Enablers/Information Technology
  • Business Process

Step 5.

Create a map for each of the Groupings that has a matrix with a vertical axis of complexity (simple. complicated, complex) and a horizontal axis of implementation lifecycle (concept, business case, buy/build, implemented). These were placed on flipcharts and stuck up on walls around the room.

Step 6.

Move the grouped sticky notes to their related map. Everyone then had to put their own sticky notes in the relevant position on the matrix.

Step 7.

People were then invited to look at each of the maps and identify other people who may have already implemented something they are currently working on the concept for. They then found the people and sought advice on any tips or tricks and organise follow up after the workshop.


Some fantastic connections were made and discussion bubbled away across the room.

Something to take back and see how it could be applied in other areas.

Cory

Filling the Bucket

The Knowledge Bucket is now up and running.

This is an open effort to get KM practitioners to share what they know about KM.

Feel free to drop in and throw something in the bucket.

Thanks

Cory

Follow

Get every new post delivered to your Inbox.

Join 639 other followers