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