Archive for the ‘Tacit Knowledge’ Category
What is the make of that car? A tale about tacit knowledge
My son’s fascination with cars started early: the first word he uttered wasn’t “Mama” or “Dada”, it was “Brrrm.”
His interest grew with him; one of the first games we played together as a family was “What’s the make of that car?” – where his mum or I would challenge him to identify the make of a car that had just overtaken us when we were out driving. The first few times we’d have to tell him what a particular car was (he couldn’t read yet), but soon enough he had a pretty good database in his little head. Exchanges like the following became pretty common:
“So what’s that one Rohan?”
“Mitsubishi Magna, Dad”
“Are you sure?”
“Yes, it is Mitsubishi,” he’d assert, affronted that I would dare question his ability to identify cars.
He was sometimes wrong about the model (and his mum would order me not to make an issue of it). More often than not, though, he’d be right. Neither his mum nor I are car enthusiasts, so we just assumed he figured it out from the logo and / or the letters inscribing the make on the boot.
Then one day we asked him to identify a car that was much too far away for him to be able to see letters or logos. Needless to say, he got it right…
Astounded, I asked, “Did you see the logo when the car passed us?”
“No Dad”
“How did you know then?”
“From the shapes, of course?” As though it were the most obvious thing in the world.
“What shapes?” I was truly flummoxed.
“All cars have different shaped lights and bumpers and stuff.” To his credit, he refrained from saying, didn’t you know that.
“Ah, I see…”
But I didn’t really. Somehow Rohan had intuitively figured out that specific makes and models have unique tail-light, boot and bumper designs. He understood, or knew, car makes and models in a completely different way than we did – his knowledge of cars was qualitatively different from ours.
(I should make it clear that he picked up this particular skill because he enjoys learning about cars; he is, therefore, intrinsically motivated to learn about them. In most other areas his abilities are pretty much in line with kids his age)
—
Of course, the cognoscenti are well aware that cars can be identified by their appearance. I wasn’t, and neither was my dear wife. Those who know cars can identify the make (and even the model) from a mere glance. Moreover, they can’t tell you exactly how they know, they just know – and more often than not they’re right.
This incident came back to me recently, as I was reading Michael Polanyi’s book, The Tacit Dimension, wherein he explains his concept of tacit knowledge (which differs considerably from what it has come to mean in mainstream knowledge management). The basic idea is that we know more than we can tell; that a significant part of our knowledge cannot be conveyed to others via speech or writing. At times we may catch a glimpse of it when the right questions are asked in the right context, but this almost always happens by accident rather than plan. We have to live with the fact that it is impossible for me to understand something you know in the same way that you do. You could explain it to me, I could even practice it under your guidance, but my understanding of it will never be the same as yours.
My point is this: we do not and cannot fully comprehend how others understand and know things, except through fortuitous occurrences. If this is true for a relatively simple matter like car makes and models, what implications does it have for more complex issues that organisations deal with everyday? For example: can we really understand a best practice in the way that folks in the originating organisation do? More generally, are our present methods of capturing and sharing insights (aka Knowledge Management) effective?
Why best practices are hard to practice (and what can be done about it)
Introduction
In a recent post entitled, Why Best Practices Are Hard to Practice, Ron Ashkenas mentions two common pitfalls that organisations encounter when implementing best practices. These are:
- Lack of adaptation: this refers to a situation in which best practices are applied without customizing them to an organisation’s specific needs.
- Lack or adoption: this to the tendency of best practice initiatives to fizzle out due to lack of adoption in the day-to-day work of an organisation.
Neither point is new: several practitioners and academics have commented on the importance adaptation and adoption in best practice implementations (see this article from 1997, for example). Despite this, organisations continue to struggle when implementing best practices, which suggests a deeper problem. In this post, I explore the possibility that problems of adaptation and adoption arise because much of the knowledge relevant to best practices is tacit – it cannot be codified or captured via symbolic systems (such as writing) or speech. This “missing” tacit knowledge makes it difficult to adapt and adopt practices in a meaningful way. All is not lost, though: best practices can be useful as long as they are viewed as templates or starting points for discussion, rather than detailed prescriptions that are to be imitated uncritically.
The importance of tacit knowledge
Michael Polanyi’s aphorism – “We can know more than we can tell’ – summarises the difference between explicit and tacit knowledge : the former refers to what we can “tell” (write down, or capture in some symbolic form) whereas the latter are the things we know but cannot explain to others via writing or speech alone.
The key point is: tacit knowledge is more relevant to best practices than its explicit counterpart.
“Why?” I hear you ask.
Short Answer: Explicit knowledge is a commodity that can be bought and sold, tacit knowledge isn’t. Hence it is the latter that gives organisations their unique characteristics and competencies.
For a longer answer, I’ll quote from a highly-cited paper by Maskell and Malmberg entitled, Localised Learning and Industrial Competitiveness:
It is a logical and interesting – though sometimes overlooked – consequence of the present development towards a knowledge-based economy, that the easier codified (tradeable) knowledge is accessed, the more significant becomes tacit knowledge for sustaining the heterogeneity of the firm’s resources. If all factors of production, all organisational blue-prints, all market-information and all production technologies were readily available in all parts of the world at (more or less) the same price, economic progress would dwindle. Resource heterogeneity is the very foundation for building firm specific competencies and thus for variations between firms in their competitiveness. Resource heterogeneity fuels the market process of selection between competing firms
Tacit knowledge thus confers a critical advantage on firms. It is precisely this knowledge that distinguishes firms from each other and sets the “best” (however one might choose to define that) apart from the rest. It is the knowledge that best practices purport to capture, but can’t.
Transferring tacit knowledge
The transfer of tacit knowledge is an iterative and incremental process: apprentices learn by practice, by refining their skills over time. Such learning requires close interaction between the teacher and the taught. Communication technology can obviate the need for some face-to-face interaction but he fact remains that proximity is important for effective transfer of tacit knowledge. In the words of Maskell and Malmberg:
The interactive character of learning processes will in itself introduce geographical space as a necessary dimension to take into account. Modern communications technology will admittedly allow more of long distance interaction than was previously possible. Still, certain types of information and knowledge exchange continue to require regular and direct face-to-face contact. Put simply, the more tacit the knowledge involved, the more important is spatial proximity between the actors taking part in the exchange. The proximity argument is twofold. First, it is related to the time geography of individuals. Everything else being equal, interactive collaboration will be less costly and more smooth, the shorter the distance between the participants. The second dimension is related to proximity in a social and cultural sense. To communicate tacit knowledge will normally require a high degree of mutual trust and understanding, which in turn is related not only to language but also to shared values and ‘culture’.
The main point to take away from their argument is that proximity is important for effective transfer of tacit knowledge. The individuals involved need to be near each other geographically (shared space, face-to-face) and culturally (shared values and norms). By implication, this is also the only way to transfer best practice knowledge.
Discussion
Best practices, by definition, aim to capture knowledge that enables successful organizations be what they are. As we have seen above, much of this knowledge is tacit: it is context and history dependent, and requires physical/cultural proximity for effective transfer. Further, it is hard to extract, codify and transfer such knowledge in a way that makes sense outside its original setting. In light of this, it is easy to understand why adapting and adopting best practices is hard: it is hard because best practices are incomplete – they omit important elements (the tacit bits that can’t be written down). Organisations have to (re)discover these in their own way. The explicit and (re-discovered) tacit elements then need to be integrated into new workplace practices that are necessarily different from standardised best practices. This makes the new practices unique to the implementing organisation.
The above suggests that best practices should be seen as starting points – or “bare bones” templates – for transforming an organisation’s work practices. I have made this point in an earlier post in which I reviewed this paper by Jonathan Wareham and Hans Cerrits. Quoting from that post:
[Wareham and Cerrits] suggest an expanded view of best practices which includes things such as:
- Using best practices as guides for learning new technologies or new ways of working.
- Using best practices to generate creative insight into how business processes work in practice.
- Using best practices as a guide for change – that is, following the high-level steps, but not necessarily the detailed prescriptions.
These are indeed sensible and reasonable statements. However, they are much weaker than the usual hyperbole-laden claims that accompany best practices.
The other important implication of the above is that successful adoption of organisational practices is possible only with the active involvement of front-line employees. “Active” is the operative word here, signifying involvement and participation. One of the best ways to get involvement is to seek and act on employee opinions about their day-to-day work practices. Best practices can serve as templates for these discussions. Participation can be facilitated through the use of collective deliberation techniques such as dialogue mapping.
Wrap-up
Best practices have long been plagued by problems of adaptation and adoption. The basic reason for this is that much of the knowledge pertaining to practices is tacit and cannot be transferred easily. Successful implementation requires that organisations use best practices as templates to build on rather than prescriptions to be followed to the letter. A good way to start this process is through participatory design discussions aimed at filling in the (tacit) gaps. These discussions should be conducted in a way that invites involvement of all relevant stakeholders, especially those who will work with and be responsible for the practices. Such an inclusive approach ensures that the practices will be adapted to suit the organisation’s needs. Further, it improves the odds of adoption because it incorporates the viewpoints of the most important stakeholders at the outset.
Paul Culmsee and I are currently working on a book that describes such an approach that goes “beyond best practices”. See this post for an excerpt from the book (and this one for a rather nice mock-up cover!)
Building project knowledge – a social constructivist view
Introduction
Conventional approaches to knowledge management on projects focus on the cognitive (or thought-related) and mechanical aspects of knowledge creation and capture. There is alternate view, one which considers knowledge as being created through interactions between people who – through their interactions – develop mutually acceptable interpretations of theories and facts in ways that suit their particular needs. That is, project knowledge is socially constructed. If this is true, then project managers need to pay attention to the environmental and social factors that influence knowledge construction. This is the position taken by Paul Jackson and Jane Klobas in their paper entitled, Building knowledge in projects: A practical application of social constructivism to information systems development, which presents a knowledge creation / sharing process model based social constructivist theory. This article is a summary and review of the paper.
A social constructivist view of knowledge
Jackson and Klobas begin with the observation that engineering disciplines are founded on the belief that knowledge can be expressed in propositions that correspond to a reality which is independent of human perception. However, there is an alternate view that knowledge is not absolute, but relative – i.e. it depends on the mental models and beliefs used to interpret facts, objects and events. A relevant example is how a software product is viewed by business users and software developers. The former group may see an application in terms of its utility whereas the latter may see it as an instance of a particular technology. Such perception gaps can also occur within seemingly homogenous groups – such as teams comprised of software developers, for example. This can happen for a variety of reasons such as the differences in the experience and cultural backgrounds of those who make up the group. Social constructivism looks at how such gaps can be bridged.
The authors’ discussion relies on the work of Berger and Luckmann, who described how the gap between perceptions of different individuals can be overcome to create a socially constructed, shared reality. The phrase “socially constructed” implies that reality (as it pertains to a project, for example) is created via a common understanding of issues, followed by mutual agreement between all the players as to what comprises that reality. For me this view strikes a particular chord because of it is akin to the stated aims of dialogue mapping, a technique that I have described in several earlier posts (see this article for an example relevant to projects).
Knowledge in information systems development as a social construct
First up, the authors make the point that information systems development (ISD) projects are:
…intensive exercises in constructing social reality through process and data modeling. These models are informed with the particular world-view of systems designers and their use of particular formal representations. In ISD projects, this operational reality is new and explicitly constructed and becomes understood and accepted through negotiated agreement between participants from the two cultures of business and IT
Essentially, knowledge emerges through interaction and discussion as the project proceeds. However, the methodologies used in design are typically founded on an engineering approach, which takes a positivist view rather than a social one. As the authors suggest,
Perhaps the social constructivist paradigm offers an insight into continuing failure, namely that what is happening in an ISD project is far more complex than the simple translation of a description of an external reality into instructions for a computer. It is the emergence and articulation of multiple, indeterminate, sometimes unconscious, sometimes ineffable realities and the negotiated achievement of a consensus of a new, agreed reality in an explicit form, such as a business or data model, which is amenable to computerization.
With this in mind, the authors aim to develop a model that addresses the shortcomings of the traditional, positivist view of knowledge in ISD projects. They do this by representing Berger and Luckmann’s theory of social constructivism in terms of a knowledge process model. They then identify management principles that map on to these processes. These principles form the basis of a survey which is used as an operational version of the process model. The operational model is then assessed by experts and tested by a project manager in a real-life project.
The knowledge creation/sharing process model
The process model that Jackson and Klobas describe is based on Berger and Luckmann’s work.
Figure 1: Knowledge creation/sharing model
The model describes how personal knowledge is created – personal knowledge being what an individual knows. Personal knowledge is built up using mental models of the world – these models are frameworks that individuals use to make sense of the world.
According to the Jackson-Klobas process model, personal knowledge is built up through a number of process including:
Internalisation: The absorption of knowledge by an individual
Knowledge creation: The construction of new knowledge through repetitive performance of tasks (learning skills) or becoming aware of new ideas, ways of thinking or frameworks. The latter corresponds to learning concepts and theories, or even new ways of perceiving the world. These correspond to a change in subjective reality for the individual.
Externalisation: The representation and description of knowledge using speech or symbols so that it can be perceived and internalized by others. Think of this as explaining ideas or procedures to other individuals.
Objectivation: The creation of a shared constructs that represent a group’s understanding of the world. At this point, knowledge is objectified – and is perceived as having an existence independent of individuals.
Legitimation: The authorization of objectified knowledge as being “correct” or “standard.”
Reification: The process by which objective knowledge assumes a status that makes it difficult to change or challenge. A familiar example of reified knowledge is any procedure or process that is “hardened” into a system – “That’s just the way things are done around here,” is a common response when such processes are challenged.
The links depicted in the figure show the relationships between these processes.
Jackson and Klobas suggest that knowledge creation in ISD projects is a social process, which occurs through continual communication between the business and IT. Sure, there are other elements of knowledge creation – design, prototyping, development, learning new skills etc. – but these amount to nought unless they are discussed, argued, agreed on and communicated through social interactions. These interactions occur in the wider context of the organization, so it is reasonable to claim that the resulting knowledge takes on a form that mirrors the social environment of the organization.
Clearly, this model of knowledge creation is very different from the usual interpretation of knowledge having an independent reality, regardless of whether it is known to the group or not.
An operational model
The above is good theory, which makes for interesting, but academic, discussions. What about practice? Can the model be operationalised? Jackson and Klobas describe an approach to creating to testing the utility (rather than the validity) of the model. I discuss this in the following sections.
Knowledge sharing heuristics
To begin with, they surveyed the literature on knowledge management to identify knowledge sharing heuristics (i.e. experience-based techniques to enable knowledge sharing). As an example, some of the heuristics associated with the externalization process were:
- We have standard documentation and modelling tools which make business requirements easy to understand
- Stakeholders and IS staff communicate regularly through direct face-to-face contact
- We use prototypes
The authors identified more than 130 heuristics. Each of these was matched with a process in the model. According to the authors, this matching process was simple: in most cases there was no doubt as to which process a heuristic should be attached to. This suggests that the model provides a natural way to organize the voluminous and complex body of research in knowledge creation and sharing. Why is this important? Well, because it suggests that the conceptual model (as illustrated in Fig. 1) can form the basis for a simple means to assess knowledge creation / sharing capabilities in their work environments, with the assurance that they have all relevant variables covered.
Validating the mapping
The validity of the matching was checked using twenty historical case studies of ISD projects. This worked as follows: explanations for what worked well and what didn’t were mapped against the model process areas (using the heuristics identified in the prior step). The aim was to answer the question: “is there a relationship between project failure and problems in the respective knowledge processes or, conversely, between project success and the presence of positive indicators?”
One of the case studies the authors use is the well-known (and possibly over-analysed) failure of the automated dispatch system for the London Ambulance Service. The paper has a succinct summary of the case study, which I reproduce below:
The London Ambulance Service (LAS) is the largest ambulance service in the world and provides accident and emergency and patient transport services to a resident population of nearly seven million people. Their ISD project was intended to produce an automated system for the dispatch of ambulances to emergencies. The existing manual system was poor, cumbersome, inefficient and relatively unreliable. The goal of the new system was to provide an efficient command and control process to overcome these deficiencies. Furthermore, the system was seen by management as an opportunity to resolve perceived issues in poor industrial relations, outmoded work practices and low resource utilization. A tender was let for development of system components including computer aided dispatch, automatic vehicle location, radio interfacing and mobile data terminals to update the status of any call-out. The tender was let to a company inexperienced in large systems delivery. Whilst the project had profound implications for work practices, personnel were hardly involved in the design of the system. Upon implementation, there were many errors in the software and infrastructure, which led to critical operational shortcomings such as the failure of calls to reach ambulances. The system lasted only a week before it was necessary to revert to the manual system.
Jackson and Klobas show how their conceptual model maps to knowledge-related factors that may have played a role in the failure project. For example, under the heading of personal knowledge, one can identify at least two potential factors: lack of involvement of end-users in design and selection of an inexperienced vendor. Further, the disconnect between management and employees suggests a couple of factors relating to reification: mutual negative perceptions and outmoded (but unchallenged) work practices.
From their validation, the authors suggest that the model provides a comprehensive framework that explains why these projects failed. That may be overstating the case – what’s cause and what’s effect is hard to tell, especially after the fact. Nonetheless, the model does seem to be able to capture many, if not all, knowledge-related gaps that could have played a role in these failures. Further, by looking at the heuristics mapped to each process, one might be able to suggest ways in which these deficiencies could have been addressed. For example, if externalization is a problem area one might suggest the use of prototypes or encourage face to face communication between IS and business personnel.
Survey-based tool
Encouraged by the above, the authors created a survey tool which was intended to evaluate knowledge creation/sharing effectiveness in project environments. In the tool, academic terms used in the model were translated into everyday language (for example, the term externalization was translated to knowledge sharing – see Fig 1 for translated terms). The tool asked project managers to evaluate their project environments against each knowledge creation process (or capability) on a scale of 1 to 10. Based on inputs, it could recommend specific improvement strategies for capabilities that were scored low. The tool was evaluated by four project managers, who used it in their work environment over a period of 4-6 weeks. At the end of the period, they were interviewed and their responses were analysed using content analysis to match their experiences and requirements against the designed intent of the tool. Unfortunately, the paper does not provide any details about the tool, so it’s difficult to say much more than paraphrase the authors comments.
Based on their evaluation, the authors conclude that the tool provides:
- A common framework for project managers to discuss issues pertaining to knowledge creation and sharing.
- A means to identify potential problems and what might be done to address them.
Field testing
One of the evaluators of the model tested the tool in the field. The tester was a project manager who wanted to identify knowledge creation/sharing deficiencies in his work environment, and ways in which these could be addressed. He answered questions based on his own evaluation of knowledge sharing capabilities in his environment and then developed an improvement plan based on strategies suggested by the tool along with some of his own ideas. The completed survey and plan were returned to the researchers.
Use of the tool revealed the following knowledge creation/sharing deficiencies in the project manager’s environment:
- Inadequate personal knowledge.
- Ineffective externalization
- Inadequate standardization (objectivation)
Strategies suggested by the tool include:
- An internet portal to promote knowledge capture and sharing. This included discussion forums, areas to capture and discuss best practices etc.
- Role playing workshops to reveal how processes worked in practice (i.e. surface tacit knowledge).
Based on the above, the authors suggest that:
- Technology can be used to promote support knowledge sharing and standardization, not just storage.
- Interventions that make tacit knowledge explicit can be helpful.
- As a side benefit, they note that the survey has raised consciousness about knowledge creation/sharing within the team.
Reflections and Conclusions
In my opinion, the value of the paper lies not in the model or the survey tool, but the conceptual framework that underpins them – namely, the idea knowledge depends on, and is shaped by, the social environment in which it evolves. Perhaps an example might help clarify what this means. Consider an organisation that decides to implement project management “best practices” as described by <fill in any of the popular methodologies here>. The wrong way to do this would be to implement practices wholesale, without regard to organizational culture, norms and pre-existing practices. Such an approach is unlikely to lead to the imposed practices taking root in the organisation. On the other hand, an approach that picks the practices that are useful and tailors these to organizational needs, constraints and culture is likely to meet with more success. The second approach works because it attempts to bridge gap between the “ideal best practice” and social reality in the organisation. It encourages employees to adapt practices in ways that make sense in the context of the organization. This invariably involves modifying practices, sometimes substantially, creating new (socially constructed!) knowledge in the bargain.
Another interesting point the authors make is that several knowledge sharing heuristics (130, I think the number was) could be classified unambiguously under one of the processes in the model. This suggests that the model is a reasonable view of the knowledge creation/sharing process. If one accepts this conclusion, then the model does indeed provide a common framework for discussing issues relating knowledge creation in project environments. Further, the associated heuristics can help identify processes that don’t work well.
I’m unable to judge the usefulness of the survey-based tool developed by the authors because they do not provide much detail about it in the paper. However, that isn’t really an issue; the field of project management has too many “tools and techniques” anyway. The key message of the paper, in my opinion, is the that every project has a unique context, and that the techniques used by others have to be interpreted and applied in ways that are meaningful in the context of the particular project. The paper is an excellent counterpoint to the methodology-oriented practice of knowledge management in projects; it should be required reading for methodologists and project managers who believe that things need to be done by The Book, regardless of social or organizational context.
Eight to Late 