Overview
Due to the lack of success of formal approaches to knowledge management researchers have focused on the informal, mundane ways in which knowledge, experience and expertise are employed, shared and passed on between personnel within and between different organizations. Numerous studies have now drawn attention to the role of narrative, or stories, in communicating just this type of information. A seminal work in this area is Orr’s (1996) study of photocopier technicians. He describes how the technicians form a community of practice whereby they routinely tell ‘war stories’ to one another as a means of sharing their experiences. Stories provide a means through which knowledge of problems and solutions (in context) is most successfully shared and transferred. That this is the case is shown by the fact that the company achieved more efficient and effective work by the technicians not by designing a better problem and solution database or better manuals but by supplying the technicians with mobile phones so they could talk to each other about the problems as they encountered them.

Currently, there is great interest in the role that stories can play in organizational activities – not only for problem solving but also for many other knowledge management activities and even as means for inspiration, leadership and strategic thinking. Much has been written and it is now espoused by a number of well known academics and management gurus like Larry Prusak, head of IBM knowledge management. The basic idea is that stories are a ‘natural’ way for humans to communicate ideas, knowledge, experience and so forth, they are necessarily social, they help us bond with other people and they contain the necessary contextual details that are lost when we abstract and codify information. Also, they are part of a dialogue, so the teller can be queried for more information, elaboration, re-specification and so forth, so mutual understanding is more easily achieved. The idea is simple; to increase the transfer of knowledge, increase the opportunities to share stories.

Over the last few years we have conducted a number of ethnographic studies of systems design and development in healthcare settings. During this time we have seen and documented a number of the difficulties these projects have experienced. In light of our experiences and the research on war stories we considered that it might be useful to provide a resource through which the experiences of the project teams might be archived as a resource of ‘risks’ or ‘hazards’ of deployment. We decided that a resource that detailed the risks in a narrative format, which could be used interactively by professionals and practitioners themselves, might be a useful approach to take.

We discounted the idea that we should just design a bare ‘template’ website whereby practitioners could add their war stories and their contact details (if they wished). We believed that we might stand more chance of attracting postings and recruiting interest if we pre-populated the site with ‘war stories’ organized in some form of structure that might better allow practitioners to browse for and locate entries that might be useful to them. With so little to differentiate many sites on the Internet, designing to attempt to get a critical mass of users is crucial. Since we had a wealth of ethnographic material from observing and recording project work and interviews with personnel we decided to firstly mine this for risks, hazards and war stories to initially populate the site. In a sense, at this stage we were producing war stories by proxy, where as in the future we would like the war stories to mainly come from the practitioners themselves. These narratives about problems could be posted directly to the website by practitioners. Also, as another source, an ethnographer could explicitly elicit war stories via interviews or collect them from observations of where they spontaneously occur in interactions between personnel in a setting.

Our website is now up and running and populated with 15 ‘proxy’ war stories (or hazards), taken from ethnographic studies of the deployment phase of systems design projects in the healthcare domain. These can be accessed via their titles but are also arranged according to the stage of deployment they arose in, for example, during ‘Database Build and Configuration’. The website is also interactive in that other academics or professionals in the working in the healthcare informatics domain can add their own war stories on-line. We are currently in a phase of evaluation and are taking steps to gain contributors. Given that the UK NHS is in the middle of a large programme of IT development and computerisation, we believe such a resource will be a useful means of sharing knowledge and experience.

Explanation

In most design projects numerous decisions are made that later turn out to be ‘non-optimal’, erroneous or mistaken. In the fullness of time developers realize that if they had known what they do now they would have done things differently. When considering organizational systems (large scale, complex, having a definite impact on organizational practices and operation) the process of design is also a process of learning about the different parts and practices of the organization and learning about the impacts of a design on those parts and practices. This means that unfortunately the required and desired knowledge of the organization is often only achieved at the end of a project. When considering the development of complex and/or large scale systems the possibilities of throwing the initial system away and starting again are often slim. Furthermore, project teams rarely stay together in entirety over the course of a single project, never mind across the development of two or more projects. In the NHS if projects are shelved, the subsequent system is likely to be built by another project team, from a different private company, configuring their own customizable-off-the-shelf (COTS) solution. Much of the learning of a previous project - in terms of documentation and expertise - is likely to be lost or out of date, as in this domain the technology, its envisaged role, and the working practices and procedures of the organizations change rapidly.

Of course, organizations do learn through their own experiences, however, timeliness can be an issue. The question of how much of what is learnt in hindsight can be put to good use in the future is an open one. However, since there is no ‘silver bullet’ of a design method or process – there may be better ways of doing things on a particular project, a more suitable COTS system to buy, more expert designers and programmers to employ, etc., but still no sure fire route to success – previously acquired knowledge and experience will necessarily play an integral part in design and development. Based on this idea we wanted to build a ‘war stories’ website for developers of healthcare systems to effectively share their expertise and experiences to help avoid some of the pitfalls of previous projects and to share their knowledge of development problems and possible solutions.

Guidance
The ‘war stories’ website is a fairly straightforward to use as an informational resource. Users can browse the stories, accessing them by name directly or through the stage in deployment that they arose. We recommend that it is worthwhile to browse the whole list if the user is involved in a healthcare design project as this will hopefully give them an idea of some of the pitfalls that may threaten the project success, or the timely delivery of the system, or that may turn out to be harder tasks than envisaged, and so forth.

Secondly, in terms of contributing ‘war stories’, we are looking for contributors to provide a narrative description of some problem or hazard that has arisen during the deployment of a healthcare information system. Our war stories should provide a template for further contribution. Currently they have a title, are connected to a phase of deployment, are around 100-300 words in length and also have a solution section that details how the problem was dealt with. A simple on-line form is provided for recording this information.