Driving organisational change

Using story to transform work processes at ABB

ABB is applying a systematic process for driving organisational process improvement by means of goal-oriented stories, derived from the experiences of the firm’s domain experts and recorded in a ‘storybase’. Peter Fröhlich and Harsh Karandikar describe the work undertaken so far and reveal some of the key lessons the company has learnt.

The role of experience databases

Many companies try to identify and spread best practices and organisational know-how using databases for storing experiences. The most elaborate form of this kind of database is the ‘experience factory’ described by Basili, Caldiera and Rombach, which is based on the activities of an organisation that collects experiences from projects, re-infuses them in the organisation and analyses their benefits quantitatively.[1] One disadvantage of this type of repository is the high price of maintenance, although certain approaches have been analysed that aim to overcome the problem of cost.[2] Once established, however, experience databases are a good medium through which standards can be deployed. ABB, for example, uses an experience database to deploy a common framework for product development.

Limitations

There are, though, severe limitations with the kind of messages that can be spread with experience databases. Such databases are not suitable for propagating values or rules, for example. Phrased directly, values are too abstract to adopt and also only exist within a specific context. As observed by Cohen and Prusak, values are often established by shared story events.[3] Values are created as lessons learnt from actual events; the lesson learnt loses its effect if the event is removed. When employees share their experiences in an informal setting, they tell anecdotes revealing how problems occurred and were solved, thereby implicitly conveying their values. Classical experience databases are strong in information sharing but weak in sharing contextual events and therefore values.

In addition, experience databases often contain only politically correct success stories, which are hardly a suitable medium for spreading negative experiences. Yet negative experiences are often the key to learning. As Demarco says, we only learn from experience, and mostly from negative experience.[4] The stories spread in Brooks’s classical text are mostly tales of disasters, and Brooks uses this idea of learning from failure in the motto at the beginning of his book: “A ship on the beach is a lighthouse to the sea.”[5]

Changing behaviour

The biggest drawback of experience databases is their inability to change behaviour. Users of an experience database are rarely novices in the corresponding subject area, and as such already exhibit a certain type of behaviour relating to that subject. An experience database does not indicate to the user whether their current working processes are sub-optimal, yet this is a critical step in education and process improvement. Nelson, for example, reports that the most difficult step in re-training programmers in a new paradigm is to make them understand that they are currently not following it.[6] Understanding that one’s current behaviour is wrong is a difficult step for most people, one for which Nelson finds analogies in medical therapy.[7] This obstacle cannot be overcome using non-intrusive, passive solutions such as that offered by an experience database.

Another hurdle is the lack of support provided by experience databases for organisational and cultural change. Once key individuals in a project or organisation are convinced of the necessity to change, a strategy for implementing the process improvement has to be worked out and implemented.[8] This implementation has a cost, however, which is usually not accounted for by the organisation responsible for the formation of the database.

The Storybase project

The power of stories for process improvement

In software engineering, many classical textbooks on process consist of stories [5,9]. These books tell the tales of common failures relating to software engineering in order to prevent readers from repeating the described mistakes. Brooks, for example, tells the story of a project that was hopelessly delayed because new, untrained resources were introduced when the project was already behind schedule. Stories enable learning from failure by describing the scenario in a fictional setting. Thus, as indicated by Snowden, stories offer a way to admit failure and help others avoid mistakes in the politically correct business world.[10] To lift accounts of failure to the corporate level, ‘anonymisation’ is necessary.

Stories also address the other shortcomings of experience databases, as described above – they convey values and rules that cannot be phrased directly. Further, stories address the obstacles to behavioural change mentioned earlier. The recipient of the story is able to identify with the protagonist, at least if the story is told by a credible storyteller. If the story consists of a plausible or even an interesting sequence of events, the recipient will recognise that the problem described actually relates to their own dilemma. The use of story can also address the problem of how to encourage cultural change in an organisation, a prerequisite to sustainable improvement. To achieve such change, the means by which the story will reach the employees in the organisation must be carefully planned. A training strategy to prepare the storyteller must also be established.

Another example of the successful use of a story approach can be found in the area of manufacturing. Goldratt and Cox use the Socratic approach of inductive reasoning to teach their Theory of Constraints.[11] They do this by presenting ideas in the form of a novel about people dealing with the problems managers face at work every day. In the story, Alex Rogo is a plant manager who is continually fighting to meet the requirements of his business. There are ongoing conflicts between marketing, accounting and production in the organisation, but through suggestions from Jonah, a friendly management guru, Rogo learns to identify, manage and overcome the problem areas.

Creating goal-oriented stories

At ABB, we have created a systematic process for the creation of stories for process improvement. This process is an extension and a variant of the story process described by Snowden, adapted to the needs of the company.[12]

In the first phase of the process – initiation – subject areas for story creation are selected. For example, for our pilot project for Storybase we selected software configuration management. In the team definition step, an interdisciplinary team consisting of both subject area experts and story methodology experts is created. The story construction itself consists of an anecdote elicitation phase, where raw material in the form of anecdotes is collected, an analysis phase, where anecdotes are deconstructed, and a construction phase, where stories are created based on the analysis results and the goals to be achieved with the story.

We have mainly used two elicitation techniques: interviews and story circle workshops. Interviewers and facilitators receive formal training on both of these structured techniques before putting them into practice. In an interview, the interviewer motivates a subject area expert to run, step by step, through their memories of successful and failed projects, thereby revealing a number of anecdotes. In contrast, the story circle workshop builds on the interaction among several subject area experts. When one subject area expert tells an anecdote, this triggers the memories of others, who will in turn attempt to tell more and better anecdotes. Using these techniques, we succeeded in collecting more than 30 anecdotes related to software configuration management.

The anecdotes resulting from the interviews are actual stories from a business environment. They are told without a business goal in mind, but implicitly reflect the ways of working, values and rules of the organisation. This implicit knowledge is made explicit in an analysis process called anecdote deconstruction. This in turn yields an information model represented as a database, called the Asset Register, which identifies:

The common themes addressed by the anecdotes;
A structured breakdown of the anecdote’s narrative;
Information on the culture and ways of working of the organisation (values, archetypes, and rules);
The application of different forms of tacit and explicit knowledge in the anecdotes. The analysis identifies the ways in which knowledge is disclosed, for example as part of a decision. It also identifies which knowledge assets are used. Assets are classified based on their representation from explicit (artefacts) to tacit (experiences, natural talent) knowledge. This is embodied in the acronym ASHEN: Artefact, Skill, Heuristic, Experience, Natural talent.

Before the actual stories are constructed from this information model, the intended process change is identified and planned, before being mapped into the organisational context. This is done in the intervention design phase. The planned intervention is supported by teaching stories whose goals are derived from the intervention design. For example, our project aimed to systematically implement configuration management training plans. An intervention was designed to achieve the necessary cultural change, supported by a story that sort to disrupt the myth that configuration management training is unnecessary for software engineers simply because they are technical people who are able to read and understand the relevant manuals themselves.

Once stories and goals are identified, a suitable story form (eg, fable or myth) is selected. Based on the analysis results, the story narrative is then constructed. The analysis results serve to highlight the elements of the anecdotes that support the required values, archetypes and rules, and describe the use of different knowledge sources in the organisation.

Lessons learnt

Although the Storybase approach continues to evolve and mature, we can make the following observations:

Investment in stories is justified by intended improvements to critical business processes or needs. While, depending on the scope, the investment can be high, the return on investment, though hard to measure, can be even higher. In addition, when it comes to capturing the know-how of experienced and retiring engineers, and promoting the adoption of good business practices, no other approach has worked anywhere near as satisfactorily to date;
Stories that disrupt wrong behaviour have proved easier to create and ultimately more effective than stories that promote good behaviour. For instance, we eventually shelved our efforts to write a story to promote the usage of a corporate process model. The story did not add a great deal to existing guidelines on the same topic. On the other hand, we succeeded in developing a powerful story to disrupt the practice of introducing CASE tools before sufficient process and training background could be given. The story describes the failure of a project in introducing a particular piece of configuration management software without systematic training. The story serves to remind the recipient of similar failures of their own, and proves much more powerful than simply issuing a directive to the same effect.
Any story has to be regarded as part of an intervention design. The effect of the story strongly depends on the way the story is delivered to the audience. We have had positive experiences with stories being delivered as ice-breakers at the beginning of symposia and with stories represented as videos. One of our stories, for instance, is now part of a standard ABB training course for describing an actual project and all of its real-world problems. The would-be storyteller also has to be trained in how to deliver the story. At the very least, they should be provided with a script with clear instructions;
Part of the benefit of our approach lies in the by-products of the story process. Chief among these is the Asset Register, while the intense exchange of experiences among participants in the anecdote elicitation phase is also extremely productive;
According to Cohen and Prusak, the trustworthiness of a story is strongly connected to the trustworthiness of the storyteller. We share this observation. We have witnessed a strong correlation between the credibility of the speaker and the impact of the story. Similarly, stories are often best received by the community from which they originated. It has often proved difficult to lift stories to a corporate level, because the political correctness of corporate communications can serve to reduce credibility;
After training and using the structured methods described by Snowden, all project team members were able to produce consistent results in the phases of elicitation and analysis.[10] Further, the selection of story elements from the anecdotes based on specific goals is a learnable step. However, the final formulation of the story and the storytelling approach requires a higher degree of natural talent. For these stages, the help of professional writers/storytellers is highly recommended.

Conclusion

Storybase represents a structured approach for capturing organisational experience and promoting organisational change through the use of stories. Adapted from an existing story technique, it allows us to capture a broad swath of knowledge within the organisation, to represent it in a compact form and to promote it using deliberately constructed goal-oriented stories that are released in carefully planned settings. While the use of stories in an instructional setting is not new, their deliberate use in a corporate setting is. Our experience with this approach has so far been extremely rewarding.

References

1. Basili, V., Caldiera, G. & Rombach, D., ‘The experience factory’ in Marciniak (ed.) Encyclopedia of Software Engineering (Vol. 1, John Wiley & Sons, 1994)

2. Houdek, F., Schneider, K. & Wieser, E., ‘Establishing experience factories at Daimler-Benz: An experience report’ in Proceedings of the 20th International Conference on Software Engineering (1998)

3. Cohen, D. & Prusak, L., In Good Company: How Social Capital Makes Organizations Work (Harvard Business School Press, 2001)

4. Demarco, T. & Lister, T., Peopleware: Productive Projects and Teams (2nd ed., Dorset House, 1999)

5. Brooks, F., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (Addison-Wesley, 1999)

6. Nelson, H. J. and Armstrong, D., ‘Old dogs and new tricks: Retraining legacy programmers in object-oriented technology’, Proceedings of the Information Resources Management Association (2000)

7. Johnson, V., Intervention: How to Help Someone Who Doesn’t Want Help – A Step-by-Step Guide for Families of Chemically Dependent Persons (Johnson Inst., 1989)

8. Kaltio, T., & Kinnula, A., ‘Deploying the defined SW process’ in Software Process: Improvement and Practice (Vol. 5, No. 1, John Wiley & Sons, March 2000)

9. Demarco, T., The Deadline: A Novel About Project Management (Dorset House, 1997)

10. Snowden, D., ‘Storytelling for the capture and communication of tacit knowledge’ in Business Information Review (Spring 1999)

11. Goldratt, E. & Cox, J., The Goal: A Process of Ongoing Improvement (North River Press, 1992)

12. Snowden, D., ‘The paradox of story’ in Scenario & Strategy Planning (Vol. 1 Iss. 5, Ark Group, December 1999/January 2000)

Peter Fröhlich is manager of the Industrial IT and Software Technology Group, Corporate Research Centre, ABB Group R&D. He can be contacted at: peter.froehlich@de.abb.com

Harsh Karandikar is global lab manager, Global R&D Lab for Engineering and Manufacturing, ABB Group R&D. He can be contacted at: harsh.karandikar@de.abb.com