Call for Case Studies: Origins – Asia Pacific Business Narrative Conference Sept 6-8 2010 Singapore

In early 2009 we (Shawn Callahan and I) wanted to see if we could put together a conference on storytelling for business. Our concept was for a very practical, workshop-focused conference, designed to help Asia Pacific business people apply story approaches to boost business performance. But we weren’t sure if anyone would come!

So we organised a two-day masterclass on business narrative as part of The Singapore International Storytelling Festival, and the festival did a wonderful job in telling people about the event. We waited anxiously to see if anyone would register. Did Asia Pacific organisations really value storytelling as a legitimate and effective business technique? I called Shawn in Melbourne a couple of weeks after we announced the event: registrations were coming in fast. We were booked out months in advance.

This year we want to build on that success and focus on the many story practitioners in our region to create an event where we can learn from each other while also expanding the awareness of narrative approaches among the region’s organisations. We’re looking for proposals for case study presentations from within the Asia Pacific region to share what you have done and what you have learned.

The conference has three objectives

• To build a network of practitioners to deepen the practice of storytelling and story use in organizations.
• To create awareness of the broad utility of narrative techniques for dealing with business issues, their capacity to humanise the workplace, and to help organisations deal with complexity and
  uncertainty.
• To inspire leaders to take the first steps in applying narrative techniques in their businesses.

Conference design

The event will have three parts:

Day 1 will be a closed practitioner’s forum for the conference speakers and case study presenters only. We will spend the day sharing what we have learned from a practitioner’s perspective. The day will be designed for dialogue rather than presentations.

Day 2 will be a public conference where practitioners will present case studies that illustrate the effectiveness of story-work; and

Day 3 will consist of a set of 1/2 day workshops to enable attendees to build their business story skills in specific areas such as coaching, organisational change, leadership development and communication.

Do you have a case study to share?

We are seeking expressions of interest to share a case study at the conference. We are particularly interested in stories of working with narrative in organizations, across private, public and non-profit sectors. They should clearly illustrate the value of how stories and storytelling can be used to meet the organisation’s business needs.

Case presenters will:

• Participate in the closed practitioners’ forum on 6 September
• Share their case study in round table discussions in the morning of 7 September
• Offer to share a technique they have successfully used in a “techniques marketplace” session in the afternoon of 7 September
• How we will select the case studies

We will select case studies based on:

• richness of the case for learning
• transferability of the lessons
• demonstrated impact
• innovative approaches
• geographic representation
• representation of different kinds of organization

Please send a short description (a couple of paragraphs) to both Patrick Lambe (plambe-at-straitsknowledge.com) and Shawn Callahan (shawn-at-anecdote.com.au) before 22nd March. We’re also happy to trade ideas by email or Skype if you want to develop an idea before you decide to put a more formal description together.

At a meeting last week, I was asked if I knew of anyone who had successfully implemented filenaming conventions across their organisation. This agency was interested because they wanted to improve the consistency with which documents are named and stored for common use, thereby improving visibility, access and sharing.

Getting started with a filenaming convention

To support such goals, filenames need to be transparent, meaningful, user-friendly and consistent. This ensures that anyone who reviews a filename should immediately be able to form an accurate expectation about the content of the document.

•Transparent means that the words in the filename accurately summarise the content of the document using language in common use.
•Meaningful means that the words used in the filename usefully distinguish the content of this document from other documents.
•User-friendly means that the filename is easy to read and understand in relation to other filenames in a list, when it is presented in an on-screen window.
•Consistent means that similar principles of filenaming are used by all document creators in a department, so that users do not have to interpret different conventions for the same collection of documents.

These principles, by the way, also apply to folder-naming conventions in a traditional folder structure – although with folders, because you are describing collections of content, you are more likely to need a standard taxonomy to provide you with standardised subject-related terms.

Some time back, I wrote a list of high level guidelines for how to approach establishing a common filenaming convention:

• Reduce repetition of common words in file and folder names to a minimum
• Use acronyms only if they are commonly understood among users
• Keep filenames to below 20 characters if you can
• Start the filename with whatever is the key discriminating information for that document type when people want to go find it (eg date, correspondent)
• Construct filenames so that your IT system will display them in a helpful order
• Make sure that all newcomers to your workgroup are introduced to the filenaming conventions
• When you begin any new folder structure or project, agree your filenaming conventions among all content producers in advance
• Enforce consistency by periodic correction of inconsistent naming practices

Filename construction

There is some much more detailed guidance on how to construct transparent, meaningful, user friendly and consistent filenames from a British records management perspective, in guidelines issued by the Universities of Newcastle and Edinburgh respectively (thanks Maish). What is nice about these guidelines is that they explain the rationale for the convention, and give worked examples for both good and bad practice. These guidelines are very easy to adapt, but do localise them to your own context.

Getting the convention bedded down in your organisation

Well at that meeting I recommended Doreen Tan, who has a lot of experience of introducing document management discipline into fairly anarchic or greenfield information environments. She responded to my clients’ enquiry with a very nice, very practical set of suggestions for how to ensure that the convention gets bedded down and actually works. Here is her advice, reproduced with her kind permission:

1. Do not expect 100% takeup rate as it would never happen, but try ways and means to maximise the number.
2. Get buy-in from your senior management at the start; in fact ask them what they would like included in the filenaming convention before implementation.
3. Be able to explain the rationale of including the various components. For example, the version numbers would help staff identify the latest documents if there are 1000 versions being churned out by different people at different times.
4. Leverage on your KM champions or coordinators to help you spread the message and monitor the filenaming at the ground level.
5. Do a 6-month audit to check compliance; highlight examples of non-compliance and keep senior management in the loop. You need to be serious about ensuring compliance.
6. Include the filenaming convention in the staff orientation so that new staff are brainwashed the moment they step into the organisation; have posters stuck on notice board, in the lifts, etc to remind them.
7. Leverage on key managers to help you with the compliance. For example, they will not accept documents that do not conform to the convention.
8. Be ready to set an example at the beginnning of implementation. This means taking the trouble to change the filenaming convention by yourself for a period of time, so that there are live examples that others would hopefully follow.
9. And of course, make sure you follow what you preach so that you will be seen as the ‘authority’ on the topic.

If you provide clear guidelines, and follow Doreen’s advice, you will stand a reasonable chance of actually helping to make information more easily navigated and shared. We shouldn’t under-estimate how a simple, clearly explained discipline like this can influence broader attitudes towards knowledge sharing.

Have we missed anything?

Of course, the human spirit has an infinite capacity to transcend our aspirations and our discipline. Here, from “Taxonomist” is a hilarious list of unusual folder names (appropriately organised into a taxonomy) that she has come across in the course of her taxonomy-building work with organisations. My personal favourites are below (but check out the whole post for them all):

• Left Behind
• Called Joe But He Wont Call Me Back_Toss It?
• I No Longer Care
• Jill’s Train wreck
• Hopefully Trash
• This Person is Deceased_Now What?
• Tom’s Files: he was incarcerated and we don’t know what to do
• Dont invest time until someone asks about it

These folder names do express meaning of a sort – we “get” immediately the emotional stance towards the content. They fail every other test, of course, because there’s really no way of forming a reasonable expectation as to the horrors (or treasures) they may contain. But the patent existence of a need to attach emotional significance to our collections of content is one that should give us pause. How do we accommodate that instinct while still serving those broader goals of access and consistency?

Even between events and venues in a single Games, learning has to be very fast. There’s only one chance to get things right. Any mistake should be made no more than once. This process starts on the ground itself, at every event that’s held. During August, every venue and every event will be conducting immediate after action reviews and collecting lessons learned for collation and analysis. So here’s an appeal for help to the Singapore KM community from Doreen Tan, Head of Knowledge Management for the Singapore Youth Olympic Games Organising Committee (SYOGOC):

“We are currently recruiting volunteers for our Games-Time KM Programme. This programme aims to collect and disseminate lessons learnt to workforce on a daily basis during Games Time (14 to 26 Aug 2010) so that there is continuous / just-in-time learning during the entire period. In order for the Programme to work, we would need to deploy volunteers to both competition and non-competition venues to help in the consolidation and ad-hoc facilitation of the AARs. It would be ideal if the volunteers had some knowledge of KM or are professionally involved in KM to some degree.”

Here are more details. Do help if you can! SYOGOC_KM_Volunteers.doc

• they held a naming competition to generate buzz; the winning entry was MOMster @ Home;
• they offer short video tutorials of under 10 sec on using the new intranet;
• they work through departmental reps, held regular engagement sessions with them, and send them “MOMster Blasts” or e-newsletters to keep them updated;
• they launched a beta version of the intranet at their Innovation Carnival as a teaser;
• after the official launch they held A&E (Anytime for Anyone) sessions to assist people during the painful content migration process;
• their “MOMers Zone” spotlight officers, birthdays and new MOMers;
• they aggregate news daily and send to staff by email to show them what’s available on the intranet;
• they created a Collaboration Toolkit to show staff how to seed communities;
• they do not censor feedback, even negative ones.

Their lessons learnt:

• involve senior management early on in the process; their Dy Secretary gave them some directions;
• start small but think big; beta version and pilot with key users first;
• manage change early; engage users early – “designed by you, for you”;
• focus on governance and education; created Intranet Team and writing toolkit.

More than 90 people from the public as well as private sector turned up for the sharing session. What really impressed me was the openness by which the MOM team shared their experience. Even their IT rep was actively fielding questions. If more people follow their example this is going to bode well for KM in Singapore.

Since 1999, my work has been related to Knowledge Management (KM). Already then, KM was a term that was not well recognised; at the time, we did not label our KM-related consulting services with Knowledge Management. Today I am holding an official position in Knowledge Management, still many people do not grasp the term and have a clear understanding of it. “Knowledge Management” seems to be fuzzy and not specific enough; it does not refer to daily (work) life topics.

In my comprehension, the field of Knowledge Management has a few clearly distinguished topics. With this article, I want to suggest that professionals in Knowledge Management should define a limited number of disciplines, that are concrete, easy to grasp, specific, and well-understood by people inside and outside the field of KM.

Here is a suggestion to split Knowledge Management into five disciplines.

One: Information Management & Search
This might be the classic part of Knowledge Management; the collection, storage, and distribution of information, documents, books, and intellectual property. Instead of information management, we could also call it document management and library management. Related to this is the topic of taxonomies, tagging, and other forms to classification.

Separately, but within the same discipline, I would like to mention the chapter of search; a rather large topic. Related to this is indexing and semantic categorisation.

Examples:

• knowledge libraries in large corporations that allow global access to documents across departments and subsidiaries
• social bookmarking tools that classify websites and allow other users to share them
• search engines that are indexing vast collection of documents and websites

Two: Collaboration
Knowledge does not only exist in final documents, books, website, etc. People are working together to create this information. People need to be engaged in conversations and encourage to share what they already know, in order to achieve more and to innovate. For me, this discipline has two major aspects: 1) establishing a knowledge sharing culture; provide management support, etc. 2) provide supportive collaboration tools; e.g. project management, task management, wiki tools.

Examples:

• contact relationship management (CRM) tools that efficiently share and store relevant information to customers, suppliers, and business partners
• corporate wiki tools that allow the capturing of experts’ knowledge and allow collaboratively develop this knowledge
• project management tools that allow disperse teams to share information, have discussions, and manage tasks & deadlines

Three: Workflow Definitions
In my experience, when we design workflow definitions, or process definitions, and flowcharts for a series of job activities, then we can influence how information is captured, stored, and distributed. This might not be commonly understood as part of Knowledge Management, but workflows of customer complaints processes or order processing flow contain a lot of important information and knowledge. With the right procedures and processes, this knowledge can be captured and shared more efficiently.

Examples:

• the right design of a costumer complaints process can ensure that the sales departments receives more information about the customers and the research & development department gathers important input on how to improve the products
• project management methodologies can include processes to capture project reports which are automatically shared in a knowledge library

Four: Networking
In collaboration, people are working together to share documented knowledge. More important than that is the exchange of tacit knowledge. Again, we need to engage people in conversations; typical platforms are communities of practice, forums, and social networking tools. The main aspect of networking is talking to each other; other elements are expert profiles, white pages, and connections.

Examples:

• social networking platforms allow to publish a personal profile, exchange thoughts, and keep in touch with colleagues and friends
• in online discussion forums questions are answered by a broad community; the answers are then available for the entire community for future reference

Five: Training & Learning
This is another classic in knowledge management. I would assume that in most cases, knowledge is transferred by schools, trainings, and other form of learning platforms. Training and learning is a rather formal transfer of knowledge. Today, this is not a one way transfer anymore. In many areas, the lecturer is capturing experiences from the audience. Popular concepts are case studies, workshops, etc.

Examples:

• corporate induction seminars gathers all newcomers in a company at one time and provide them an introduction at the same time; this could also be done with e-learning tools
• professionals in a specific field of interest gather regularly in conferences to exchange their latest findings and discuss about it
• training programs for ‘Efficient Meetings’ (just as an example) can be conducted in two parts: a) a brief introduction to the latest findings for this topic, b) a discussion among the participants on how these findings could be applied in their environment

Related Disciplines
Beside these five disciplines, there are other topics which are very closely related to Knowledge Management; topics that are necessary for Knowledge Management but might also be applicable in other areas. These disciplines are Psychology of Behaviour, Change Management, etc.

Conclusion & Benefits
Most of these disciplines are very closely linked. For example, people collaborate on documents, or procedure are defined in network. Still, this separation could help to make dismantle the myths about knowledge management and make it more approachable.

All of the five disciplines have the following benefits:

• enable and cultivate conversations between people
• streamline the flow of information in a structured and informal way
• efficient sharing of written knowledge and knowledge in the heads of people
• safe time in accessing a large amount of knowledge
• avoid re-inventing the wheel

Overall, Knowledge Management supports smarter decisions making and innovation.

If we separate Knowledge Management in these five disciplines, the outside world would have a clearer understanding of this field; because people are more familiar with these specific topics, the acceptance of KM could be higher.

“I would reject the DIKW pyramid, aside from the fact it’s just plain wrong, it’s difficult to explain and leads to bad labels. Better to think that KNOWLEDGE is the way we create INFORMATION from DATA. If we share knowledge then we can understand information.”

“Aside from being linked to a particular period of systems thinking approaches, which we are hopefully moving on from, its very culturally specific.  It fails entirely to account of shamanistic knowledge, or the narrative traditions of Sufi philosophy and others.  I could go on, but the you get the point; the DIKW pyramid is a culturally limited and inadequate model which has done more harm than good. The SECI model with its de facto focus on codification comes a close second, as I said the other day it’s the model that launched a thousand failed knowledge management initiatives.  The main problem is its tendency to get people to think of knowledge as a thing rather than as a flow.”

Dave has posted in the past at greater length on DIKW here and here, and so have I.

However, one worried comment from a listserve member that DIKW was a “well-understood idea within the community” struck me, and prompted a further reply from me - because indeed this hierarchy is extremely well entrenched in the KM (and information science) literature. It’s about as sacred as a sacred cow can get. Why? And should that make it immune to attack posts?

Here’s my reply, slightly modified for a wider audience:

It’s important to understand the origins of a model to understand what it was designed for. The DIKW model emerged out of the struggles of computer science and information science through the late 1970s and early 1980s to legitimise themselves as strategic disciplines for the enterprise. For the data managers, the struggle was to get their organisations to treat data as a strategic resource, so establishing a relationship to information that fed decisions based on knowledge made a lot of sense. For the information managers the “downwards” link to data gave them a structure to work from, and the “upwards” link to knowledge gave them legitimacy in the eyes of senior management.

So while it had utility for data and information managers, the hierarchy was never designed to accommodate the far more complex world uncovered by knowledge management, and as Dave points out, it completely fails to acknowledge the naturalistic ways that data, information and knowledge interact. For example, it does not reflect the fact that data is a very small subset of repeatable information, abstracted and structured for mechanical processing based on knowledge. Data is the product of a knowledge-driven, purposeful piece of design work. The DIKW model implies the opposite, that knowledge is the product of a series of operations upon data. The model also completely fails to account for the sea of knowledge activity in an enterprise which is never informationalised or structured as data. In the natural world, data is the product of a very small component of knowledge activity.

From the data manager’s point of view, the problem in the enterprise is “we have all of this data sitting around, think of what we could do with it if we could figure out how to squeeze insight out of it”. While this is a legitimate question, the knowledge manager has discovered rather painfully, that you need to go back to the contexts that created the data and the knowledge activities the data supports, in order to figure out how the data can be manipulated for greater advantage. You can’t get there by performing a series of logical transformations on the data to create information, and then another series of operations to create knowledge.

So DIKW is a managerial model intended to explain how data can be leveraged as an enterprise resource. It has no practical value for guiding action beyond the D-I interface where it has limited value, explains almost nothing about knowledge, and its references to wisdom have always been completely without substantive or actionable content.

Why did the hierarchy become received “wisdom” in KM?

(1) It became received wisdom very quickly in computer sciences and information science literature, because it was a legitimising model – such models become entrenched very quickly.

(2) The weaknesses of the model in relation to knowledge and wisdom were never tested in its first decade by which time it had become entrenched in the literature.

(3) Writers for new knowledge management journals in the 1990s – as in any new discipline – suffered from “citation poverty” and so fell back on the received literature and mental models from their parent disciplines, without adequately questioning their applicability in this new context.

(4) If you don’t actually try to do anything based on the model, it serves a quite useful function in proffering a glib explanation of the distinctions between data information and knowledge and makes a pleasing nod at wisdom, so it seems like it has utility.

(5) If you do try to structure your KM work using the model, you get rapid support from the technology side of KM (so the model must be ok), and when you run into problems with ground adoption and usability, it’s easy to chalk this up to human intransigence and change resistance, rather than the poverty of the model as a framing device.

The pyramid form implies that data – at the base – is more abundant than information, which is more abundant than knowledge, which is more abundant again than wisdom, at the very tip. Indeed, from an enterprise perspective that might seem to be the case, but I happen to think it’s mistaken. My own view is that in most cases there’s a lot more knowledge (in and around the people) than information, and even less data. I won’t comment on wisdom.

One constructive way to read the DIKW pyramid is in terms of the VISIBILITY and TANGIBILITY of the different elements, which is a different thing from their presence. From that perspective, the visual representation of the pyramid makes sense. We do see a lot more data, it’s easier to figure out where it is, and what to do with it. Information is less transparent and more complex to audit and map, knowledge is much more opaque, and wisdom auditing (people do actually sell this!) would be either a work of opinion or divination. So if DIKW just made claims about visibility it would have some use.

That may be another reason why the DIKW pyramid has seemed so attractive: the visual form focuses us first on the more manageable (visible and tangible) elements and encourages us to work on those first as foundational elements – providing a visual justification for a quick win bias. The problem is that the knowledge ecosystem is more complex than DIKW allows, and focusing energies and effort on the easier stuff frequently fails to meet the most critical needs. The critical stuff is just not “seen” through a DIKW lens.

It’s interesting to note that some information scientists have recently been reassessing their attachment to their offspring:

• Jennifer Rowley has a good review of how the DIKW model has been used in the literature, and its ambiguities and weaknesses (Journal of Information Science April 2007)
• Martin Fricke has a sustained critique of the hierarchy concluding that it is “unsound and methodologically undesirable” (Journal of Information Science April 2009).
• Nikhil Sharma has a useful overview of the origins of the DIKW hierarchy.

Anti-DIKW convulsions seem to have their echoes in the noosphere that connects us all. In almost exact synchronicity with the KM4Dev discussion, David Weinberger was posting on “The Problem with the Data-Information-Knowledge-Wisdom Hierarchy” over at the HBR blog (thanks Nancy, and Jaap). He makes very similar points to myself and Dave (although he seems to have borrowed heavily from Nikhil Sharma’s fine paper on the origins of the hierarchy without crediting it – tsk tsk).

I think he’s got it wrong on a minor point: he characterises the hierarchy’s rapid acceptance as a backwards justification of systems that had been built, where I think the emergence of the hierarchy and its acceptance were more of a forwards justification to legitimize data and information management as strategic concerns. But his closing line is nicely put: “Knowledge is more creative, messier, harder won, and far more discontinuous [than the pyramid implies].”

Then I was directed by Simone Staiger to a discussion over at the Agricultural Biodiversity Blog arising out of an example where a youtube video showing trial results from a taro breeding programme in the Dominican Republic was posted on a taro researcher’s Facebook wall with a request for an English translation. He got his translation and found out which of the hybrids were the most promising, along with more information about what was going on with hybrid breeding in Puerto Rico. It’s one of those great, ubiquitous, social media knowledge sharing stories.

The telling part (and the bit that started the debate) was the final line of the post: “Who needs databases?”

Go visit the story to see the full discussion, it’s a very good one. But what struck me was that, in starting a fight over the DIKW-blinkered-view, there are three risks we need to watch out for:

(1) Irrational Prejudice: that we stimulate an “anti-data-mania” along the lines of “structure (data) is totalitarian control and freedom (knowledge/wisdom) is the democratic way”. We’ve seen that already with an anti-expert backlash, and the foolish notion that folksonomies can replace taxonomies. We need data – and structure. They are precious. Data allows us to track and manipulate information about salient features of important things in our world. Like epidemics. Like indicators of weather and climate patterns. Like the efficacy of pharmaceuticals. Like customer behaviours.

(2) Old Mental Models in New Dress: that we “knowledge-people” maintain the prevailing “them and us” attitude towards the “data-people”. I.e. we maintain the same tribal stratification embedded in the DIKW pyramid itself. A consequence is that we treat data just as a servant or instrument of knowledge rather than also as a potential environment for knowledge – one offlist comment that struck me was “one intelligent person can get far more “information” or even “wisdom” from a stream of “data” than any machine” (thanks Jeremy). We run the risk of assuming that data is structure, and so the interfaces with data must also be structured. Jeremy’s comment reminded me that data can also be rich in meaning when we can play in it in less structured ways – though we need to be much more skilled and ethically aware when we do this.

(3) Alienation of Professional Colleagues: that the attack is seen as an attempt to delegitimise data and information management, driving professionals in that field into a defensive mode rather than encouraging the related disciplines to work harder on how we can collaborate constructively with each other. We also need to work on how the different manifestations and artefacts of knowledge can be better represented and supported – in both structured and networked ways.

What does this mean? We need a better conceptual model, certainly, for explaining the elements of data, information and knowledge (and keeping wisdom well out of it), and how they interact. Deeper than that, we need to address the legitimising need of the players in data, information and knowledge management. We need a social model for how the disciplines interact in the service of the enterprise (or the community, or society). If we don’t address this need, we’re just children throwing stones, across lines in a pyramid, at varying levels of abstraction.

“It’s a political quagmire. [KM]IA discussions require a horizontal approach to traditionally vertically managed resources. On top of this, business areas tend to feel a strong sense of ownership of the data in their mission-critical applications, and they’re suspicious that any discussions about data usage with “outsiders” could lead to a loss of control.

A very good relationship between IT and the business is a prerequisite for [KM]IA. Overcoming the political difficulties is challenging enough; succeeding when there is a poor track record of communication and trust between IT and the business is even more unlikely.

[KM]IA can look like a boil-the-ocean effort. The data and content mess facing most large organizations is enormous, and any architects who consider getting the enterprise in order quickly recognizes that they will retire before the task can be completed — no matter how young they are.”

Read on in the report for some insightful advice about “street-level-strategy” building to address these challenges – just as good advice for KM as for IA.

There’s one big gap which is not addressed: take a look at the high level view of the enterprise information architecture (shown below) from the report.

What struck me was what was missing: where are the human beings in the framework? “Real” architects never show their models or visualisations without putting in stick figures to show how it works with people in them. Why don’t we? Apparently, this report, unabashedly technical in orientation, has ruffled a few feathers in the more human-oriented IA camps, not least for quoting a reference to them as “Web weenies”.

There’s a reason why user experience folks call themselves information architects, and they’re not going to be expelled from the academy because they don’t fit within a logical array. The parallels with KM sharpen this question for us as well: where does the interface with people’s desires, aspirations, frustrations and needs come into what we do? Where does it fit within our KM frameworks?

Thanks to Nick Berry for highlighting this via the TaxoCop forum.