Tag Archives: knowledge_management

Now you tell me! – Information at the right time

    Start a conversation 
Estimated reading time 7–12 minutes

My posts have been a bit thin on the ground this year because I have just relocated from the UK to Canada, to start a new job. This has been a lot of fun, but hard work.

The process has made me acutely aware of the problems of delivering information at the time when it is the most useful. This is often overlooked in information and knowledge management, but getting the timing wrong can render extremely valuable information almost worthless if it is forgotten, lost, or misunderstood.

Knowledge takes time

When I started my previous job, it was a new role, so I had to spend time researching, collecting, and collating relevant knowledge and information from existing employees and previous projects. There was no one person I could talk to in order to get an overview and there was no single story for me to join. I enjoyed the research process, but from an organizational learning pont of view, the less time and energy each new employee has to spend merely to find out what they need to do to be effective in their job, the better. I find corporate storytelling, as advocated by knowledge managers such as David Gurteen, very useful, especially when forging connections between “technical” and “business” teams and transferring tacit knowledge. However, telling helpful stories is easier said than done for many reasons, but in this post I will focus on the time factor.

When I came to hand over my responsibilities to my successor, I found I could construct “histories” of projects explaining how we had arrived where we are reasonably easily, because time in the past could be compressed into simple linear sequences – we spent a year debating this, then we recieved a directive to do that, then we reassessed where we were, etc. Such a narrative can answer many questions, explaining scope change, for example. However, when trying to explain what must be done next, it is important not simply to explain sequence, but also timing and conditionality – when judgement calls need to be made. The “history” has to become a “prophecy” and prophecies tend to be vague and enigmatic for a reason!

If you are handing over a project that has very clearly defined next steps, you can produce a set of instructions that say “when this happens, do this, which will result in something else, and then you will have to do the next thing”. You can even add expected timings. For example “when the technical team deliver the next software release (scheduled for April), you will have one week to check that the data has been transferred correctly, and if there are any errors, inform the technical team before signing off the release”. However, if the project is broader in scope, or less well defined, it is far harder. For example, “following the release of the new search system, you will need to manage user satisfaction with the results, which you could do by statistical analysis, customer satisfaction surveys, interviews, liaison with the UX teams, etc., but you will need to put forward a proposal for funding to do such work and what you should propose will be more successful if it is tailored in reponse to circumstances – available resource or budgets, departmental politics, etc. So, it may be better to conduct some small-scale interviews with a handful of users or it may be worth pushing for an expensive technical solution.” Even this simple example of a potential future judgement call has become extremely difficult to turn into a coherent story. Perhaps you could create a series of “time capsule” handover notes – if this happens, open the red envelope (or file or video), if the opposite, open the blue one. Of course, this is hugely time consuming to set up, so not very practical, and you are never going to be able to include all possible future universes.

Successful succession planning is about training someone to make good decisions by themselves so that they can take over from you without instructions covering every eventuality. Again, this is about timing. You have to train them over time, by involving them in decisions and teaching them how to make good decisions well ahead of when you leave. Try to do it on the afternoon before you head out of the office and both you and they will struggle!

Information overload is just information arriving at the wrong time

I have received huge amounts of information, advice, and instructions over the past few months about the move. Instructions arriving too soon can be reassuring as you can “practice” what you need to do, but this may be very inefficient in workplace settings, as it is unlikely people will remember clearly enough over time, so they will end up re-reading the same instructions – possibly even several times – and may even become over-confident that they know exactly what to do, fail to double-check at the appropriate moment, and then make unnecessary mistakes. So, it is worth thinking about the nature of the instructions and planning the delivery of the information as a project in its own right.

It is very tempting to offload everything onto somebody as soon as you think of it, but what you are actuallly doing is handing over the management of the delivery of that information to them. If you are doing this as a deliberate delegation to a junior member of staff, it may be a valid part of their job, but then it should be recognised that they are taking on those extra tasks as part of their workload. For example, if your employee is going to have to fill in a set of project completion forms, assemble paperwork, and write the report before a certain date, it is not necessarily helping them if you send them all the project completion forms before they have even started the project, as that burdens them with both the records management of those documents and the project managment aspect of remembering that the forms need to be submitted a week after the report itself is completed and submitted. If there is some way you can set up a business process that automatically triggers the sending of the project completion forms after submission of the project, the employee can think about other things. It may be helpful to tell them about the forms, and give them a list of the key documents that they will need (monthly budget statements, for example) to keep throughout the project, but you probably don’t need to make them read through every single question in detail at the start of the project, when they are absorbing huge amounts of other new – and significant – information.

Business process efficiency requires thinking carefully about the timing of information delivery. Considering potential “information overload” points from a human perspective is too often forgotten. It may seem simpler aned cheaper to lump all the instructions together and deliver them at once from a technical point of view, but it is worth weighing up whether the savings on the technical side are really worth more than the savings on the human cognitive efficiency side.

Interaction design is about timing

The same principles remain relevant on the “small scale” timings of interactions with a particular website or business system. Good interaction designers pay attention to the limits of human memory and concentration to make sure that users are delivered information in digestible chunks and in easy to follow steps and stages. Poor interaction design leaves the user clicking to and fro or opening multiple windows to try to remember something that was on a different screen.

If you have ever felt the need to make notes on a piece of paper while using a particular interface, tell the designer! Deciding which information the user needs to see early in an interaction and which can be left to the end can be controversial. For example, quoting a base price on a home page and only adding compulsory additions, such as taxes, supplements, and other charges at the last stage of booking could be described as a mis-use of the notion that users need to be delivered information in small manageable chunks. However, providing detailed directions about how to contact the delivery company in case of a query right at the end of a purchasing process is likely to be a good use of information timing, as the user has finished thinking about everything else by that stage.

An example of “perfect timing” I encountered recently was when I travelled into central London to go to a particular shop. I had already made the decision to go there and knew the address, but I did not know whether to turn left or right when leaving the tube station. To my relief, there on the wall in front of me at the top of the escalators was a large advertisement for the shop, telling me the exit to take, the direction to turn, and the number of metres to walk. I did not care about the metre-precise location when I decided to visit the shop, and I did not want to be burdened with that level of detail when I planned my route to the tube station, but getting the information at the exact time that I needed it was extremely helpful.

Same problem – different scales

Balancing the urge to deliver all available information at once against the information overload and cognitive burden this can cause applies whether dealing with long-term knowledge management (typically years-decades), medium-term business process management (months-years), and short-term interactions with an interface (minutes). There is no simple formula to getting this right, but these different information delivery situations have much in common. Thinking about your knowledge management as a form of interaction or your interaction design as a business process may help offer a new perspective on tricky problems of creating well-timed narratives and telling people not just what they need to know, but telling them what they need to know when they need to know it.

IASA Conference 2011: Turning archives into assets

    Start a conversation 
Estimated reading time 2–3 minutes

Semantic enrichment

Guy Maréchal continued the Linked Data theme by talking in more detail about how flat data models can be semantically enriched. He pointed out that if you have good structured catalogue records, it takes very little effort to give concepts URIs and to export this data as sets of relationships. This turns your database into a graph, ready for semantic search and querying.

He argued that “going to semantics cannot be avoided” and that “born digital” works will increasingly be created with semantically modelled metadata.

From Mass Digitisation to Mass Content Enrichment

The next talk was a description of the SONUMA digitisation and metadata enhancement project. Sonuma and Memnon Archiving Services have been working on inventories and dictionaries to help them index audio visual assets. They have been converting speech to text, holding the text as XML files, and then associating sections of the XML with the appropriate point in the AV content, so that it can be searched.

They identify breaks in programmes by looking for the time stamps using OCR techniques, and then looking for jumps in the numerical sequences. They assume that jumps in the numbers are breaks in programmes. This enables them to break up long tapes into sections, which usually correspond to programmes.

Social networking and Knowledge Management

Tom Adami described Knowledge Management projects at the United Nations Mission in Sudan (Best Practice Lessons Learnt: How the Exit Interview and Oral History Project at UNMIS is building a knowledge database). The UN in Africa faces problems of high staff turnover, remote locations, and difficulties in maintaining infrastructure. However, they have been using social networking to encourage people to share their knowledge and experience in a user-friendly way and so add to the official knowledge base.

Archive as a social media lab: Creative dissemination of digital sound and audiovisual collections

Budhaditya Chattopadhyay talked about a project to bring together archival practice, artistic practice, and social media. He also referred to the problems of preserving social media which is in essence ephemeral but may be an integral part of an artwork.

Knowledge angels

    Start a conversation 
< 1 minute

Knowledge angels are not Christmas decorations 2.0 but are “those people in information industries who are the most expert, understand innovations in their sector and add the most value to a company” according to an article on Alphagalileo. The phrase is based on “business angels” and one of the researchers who coined it stated: “Other possible names, such as, for instance, ‘consulting wizards’, ‘services magicians’, ‘knowledge-intensive demons’ or any further hybrid creatures resulting from the crossing of a management handbook and a magic trading cards, would sound less attractive.”

It will be interesting to see how long it takes for the phrase to start appearing on CVs!

Is knowledge stuff or love?

Estimated reading time 2–2 minutes

Stuff or love? How metaphors direct our efforts to manage knowledge in organisations by Daniel G. Andriessen, in the Journal of Knowledge Management Research & Practice, is a charming paper proposing that the metaphors we use to describe knowledge affect the way that it is managed. Managers often talk about knowledge as a commodity or resource to be exploited – it has a finite value, can be traded, conserved, wasted, and presumably can run out. Having discussed various metaphors of knowledge as a resource, Andriessen asked people to talk about knowledge thinking of it as love. He says: “The topic of conversations changed completely. Suddenly their conversations were about relationships within the organisation, trust, passion in work, the gap between their tasks and their personal aspirations, etc.”

He points out the “knowledge as a resource” is a very Western viewpoint, whereas knowledge as love is more akin to Eastern philosophies. Knowledge as love can be shared without it running out, but it is much harder to direct or control it. It is not difficult to guess which metaphor managers tend to prefer!

Andriessen points out that the metaphors we use tend to remain hidden and unquestioned in our subconscious. He urges us to think about the metaphors underlying our discussions and research on knowledge management and ask “What would have been the outcome of the research if we see knowledge not at stuff but as love?”

Dead KM Walking

    Start a conversation 
Estimated reading time 2–3 minutes

This fascinating video (with transcript and follow-up post) on Patrick Lambe’s excellent blog (Green Chameleon) has turned out to be something of a hit, generating quite a discussion.

There’s far more in it than I can do justice to here, but I was struck by two core questions – what is the future for “knowledge management” as a field or practice in itself and what is the future for the phrase “knowledge management”?

I think that “knowledge management” as a practice has always been important and always will be, but the name may well change again and again (I’m sure the basic idea has been referred to as all sorts of things in the past). The lifespan of names is getting shorter and shorter these days, driven by the need to appear innovative and cutting edge all the time. There is also a tension – as people become specialised – to distinguish themselves from each other. This happens in every discipline – biologist, zoologist, ornithologist, herpetologist, virologist, etc. What I am not so sure about is whether “information professional” is accepted and well enough understood as a catch-all, so that “knowledge managers”, “records managers”, “librarians”, “information architects”, “enterprise content managers” etc are all seen as cousins in the same family. I’m also not sure if what is going on at the moment with “knowledge management” is is a kind of vying for dominance of the different terms, so at one point it looked like “knowledge management” would be the one and only catch-all term (rather than “information professional”, “information scientist” etc) and that other terms are now rising to prominence. What I am convinced of, however, is that everybody needs to talk to each other as much as possible and not let names turn into silos. Just as in a taxonomy – the labels are supposed to be signposts, not barriers.