Eight to Late

Sensemaking and Analytics for Organizations

Archive for November 2010

Why best practices are hard to practice (and what can be done about it)

with 14 comments


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:

  1. Lack of adaptation:  this refers to a situation in which best practices  are applied without customizing them to an organisation’s specific needs.
  2. 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.


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:

  1. Using best practices as guides for learning new technologies or new ways of working.
  2. Using best practices to generate creative insight into how business processes work in practice.
  3. 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.


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!)

Written by K

November 18, 2010 at 11:45 pm

A social constructionist perspective on software development projects

leave a comment »


Many new product development (NPD) projects are subject to unpredictable effects which can be hard to control. Examples of these include: requirements changes, changes in personnel, shifting business needs etc. Moreover, in the early stages of  projects, there is often a great deal of uncertainty as to what exactly needs to be done. Many project management methodologies tend to conceptualise NPD projects as well defined efforts that can be decomposed into discrete tasks which can then be planned and directed (see this paper review, for example). This conceptualization – or more correctly, assumption – accords software development projects a solidity and certainty that they do not have. In a paper entitled, Towards a (more) critical and social constructionist approach to new product development projects, Beata Segercrantz looks into how NPD projects  – specifically, software development projects – can be viewed usefully as entities that emerge from relationships and interactions between various project stakeholders. This post is a review of the paper.

Segercrantz views NPD projects as constructed by discourse – i.e. through dialogue and interactions between all stakeholders. In sociology this is termed as a constructionist view, one in which knowledge of an entity (in this case, a project) and the identities of those involved in or with it (the stakeholders)  is seen as being produced through conversations and interactions between those involved in creating the entity. This approach necessarily results in multiple views,  reflecting the that reality  no two stakeholders will have the same conception of the project. In such a view, voices that are marginalized by the traditional project-as-well-defined-entity  view are given equal air time. This is useful because it can unearth viewpoints and insights that would otherwise be missed.


The best known NPD methodology is the Stage-Gate approach, which views the product development process as moving through Scoping,  Build Business Case,  Development, Testing and Validation and Launch. The stages of discovery and post-launch review are considered to be outside the traditional stage-gate model. Although recent references on the methodology  emphasise its flexibility and customizability (see this paper, for instance),  it remains at heart a process-based approach to NPD. Segercrantz draws attention to research which suggests that the stage-gate approach, with its early lock-in of product definition, may be too constraining for technology projects, which tend to take place in highly changeable environments (see this paper, for example).  More flexible approaches involving overlapping stages which, in effect, allow changes to product definition at later stages are necessary. But these dilute the benefits of the stage-gate approach, the main loss being certainty of commitments and the costs that go with it.

The problem with mainstream NPD methodologies is that they are too prescriptive (whilst claiming to be flexible).  Further, in areas where flexibility is claimed, they actually end up delegating much of the management detail  to other, unspecified project management processes. This gives the illusion of flexibility.  Further – and more important, in my opinion – is that they do not address the process of  discovery. They only address what comes after.  This, of course, would be a problem for any process because it is impossible to prescribe a method that would lead to useful discoveries. However, this  is a shortcoming that isn’t entirely clear in accounts that describe popular NPD methodologies.

Mainstream NPD methodologies focus on reducing product development costs and time to market, whilst ensuring product quality. Their preoccupations, quite naturally, are all about specifying the processes that will enable organisations to achieve these goals. Their approach is, also  quite naturally, rational.  However, such an approach, which focuses on best practice and standardization ignores the human element.  To quote from the paper,

…much mainstream NPD literature presupposes that improved models of NPD processes and projects are likely to lead to progress. Through increased empirical knowledge about different characteristics of NPD, it is assumed that structures of the world, including NPD, can be found; structures that leave little space for margins or deviation from rules of reason. Only increased precise predictions are assumed to produce effective NPD projects and formulating the predictions requires ‘finding’ a single best account or sometimes a limited number of related accounts. The prescriptive accounts in mainstream NPD models, however, pay little attention to various consequences of the models on individuals… Complex ways in which individuals respond to dominant discourses of organizations seem to be under-explored…

Segercrantz’s research is aimed at exploring some of the human elements of NPD projects, specifically how certain voices are shut out of the decision making process thus precluding some outcomes that could otherwise have occurred.

Projects – from being to becoming

In the traditional view, a project is seen as a well-defined organizational entity that has an existence independent of the people who work on it. Real-world interactions between people (the real organisation, if you will) are considered to be secondary. This view is cart-before-horse because, in reality, the project is a consequence of organizing  (by the people who comprise the project).  So, projects do not have an independent existence, they are brought into being by a process of organizing – i.e. they are socially constructed.

To understand how relationships and interactions create projects, one has to move beyond the traditional view. As Segercrantz puts it,

…our attention shifts towards complex social processes that software product development experts engage in; the interactions and relational processes that take place between them. Through these processes, projects are socially constructed and come into existence as they are attributed with specific meanings. How the product development processes interactively unfold and construct certain shared understanding of NPD and not others are emphasized. These actions are continuous and thus meanings attributed to projects are more or less constantly modified as the actors participate in NPD. Meanings are therefore always in a state of becoming, never fixed, and should be understood as primarily culturally and historically specific. In sum, by engaging in certain process, actors seek to construct stabilized meanings of NPD but, simultaneously, as they participate in these projects various meanings are modified…

To develop a social constructionist view, one has to rely on discourse analysis, which essentially entails understanding what people actually  say and do,  rather than what they ought to be saying and doing.  The point is, what people actually say and do on a specific project to a large extent defines what the project is and how it is to work on it.  Further, it is also important to note that certain discursive possibilities are excluded because not everyone on the project is equal –  some voices are marginalized because of their subordinate position in the project and/or organisational hierarchy.

So, where do traditional NPD methodologies fit in the discursive scheme of things? Segercrantz suggests that NPD processes and procedures should be seen as discursive templates which can be used as starting points from which one can develop new ways of understanding and running specific projects.  This is the reality anyway, because best practices are almost always hacked up to suit specific organizational and project needs. Moreover, the changes needed are most often decided via social interactions – i.e. discourse.

The method

Best practices and methodologies presume there is a right way to do things. Consequently, studies that focus on these tend to give more weight to opinions that support the practice/methodology whilst ignoring contrary views.   One of the key benefits of discourse analysis is that it can expose some of these hidden views. In the best case, this can offer up new possibilities for how NPD projects can be run. In Segercrantz’s words:

By unmasking the becoming of certain effects, we can produce new alternatives for the future. This objective sharply contrast to much mainstream NPD literature, which typically aims at formulating one or limited prescriptive options for the future to produce preferred effects.

Segercrantz mentions the difference between critical and analytical approaches to discourse analysis: the former views interactions through the lens of political/social power relationships (i.e. they assume certain stakeholders are more powerful than others) whereas the latter make no such assumptions. The approaches are not mutually exclusive, both can and should be used in discursive studies. Segercrantz  uses both approaches: the former to make inferences from the data she gathers and the latter to interpret data in terms of power relationships.

The raw data for the study consisted of over 80 interviews with professionals working in Finnish software companies. In the paper, Segercrantz provides illustrative examples of data drawn from interviews with 6 development professionals within a single company. She notes that when analyzing the data, she initially made no assumptions about relationships (i.e. she used an analytical approach) and made inferences about different organizing patterns based on the data alone. After that, she examined power relations using a critical approach.

The case study

The software company studied was continually engaged in NPD projects. Segercrantz sought the views of development professionals within the organisations. Here’s what one of them had to say:

The process, according to my view, began as the person who is pulling the strings, the major guru, who sort of leads the product development, he has a long history, he has seen many products, he has even seen many versions of this product [under development], that is, of financial portfolio systems. He has seen many financial portfolio system products and systems related to them. Based on this experience he has probably during the years developed a vision and he also happens to be, let’s say quite an intelligent person. Somehow he can keep all these things in his head, it helps. And then he probably got a green light from someone to begin developing his idea. In my view, it has been lead from one head. … Each [team member] has had a very narrow scope in it [the NPD project]. One hasn’t let them intervene in everything. Instead they have been, well, let’s say that their scope has been kept narrow with dictatorial means. It is maybe doubtful in a social sense, but on the other hand it has given good results. That is, a product has been created. And if you would start messing a lot outside your own scope, then you would suffocate very soon. It has worked in this case. Perhaps everyone has respected it. There has been a leadership style that is efficient in my opinion.

Several interesting points emerge from the above:

  1. Product development was organized according to a process that evolved over time rather than a best practice template.
  2. The project leader was in a position of power, and was portrayed  as (or constructed as) a “major guru ” hence legitimizing his right to decree how things should be done and who should do them. Implicitly, the others were portrayed as having less experience and knowledge, and their opinions could thus be ignored.
  3. The interviewees emphasized that they had well defined but narrow roles.

In addition, from other interviews it emerged that:

  1. The interviewees were in positions where they had to comply with rules set from those higher up in the hierarchy, but they also had to set direction and delegate to those who were below them.
  2. The delegation process had a political aspect to it: delegating work to others also involved convincing them to do it in a prescribed way, following certain rules. This wasn’t a straightforward process. This was the cause of a fair bit of stress.

Segercrantz makes the point that the NPD model shaped and used by the leader served as a discursive template via which others in the project interpreted their experiences and roles.  This can be seen as an exercise of positional power.  In contrast, the others took up “narrowly defined subject positions offered in discourse and were ‘locked’ into a structure of rights (and obligations) that addressed them as ‘communicators’ and instruction-followers.” However, although the project was run “dictatorially”, the others were able to (had to!) modify (customize) the template in order to get the job done.  Some of them also made sense of (or rationalized) their positions within the project and firm via the template , even though they felt disempowered. As Segercrantz states:

The interviewee cited in the beginning of this section seems to dis-identify with the subject positions offered through the seemingly institutionalized ‘dictatorial’ ways of organizing projects. However, he still performed his obligations and even defended the practices by claiming ‘it has given good results’ and ‘there has been a leadership style that is efficient’, thus legitimizing the relations of power. In contrast, another interviewee explicitly seemed to identify, at least in certain local conditions, with the subject positions offered; working under time pressure functioned as an important means through which he was constructed as ‘a person who is needed by the company


The paper puts forward a very interesting perspective on how projects can be viewed as socially constructed. Seen in this light, projects don’t have an existence independent of the people and relationships that comprise them. This questions the universality of popular approaches to project management, all of which assume that the project is an organisational entity that can be managed via standardised processes that pay scant attention to human relationships. That said, I found the case study very disappointing because it is too limited, and does not make a convincing case for the validity of the theoretical framework proposed.  Thus, in my opinion, the value of the study lies in the questions it raises, not those that it answers.

Written by K

November 11, 2010 at 10:40 pm

The Abilene paradox in front-end decision-making on projects

with 2 comments

The Abilene paradox refers to a situation in which a group of people make a collective decision that is counter to the preferences or interests of everyone in the group. The paradox was first described by Jerry Harvey, via a story that is summarised nicely in the Wikipedia article on the topic. I reproduce the story verbatim below:

On a hot afternoon in Coleman, Texas, the family is comfortably playing dominoes on a porch, until the father-in-law suggests that they take a trip to Abilene [53 miles north] for dinner. The wife says, “Sounds like a great idea.” The husband, despite having reservations because the drive is long and hot, thinks that his preferences must be out-of-step with the group and says, “Sounds good to me. I just hope your mother wants to go.” The mother-in-law then says, “Of course I want to go. I haven’t been to Abilene in a long time.”

The drive is hot, dusty, and long. When they arrive at the cafeteria, the food is as bad as the drive. They arrive back home four hours later, exhausted.

One of them dishonestly says, “It was a great trip, wasn’t it?” The mother-in-law says that, actually, she would rather have stayed home, but went along since the other three were so enthusiastic. The husband says, “I wasn’t delighted to be doing what we were doing. I only went to satisfy the rest of you.” The wife says, “I just went along to keep you happy. I would have had to be crazy to want to go out in the heat like that.” The father-in-law then says that he only suggested it because he thought the others might be bored.

The group sits back, perplexed that they together decided to take a trip which none of them wanted. They each would have preferred to sit comfortably, but did not admit to it when they still had time to enjoy the afternoon.

Harvey contends that variants of this story play out over and over again in corporate environments. As he states in this paper, organizations frequently take actions in contradiction to what they really want to do and therefore defeat the very purposes they are trying to achieve.

The Abilene paradox is  essentially a consequence of the failure to achieve a shared understanding of a problem before deciding on a solution.  A case in point is Nokia’s ill-judged restructuring circa 2003, initiated in response to the rapidly changing mobile phone market.

Prior to the restructure, Nokia was a product-oriented company that focused on developing one or two new phone models per year. Then, as quoted by an employee in an article published in Helsingin Sanomat (A Finnish daily), Nokia management deemed that: “Two new models a year was no longer enough, but there was a perceived need to bring out as many as 40 or 50 models a year… An utterly terrifying number.”  Company management knew that it would be impossible to churn out so many models under the old, product-focused structure. So they decided to reorganise the company into different divisions comprising of teams dedicated to creating standard components (such as cameras), the idea being that standard components could be mixed-and-matched into several “new”  phone models every year .

The restructuring and its consequences are described in this article as follows:

[The] re-organisation split Nokia’s all-conquering mobile phones division into three units. The architect was Jorma Ollila, Nokia’s most successful ever CEO, and a popular figure – who steered the company from crisis in 1992 to market leadership in mobile phones – and who as chairman oversaw the ousting of Olli-Pekka Kallasvuo this year [i.e 2010].

In Ollila’s reshuffle, Nokia made a transition from an agile, highly reactive product-focused company to one that managed a matrix, or portfolio. The phone division was split into three: Multimedia, Enterprise and Phones, and the divisions were encouraged to compete for staff and resources. The first Nokia made very few products to a very high standard. But after the reshuffle, which took effect on 1 January 2004, the in-fighting became entrenched, and the company being increasingly bureaucratic. The results were pure Dilbert material.

That the Nokia restructure was possibly a  “trip to Abilene” is suggested by the following excerpt from an interview with a long-time Nokia employee  (see part IV of the Helsingin Salomat article):

…Even CEO Jorma Ollila was less than enthusiastic about the heavy organisational structure, and recognised perfectly well that it was making Nokia stiff and sluggish in its movements. In their time, Ollila’s views made it all the way down to the factory floor.

But was it not Jorma Ollila himself who created the organisation he led?
“Yes”, replies the woman.

Ollila’s unwavering line was to allow his subordinates freedom, to trust them without tight controls. In this way the then leaders of the business units like Mobile Phones and Multimedia could recruit whom they wanted. And in so doing the number of managers at all levels mushroomed to enormous proportions and the product development channels became clogged…

Management actions aimed at shoring up and boosting Nokia’s market share ended up achieving just the opposite, and the  irony is that the restructure did not even have the whole-hearted support of management.

Like the Nokia restructuring effort, most projects are  initiated  in response to a perceived problem. Often times, those responsible for giving the project the go-ahead do not have an adequate appreciation of the problem or the proposed solution. As I have stated in an earlier post:

Many high profile projects fail because they succeed. This paradoxical statement is true because many projects are ill-conceived efforts directed at achieving goals that have little value or relevance to their host organisations.  Project management focuses on ensuring that the project goals are achieved in an efficient manner. The goals themselves are often “handed down from above”, so the relevance or appropriateness of these is “out of scope” for the discipline of project management.  Yet, the prevalence of projects of dubious value suggests that more attention needs to be paid to “front-end” decision making in projects – that is, decision making in the early stages, in which the initiative is just an idea.

Front-end decisions are difficult because they have to be made on the basis of ambiguous or incomplete information. This makes it all the more important that such decisions incorporate the honest views and opinions of all stakeholders in the organisation  (or their nominated representatives).  The first step in such a process  is to ensure that all stakeholders have a common understanding of the goals of the project – i.e. what needs to be done. The next is to reach a shared understanding of how those goals will be achieved. Such stakeholder alignment can be facilitated through  communication-centric, collaborative techniques such as dialogue mapping. Genuine dialogue  is the only way to prevent pointless peregrinations to places that an organisation can ill-afford to go to.

Written by K

November 5, 2010 at 10:40 pm

%d bloggers like this: