Eight to Late

Sensemaking and Analytics for Organizations

Archive for the ‘Best Practice’ Category

The myth of the lonely project

with 4 comments

Introduction

Much of project management theory and practice is based on the premise that projects that are lonely – that is, they are unique undertakings,  largely independent of their organizational environment and history.  In an important paper published in 2003 entitled, No project is an island:  linking projects to history and context, Mats Engwalls argues that such a view is limited and misleading. This post presents a summary and some reflections on  the paper.

Background

It is easy to understand why the lonely project perspective dominates much of project management practice and research. A project manager’s focus is on his or her current project; history,  environment and context are therefore seen as irrelevancies.   Perhaps as a consequence, this view also permeates much of mainstream research in the field. There are exceptions, of course, such as the paper I  have reviewed in my post on the relationship between projects and organisations.

As Engwall states:

With few exceptions, research has been dominated by a perspective based on “the lonely project”. The primary interest has been in the structures and dynamics of individual projects, typically discussed from the individual project manager’s (PM’s) perspective. As an outcome, the project has been conceptualized as a lonely phenomenon, independent of history, contemporary context and future. Earlier experience, simultaneous events, and future intentions are seldom included in the analysis. In this dominating ontology, procedures employed in one project are considered to be unique and factors determining project success are considered to be due to the individual project in question

In contrast, organizational theory has long recognised that (permanent) organisations are influenced by their environment and history. As he states:

In organizational theory, the environmental impact on organizations is a classical issue. There are probably few organizational theorists today who would challenge the idea that external factors strongly influence the inner life of an organization.

Engwall’s contention is that projects, like permanent organisations, are best viewed as open systems whose structures and processes are influenced by their environment and the history/culture of the organisations in which they are embedded. He builds his argument through a detailed analysis of  two major engineering projects undertaken within one  organisation. We’ll take a brief look at the two projects first and then discuss his analysis in some detail .

The case studies and the approach

The two projects were carried out within a major Scandinavian utility company. Both projects were multidisciplinary, involving teams with expertise in construction, process and electrical engineering. The first project – referred to as the Hydropower project– was a major upgrade of a hydroelectric plant and the second – called the Transmission project – involved the design and construction of a high voltage direct current (HVDC) power link across the Baltic Sea.

The two projects had several features in common. These include:

  1. Both were internal projects – i.e. the deliverables were intended for use by the power company.
  2. The projects were carried out in roughly the same period (between 1985 and 1992).
  3. They were the two biggest projects carried out by the company during the period.
  4. Both projects were organized on a matrix principle. Work carried out in individual departments was coordinated by the project manager.
  5. The project managers on both projects were of a similar age. Both were seasoned engineers with plenty of experience of working on major projects.

As we’ll see, the two projects took very different trajectories despite these similarities.

Engwall gathered data on the two projects through a variety of sources – from archives, through interviews and even by direct observations in project meetings. He  then analysed the data from two perspectives: first, from the view of a near-autonomous project (the “lonely project” view) and  then from a viewpoint that takes into account historical and contextual linkages with the parent organisation.

The lonely project view

The hydropower project

This project was implemented by the hydropower division, one of seven engineering and business divisions within the utility. The project was run by a project manager who coordinated the engineering work done by the different divisions. Most of the work was done by internal staff, supplemented by externals where necessary.  Most important, though, is the fact that the project was run as a traditional “textbook” project. As Engwall puts it:

The PM was well aware of the message in project management literature and had the explicit intention of employing its concepts and techniques in his project. He put a strong emphasis on structuring, planning, scheduling, and cost control. He produced a project management handbook, defining guidelines and checklists for the project. He formally defined the roles and procedures of the project organization. He initiated start-up meetings, workshops, and seminars for key engineers, and assembled his project team for coordination meetings once a month. He felt responsible for all kinds of issues concerning the design and engineering of the hydropower plant…In many ways, his management approach resembled the role model of the project management textbooks.

The project manager felt that he was ultimately responsible for delivery of the design and engineering work, and his approach reflected this. In short: the project was run pretty much as recommended by project management orthodoxy.

The transmission project

This project was run by the transmission division of the utility. The project was managed by a team leader from one of the engineering departments within the division. The core HVDC system was procured from external vendor, but most of the other engineering work was done by different divisions within the company. The project manager’s main job was to coordinate the work done by the different divisions and the external party. He did not have as much positional or expert authority as his counterpart on the hydropower project. Further, he kept a much lower profile, often deferring to experts to make decisions. Significantly, neither the manager nor his deputy had any formal knowledge of project management principles. As Engwall puts it:

In relation to the Hydropower Project, this PM had a lower formal rank within the company’s hierarchy. In his position as PM, he had no formal authority at all. He held a degree in electrical engineering from a junior college. He was very humble, had a very low personal profile and was often silent during meetings. He, and his deputy, coordinated the project without an explicit management approach. Neither of them had any formalized training in project management and they had limited theoretical knowledge of project management methods and techniques. During the interviews, they often excused themselves for their lack of knowledge in project management theory.

Moreover, the project had no formal organizational structure. Project meetings were optional – it was up to the departments to decide whether or not send a representative. Most of the coordination work was done through direct (but informal) contact between the project manager and the engineers doing the work. The responsibility for scheduling and timely delivery of different modules was delegated to the engineering department doing the work. In short: the project was run without formal project management processes and controls.

Analysis

Surprisingly, the manager of the hydropower project had many more problems than his counterpart who ran the transmission project. As Engwall states:

The PM of the Hydropower Project encountered several difficulties when he tried to coordinate the activities of his project. Many of the participating engineers did not follow his instructions and decisions. The project was constantly delayed because the engineering departments were not paying enough attention to it. Furthermore, many of the engineering departments tried to perform their parts of the project independently of the other departments, and without the involvement of the PM. On many occasions, the PM found it impossible to gain control of the project, which he was formally in charge of. Time schedules and milestones were not taken seriously, costs were recorded without consideration to budget, and different departments were planning and engineering their technical power plant subsystems without sufficient coordination with the other players…

The project manager’s response to the above was pure traditional PM: he attempted to assert control by pushing the formal processes even further on an already mutinous team. Yet, despite his efforts, the project was judged a failure because of delays and budget blowouts.

In contrast, the transmission project ran smoothly, and was deemed a great success. The specifications were met within the stipulated budget. Further, the transmission link was operational several days ahead of schedule.

From the lonely project perspective, the difference between the two projects is paradoxical. As Engwall writes:

The PM with his formal authority, explicit management approach, and who deliberately applied state-of-the-art methods of project management was having significant problems, while the PM who lacked both formal authority and an explicit management approach, and who deviated substantially from the textbooks, was being significantly successful. How come?

As an answer to the question posed above, Engwall suggests that classical project management theory (as described in books and BOKs) is incomplete – i.e. there are factors that the theory does not take into account. To illustrate this point, he takes a broader perspective of the projects, one which includes the organisational environment (context) and history.  We’ll look at this organisational view next.

The organisational view – linking projects to environment and history

The hydropower project

On the technical side, one of the key requirements of the hydropower project was that many features and aspects of the existing plant had to be preserved for their historical value. It was also stipulated that the plant had to continue operating uninterrupted whilst the upgrade was in progress. These requirements greatly increased the technical complexity of the project.  Finally, the project was truly unique because it was the first time the organisation was carrying out a major upgrade within a single project; all prior upgrades had been carried out as a series of minor, ongoing extensions.

On the management side, the project was used as a testing ground for a new project management approach within the organisation. The new approach conflicted with the existing one in many ways.   For one, the project manager took on responsibility for coordinating work between different engineering divisions – something that, in the old approach, was done through direct contact between those responsible for the work. Consequently, many project personnel saw the new approach as a deliberate move by management to micro-manage their work and reduce autonomy.

As Engwall puts it:

For the first time, engineers and department heads, who were used to working almost autonomously, encountered a PM who was deliberately trying to control the project process by actively getting involved in their day-to-day work. The management problems of the project were, in this sense, the result of a collision between two philosophies: … traditional procedures…and [a] “modern” management style…The hidden agenda behind the client’s appointment of this specific PM for this specific project was as follows: to force the Hydropower Division to change its management procedures from within.

In short: there was a clear lack of trust and open communication between the project manager and the team.

The transmission project

The transmission project, because of its strategic importance, was strongly supported by top management. The project was therefore given high priority. Further, the project was considered interesting by engineers because of its technical novelty and complexity. Yet, despite the perceived novelty, the organisation had carried out many similar projects involving HVDC technology. Further, the company already had a longstanding relationship with the external contractor who was responsible for the core HVDC component: the players involved in the project were known to each other and, more importantly, trusted each other. The key team members – many of whom had worked on the earlier HVDC projects – had the same responsibilities as they had on those prior endeavours. The project was therefore not so unique.

Another important point is that the low-key management style of the project manager fit perfectly with the ethos and existing procedures of the organisation. Quoting from the paper:

The PM had been working at the division in over 30 years; he was a well-respected engineer and had an in-depth understanding of the inner life of the division. He manifested trust in his engineering colleagues and had no interest in challenging the traditions of his division. He did not fight for any formal power or official recognition as a PM. Once the HVDC contract was signed, he left most of the responsibility for its execution to the informal team of key engineers….the PM did not challenge the permanent engineering departments by fighting for more formalized procedures or methods in accordance with project management textbooks. On the contrary, his humble and informal way of coordination harmonized the existing norms and structures perfectly.

In short: the PM did his job in a way that was sensitive to the expectations of those who worked with him. He did not violate the (explicit or implicit) rules and norms of the organisation.

Analysis

When viewed through the lens of context and history, the following differences between the projects become apparent:

  1. The transmission project, because of its strategic importance, had greater visibility and prestige in the organisation. The fact that it was well supported by management and had interesting technical challenges made the project attractive to engineers within the organisation. In contrast, the hydropower project was low key and had little support from top management. Consequently, there was little incentive for engineers to devote time to it.
  2. The projects differed in degree of uniqueness: the organisation had more experience in HVDC transmission projects than it had in performing upgrades on functioning hydropower plants. The fact that the organisation had successfully carried out projects similar to the former reduced uncertainty associated with that project.
  3. The projects were managed using very different approaches. The manager of the hydropower project used an approach that did not fit with the existing culture and ethos of the organisation whereas the transmission project was managed in a way that was sensitive to institutional norms and practices. It isn’t surprising, therefore, that the manager of the hydropower project had more difficulty in getting the job done.

The paradox is thus resolved: a full understanding of a project must take into account the context of the project, and  the culture/environment of the host organisation(s).

Discussion

The author’s analysis suggests that project success factors are context dependent: a methodology or approach that works in your organisation may not work in mine.   An implication of this is that prescriptive project management methodologies are unlikely to work when they are applied without due regard to organisational quirks and circumstances. Several other studies support this conclusion – see my posts on going beyond best practices and project management in post-bureaucratic organisations for examples.

Another important implication of this work is that intrinsic properties of projects (such as size, scope, technology etc.) are perhaps less significant than extrinsic ones (such as organisational culture). As Engwall puts it:

… these [latter] factors have little to do with the technical content of a project per se, but rather with how different stakeholders interpret a project in relation to the procedures and traditions of its surrounding context. The findings suggest, for instance, that important aspects of a project’s inner life are dependent on the level of deviation between the practices applied within the project and the knowledge base and institutional structure of its organizational context.

The research also calls into question the notion of a project as a unique undertaking. Engwall’s contention, supported by the case studies, is that projects typically consist of a mix of unique and repetitive processes. We never begin with a completely blank slate, nor do we ever repeat exactly the same project.

Endnote

The obvious takeaway from the paper is that project managers need to be aware of the history, culture, strategic imperatives and social dynamics of the organisations within which their projects are embedded. They should then tailor their  approach based on their knowledge of these factors. As the case studies illustrate, project management best practices may count for little if historical and contextual factors are ignored.

At a more philosophical level, the paper illustrates that project success is contingent on a host of factors that at first sight have nothing to do with projects.  Often these factors will become evident only in hindsight,  after the project has run its course.   Managers can therefore never be absolutely certain that they have considered all the key variables on their projects. Consequently they should view any actions they take as being provisional,  subject to change as their knowledge  of the project evolves.

Written by K

October 21, 2010 at 5:04 am

Thinking outside the BOKs

with 14 comments

Introduction

Mainstream project management practices are codified in various “bodies of knowledge” (BOKs) that serve as definitive guides or standards for the profession.  This formalization of project management knowledge serves to propagate and legitimize practices regardless of their actual utility. Moreover, it also leads to a perception that project management practices are domain-independent.   In a recent paper entitled,  21st century project management = open source body of knowledge,  Jon Whitty calls for an open source approach to the development and dissemination of project management knowledge, with a view to addressing the aforementioned limitations  of the “BOK-centric” paradigm.   This post summarises the main ideas presented in the paper.

Why step outside the BOKs?

According to Whitty, many project management tools and techniques have become standard practice for reasons other than their utility. Some of these reasons include:

  1. Techniques that are easy to replicate (copy and pass on to others) have a greater chance of acceptance, regardless of whether they are useful or not. This point is discussed at length in my post on the memetic view of project management.
  2. Techniques that give project managers (and their managers) an emotional affect have a better chance of acceptance.  See my post on emotional effect of project management artefacts for more on this.

As Whitty puts it, “One might say that we have been duped or perhaps more poetically speaking romanced by some aspects of modern project management…

The main consequence of the above is that “standard” project management knowledge as embodied in books and BOKs isn’t necessarily a reflection of how project management  is (or even, should be) practiced.   Yet this is the official, authorized version of knowledge, used to train and certify project managers.

Another point that Whitty makes is that despite of the discipline’s attempt to rid itself of domain specific connotation, project management (in practice) is domain specific – there is a difference, say, between a corporate reporting system project and a health care project. It is wishful thinking to expect that a project manager will be able run a project in an unfamiliar area without first learning a bit about the domain. Consequently, Whitty writes that:

…we must acknowledge that each domain of work (e.g. health, arts, sciences, education) is capable of evolving its own methods for managing projects if given the freedom to do so. I suggest there is a moral obligation on all scholars and practitioners of project management to enable these domain specific methods to emerge…

Another point that I would add in support of Whitty’s arguments is that there is a difference between project management theory and project management practice (see this paper, for example).  Projects are seldom, if ever, run by the book; it is a fact that most project managers do “think outside the BOKs” when practicing their profession.  A body of knowledge reflecting how projects are actually run in practice would thus be very different from the prescriptions presented in books and BOKs.

Project management as a (controlled) democracy

To address the issues mentioned in the previous section, Whitty suggests democratizing project management knowledge by:

  1. A bottom-up approach to project decision making, involving all stakeholders, rather than a top-down approach implicitly advocated by books and BOKs.
  2. The recognition that project management needs to be tailored to the needs of specific domains, rather than striving for the lowest common denominator of domain independent tools and techniques.
  3. An open source approach to project management knowledge whereby anyone can contribute techniques and case studies based on their own (possibly domain specific) experiences.
  4. A culture that enables project managers to report their specific practices (and failures) without fear of reprisals.

Whitty clarifies that open source means more than free access. Among other things, it offers a means by which

  1. New techniques can be shared and evaluated by practicing project managers and academics.
  2. Domain specific project management knowledge can be compiled, tested and disseminated. This knowledge will evolve as it is supported (or refuted) through case studies and other data contributed by practitioners.

Obviously open source does not mean that anything goes; that would be a recipe for chaos and confusion. Oversight is needed to ensure that the repository is coherent and meaningful, and that contributed material meets certain quality standards. This is nothing new – most open source efforts operate this way already – Wikipedia being the closest in spirit to the one proposed by Whitty.

The role of professional organisations in an OS-BOK world

What role would professional organisations have in such an open source BOK world?  Here’s what Whitty thinks,

The implications for an open source body of knowledge for project management will be significant for the current project management professional associations who control existing BOKs, particularly the PMI who hold the intellectual property to the current Guide. The PMI and others will need to abandon their ideals for creating a professional class of project managers. They could take a leadership role in the development and on‐going coordination of the human and technological mechanisms that develop and maintain the OS‐PMBOK and validate the source evidence of the various knowledge libraries.   Their role might also be more like that of a vocational skills awarding body. As the various domain specific bodies of knowledge for project management emerge, the project management associations could have a place in developing and administering specific project management certification in conjunction with key industry bodies that represent the various domains. The project management associations will also need to establish new alliances with the academic community and lend support, cooperation, and channel industry funding towards evidence-based practice research.

Many of the activities listed by Whitty are already carried out by most professional project management organisations. As I see it, these organisations would continue to play an important role in developing the profession. However, they would no longer be the arbiters of what is legitimate and what isn’t.

Conclusion

Existing project management knowledge tells us how projects should be managed, not how they are actually managed. Seen in this light, Whitty’s proposal for an open source approach to project management makes eminent sense. Such an approach may lead to a body of knowledge that reflects the diverse ways in which project management is practiced in various (corporate and national) cultures and domains.

Written by K

August 27, 2010 at 5:37 am

Beyond Best Practices: a paper review and the genesis of a collaboration

with 10 comments

Introduction

The fundamental premise behind best practices  is that it is possible to reproduce the successes of those who excel by imitating them. At first sight this assumption seems obvious and uncontroversial. However, most people who have lived through an implementation of a best practice know that following such prescriptions does not guarantee success. Actually, anecdotal evidence suggests the contrary:  that most attempts at implementing best practices fail. This paradox remains unnoticed by managers and executives who continue to commit their organisations to implementing best practices that are, at best, of dubious value.

Why do best practices fail?   There has been a fair bit of research on the shortcomings of best practices, and the one thing it tells us is that there is no simple answer to this question.  In this post I’ll discuss this issue, drawing upon an old (but still very relevant) paper by Jonathan Wareham and Han Cerrits entitled, De-Contextualising Competence: Can Best Practice be Bundled and Sold.   Note that I will not cover the paper in its entirety;  my discussion will focus only on those aspects that relate to the question raised above.

I may as well say it here:  I have a secondary aim  (or more accurately,  a vested interest)  in discussing this paper.  Over the last few months Paul Culmsee and I have been working on a book that discusses reasons why best practices fail and proposes some practical techniques to address their shortcomings.  I’ll end this post with a brief discussion of the background and content of the book (see this post for Paul’s take on the book). But let’s look at the paper first…

Background

On the first page of the paper the authors state:

Although the concept of ‘imitating excellent performers’ may seem quite banal at first glance, the issue, as we will argue, is not altogether that simple after deeper consideration. Accordingly, the purpose of the paper is to explore many of the fundamental, often unquestioned, assumptions which underlie the philosophy and application of Business Best Practice transfer. In illuminating the central empirical and theoretical problems of this emerging discipline, we hope to refine our expectations of what the technique can yield, as well as contribute to theory and the improvement of practice.

One of the most valuable aspects of the paper is that it lists some of the implicit assumptions that are often glossed over by consultants and  others who sell  and implement best practice methodologies.  It turns out that these assumptions are not valid in most practical situations, which renders the practices themselves worthless.

The implicit assumptions

According to Wareham and Cerrits, the unstated premises behind best practices include:

  1. Homogeneity of organisations: Most textbooks and courses on best practices present the practices as though they have an existence that is independent of organizational context.  Put another way: they assume that all organisations are essentially the same. Clearly, this isn’t the case – organisations are defined by their differences.
  2. Universal yardstick: Best practices assume that there is a universal definition of what’s best, that what’s best for one is best for all others. This assumption is clearly false as organisations have different (dare I say, unique) environments, objectives and strategies. How can a universal definition of “best” fit all?
  3. Transferability:  Another tacit assumption in the best practice business is that practices can be transplanted on to receiving organisations wholesale. Sure, in recent years it has been recognized that such transplants are successful only if a) the recipient organisation undertakes the changes necessary for the transplant to work and b) the practice itself is adapted to the recipient organisation. The point is in most successful cases, the change or adaptation is so great that it no longer resembles that original  best practice. This is an important point – to have a hope in hell of working, best practices have to be adapted extensively. It is also worth mentioning that  such adaptations will succeed only if they are  made in consultation with those who will be affected by the practices. I’ll say more about this later in this post
  4. Alienability and stickiness: These are concepts that relate to the possibility of extracting relevant knowledge pertaining to a best practice from a source and transferring it without change to a recipient. Alienability refers to the possibility of extracting relevant knowledge from the source. Alienability is difficult because best practice knowledge is often tacit, and is therefore difficult to codify. Stickiness refers to the willingness of the recipient to learn this knowledge, and his or her ability to absorb it. Stickiness highlights the importance of obtaining employee buy-in before implementing best practices. Unfortunately most best practice implementations gloss over the issues of alienability and stickiness.
  5. Validation: Wareham and Cerrits contend that best practices are rarely validated. More often than not,  recipient organisations simply believe that they will work, based on their consultants’ marketing spiel. See this short piece by Paul Strassman for more on the dangers of doing so.

What does  “best” mean anyway?

After listing the implicit assumptions, Wareham and Cerrits argue that the conceptual basis for defining a particular practice as being “best” is weak.  Their argument hinges on the observation that it is impossible to attribute the superior performance of a firm to specific managerial practices. Why? Well, because one cannot perform a control experiment to see what would happen if those practices weren’t used.

Related to the above is the somewhat subtle point that it is impossible to say, with certainty, whether practices, as they exist within model organisations, are consequences of well-thought out managerial action or whether they are merely adaptations to changing environments. If the latter were true, then there is no best practice, because the practices as they exist in model organisations are essentially random responses to organizational stimuli.

Wareham and Cerrits also present an economic perspective on best practice acquisition and transfer, but I’ll omit this as it isn’t of direct relevance to the question of why best practices fail.

Implications

The authors draw the following conclusions from their analysis:

  1. The very definition of best practices is fraught with pitfalls.
  2. Environmental factors have a significant effect on the evolution and transfer(ability) of “best” practices. Consequently, what works in one organisation may not work in another.

So, can anything be salvaged?  Wareham and Cerrits think so. They 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.

Discussion

Cerrits and Johnson focus on the practices themselves, not the problems they are used to solve. In my opinion, another key reason why best practices fail is that they are applied without a comprehensive understanding of the problem that they are intended to address.

I’ll clarify this using an example:  in a quest to improve efficiency an organisation might go through a major restructure. All too often, such organisations will not think through all the consequences of the restructuring (what are the long-term consequences of outsourcing certain functions, for instance). The important point to realize is that a comprehensive understanding of the consequences is possible only if all stakeholders – management and employees – are involved in planning the restructure.  Unfortunately, such a bottom-up approach is rarely taken because of the effort involved, and the  wrong-headed perception that chaos may ensue from management actually talking to people on the metaphorical shop floor.   So  most organizations take a top-down approach, dictating what will be done, with little or no employee involvement.

Organisations focus on how to achieve a particular end. The end itself, the reasons for wanting to achieve it and the consequences of doing so remain unexplored; it is assumed that these are obvious to all stakeholders. To put it in aphoristically: organizations focus on the “how” not the on the “what” or why.”

The heart of the matter

The key to understanding why best practices do not work is to realise that many organizational problems are wicked problems: i.e., problems that are hard to define, let alone solve’s  (see this paper for a comprehensive discussion of wicked problems).  Let’s look at organizational efficiency, for example.   What does it really mean to improve organizational efficiency?   More to the point, how can one arrive at a generally agreed way to improve organizational efficiency?  By generally agreed, I mean a measure that all stakeholders understand and agree on. Note that “efficiency “is just an example here – the same holds for most other matters of strategic importance to organizations: organisational strategy is a wicked problem.

Since wicked problems are hard to pin down (because they mean different things to different people), the first step to solving them is to ensure that all stakeholders have a common (or shared) understanding of what the problem is. The next step  is to achieve a shared commitment to solving that problem. Any technique that could help achieve a shared understanding of wicked problems and commitment to solving them  would  truly deserve to be called the one best practice to rule them all.

The genesis of a collaboration

About a year ago, in a series of landmark posts entitled The One Best Practice to Rule Them All, Paul Culmsee wrote about his search for a practical method to manage wicked problems.  In the articles he made a convincing case that dialogue mapping can help a diverse group of stakeholders achieve a shared understanding of such problems.  Paul’s writings inspired me to learn dialogue mapping and use it at work. I was impressed – here, finally, was a technique that didn’t claim to be a best practice, but had the potential to address some of the really complex problems that organisations face.

Since then, Paul and I have had several conversations about the failure of best practices in to tackling issues ranging from organizational change to project management. Paul is one of those rare practitioners with an excellent grounding in theory and practice.  I learnt a lot from him in those conversations. Among other things, he told me about his experiences in using dialogue mapping to tackle apparently intractable problems (see this case study from Paul’s company, for example).

Late last year, we thought of writing up some of the things we’d been talking about in a series of joint blog posts. Soon we realised that we had much more to say than would fit into a series of posts – we probably had  enough for a book.  We’re a few months into writing that book, and are quite pleased with the way it’s turning out.

Here’s a very brief summary of the book. The first part analyses why best practices fail.  Our analysis  touches  upon diverse areas like organizational rhetoric, cognitive bias, memetics and scientific management (topics that both Paul and I have written about on our blogs).  The second part of the book presents a series of case studies that illustrate some techniques that address complex problems that organizations face. The case studies are based on our experiences in using dialogue mapping and other techniques to tackle wicked problems relating to organizational strategy and project management.  The techniques we discuss go beyond the rhetoric of best practices – they work because they use a bottom-up approach that takes into account the context and environment in which the problems live.

Now, Paul writes way better than I do. For one, his writing is laugh-out-loud funny, mine  isn’t. Those who have read his work and mine may be wondering how our very different styles will combine.  I’m delighted to report that the book is way more conversational and entertaining than my blog posts.  However, I should also emphasise that we are trying to be as rigorous as we can by backing up our claims by references to research papers and/or case studies.

We’re learning a lot in the process of writing, and are enthused and excited about the book . Please stay tuned – we’ll post occasional updates on how it is progressing.

Update (16 June 2010):

An excerpt from the book has been published here.

Update (27 Nov 2011):

The book, which has a new title, is currently in the final round of proofs. Hopefully it will be available for pre-order in a month or two.

Update (05 Dec 2011):

It’s out!

Get your copy via Amazon or Book Depository.

The e-book can be obtained from iUniverse (PDF or Epub formats) or Amazon (Kindle).