Eight to Late

Sensemaking and Analytics for Organizations

Search Results

A model of project complexity

with 4 comments


The lack of a clear definition of project complexity has lead to much confusion amongst project management academics and practitioners regarding what makes a project complex to manage. A recent paper by Harvey Maylor, Richard Vidgen and Stephen Carver, entitled Managerial Complexity in Project-Based Operations: A Grounded Model and Its Implications for Practice, is a step towards changing this situation. In the paper Maylor and his co-workers  present a qualitative empirical model which captures both structural (static) and dynamic1 elements of  managerial complexity in projects. I summarise and review the paper below.

Background and Objectives

The authors make the observation that project management methodologies (as codified in the various “bodies of knowledge”) contain what is deemed as accepted practice rather than best practice.  The point being that there is never any proof offered that the practice in question is indeed the best, or even better than others. Such proof is impossible because methodologies are highly prescriptive and  ignore context (i.e. the particular environment and quirks of individual projects).  This dogmatic, “our way is the best way” attitude is inconsistent with the diversity of situations and factors that make projects hard to manage. Hence the need to develop a understanding of what makes a project complex.

It may thus be helpful to consider projects as complex adaptive systems. As a first step, the authors discuss various characterstics of such systems, in particular those that might apply to projects. I have covered much of this material in an earlier post, so my coverage here will be brief. The main points the authors make are as follows:

  1. The components of a complex system interact and produce outcomes that are unpredictable and nonlinear.
  2. One cannot understand a complex system by studying the individual components that comprise it.
  3. A complex system displays path dependence (i.e. dependence on history) and sensitivity to initial conditions.
  4. Adaptive systems can change and “learn” from experience.

There have been several models of project complexity proposed by researchers. Each of these propose various dimensions (or factors) that capture complexity. Some of these factors are:

  1. The number of physical elements of a project and their interdependencies. (Baccarini)
  2. Organisational, technical and resource complexity.
  3. Organisational and technical complexity, and structural and dynamic interactions between the two. (Xia and Lee)

Although earlier models have been useful, organisations have found that other factors (unaccounted for in existing models) contribute to managerial complexity in projects. With this in mind, the authors’ aim to develop a comprehensive empirical model of managerial complexity in projects and thus answer the question: What makes a project complex to manage?

The Model

The  model  was developed through workshops that involved a large number of practising project managers. I will not go into details of research methodology here; please see the original paper for details.  What is important to note is that the model includes input from a broad range of practitioners. With that said, I’ll move straight on to a description of the model.

The model describes both structural and dynamic elements of managerial complexity. The authors find that structural complexity in projects comprises of the following broad dimensions: Mission,  Organisation, Delivery, Stakeholders and Team. Following a distinctly academic penchant for acronymisation (to coin a term), the authors call their model MODeST, taking the first letter or two from each of the above dimensions.

The hierarchy below lists each of the above dimensions along with their sub-dimensions. Further, the lowest level of the hierarchy (sub-dimension level) lists representative questions that can be used to characterise each sub-dimension.  (Note: Please see the paper for full details).

  • Mission
    • Objectives
      • Is there a clear vision?
      • Are the goals clear?
    • Scale
      • Long timescale?
      • Large number of resources?
    • Uncertainty
      • Are there interdependencies with other projects?
      • Are there interdependencies within the project?
      • Does it involve new technology?
      • Has the project been done before?
    • Constraints
      • Are there legislative or compliance constraints?
  • Organisation
    • Time
      • Are there multiple timezones?
    • Space
      • Are team members colocated?
      • Is there face-to-face communication between team members?
    • Geography
      • Are there multiple languages?
    • Project / organisation fit
      • Is there a mismatch between project team structure and organisational structure?
    • Organisational change
      • Does the project involve organisational restructuring?
  • Delivery
    • Administration
      • Is project reporting accurate, adequate and does information get to people who need it?
      • Is project data collection accurate, true and complete.
    • Decision Making
      • Is there effective governance of project decision making?
      • Are too many levels of management involved in decision making?
    • Change management
      • Is the change management process cost effective?
      • Is it flexible?
    • Project processes
      • Are project processes defined, standardised but not overly bureaucratic?
      • Is there a clear responsibility for tasks and deliverables?
    • Project management methodology
      • Is there a common methodology used throughout the project?
    • Resources – Human
      • Are human resources shared across projects?
      • Who controls human resources for the project?
      • Does the project manager have control over resource selection?
    • Resources –  Technology
      • Does the project have tool support?
    • Resources – Financial
      • How flexible is the project budget?
  • Stakeholders
    • Stakeholder Identification
      • How many stakeholders are there?
      • Are there any unidentified stakeholders?
    • Support for project
      • Do stakeholder groups interfere with the project?
      • Do stakeholders have sufficient time for the project?
      • Do they respond to project needs in a timely manner?
    • Relationship basis
      • Is the relationship between the project and stakeholders contractual?
    • Experience
      • Do the stakeholders have realistic expectations of the project?
      • Do they have domain experience?
      • Do they have project management experience?
    • Power
      • Do the stakeholders have power to make decisions.
    • Key stakeholders
      • Is there senior management support?
    • Sociopolitical
      • Are there hidden agendas or unsurfaced assumptions?
      • Do stakeholders have conflicting priorities?
      • Are there any conflicts between requirements of different stakeholders?
    • Interdependencies
      • Are there interdependencies between stakeholders? (e.g. between suppliers)
  • Team
    • Project staff
      • Do team members have sufficient prior experience?
        Does the project involve multiple technical disciplines and languages?
      • Are the team members knowledgeable and competent in all aspects of the project (business, technical and project management)?
      • Are the team members motivated?
    • Project manager
      • Is the project manager an effective communicator?
      • Does the project manager have authority?
    • Group
      • Are there cultural differences between team members?
      • Are there personality clashes or is there any rivalry within the team?
      • Does the team have a shared vision for the project?

The above dimensions and sub-dimensions characterise the structure of managerial complexity in projects. However, that isn’t all: the authors mention that many workshop respondents emphasised that elements (i.e dimensions) that make up the model interact thereby “multiplying” managerial complexity. This is one aspect of dynamic complexity. The authors also note that interactions can occur within a single element – for example, within interdependencies between suppliers and stakeholders. Analysis of the data showed that there is a dynamic element corresponding to every structural element of the model. Further still, dynamics of an individual structural element can be affected by interactions with other structural and dynamic elements. That is, the dynamics of one part of the system can be altered by other changes in other parts. The model thus captures structural, dynamic and interactive aspects of managerial complexity in projects.

The authors report that workshop participants also recognised their own role in adding to managerial complexity. For example, a project manager who fails to recognise task dependencies in early stages of a project contributes to complexity down the line. Project managers are thus, ” key actors embedded within the conceptualisation of the complexity of their projects rather than external observers.” The authors suggest that this indicates that many elements of managerial complexity can in fact be tamed by proper management. That, arguably, is what a project manager’s job is all about.

Implications and Discussion

The authors observe that projects are ubiquitous within organisations. Yet, current project management practices as codified in well-known methodologies fail to account for variations in context between projects. Managerial complexity varies with (and is defined by) a particular project’s context – for instance, a project may have several stakeholders with conflicting requirements whereas another may have only one stakeholder. The model developed by the authors describes managerial complexity using five dimensions and several sub-dimensions. These structural elements can change in time and also interact with each other, so the model is also capable of describing dynamic complexity in projects.

To illustrate expand on the last point of the previous paragraph, consider stakeholders – the “S” in the MoDest acronym. The authors point out that, “from an organisational theory perspective, a project can be seen as being constituted from the entire set of relationships it has with itself and with its stakeholders.” Project managers need to understand not only the power and legitimacy of each of the stakeholders, but also the relationships or interactions between them.  Moreover, the relationships between stakeholders evolve in time – i.e they are dynamic. Similarly, the other four dimensions of the model also display dynamic behaviour.

This dynamic behaviour is merely a restatement of the obvious:  in projects things change, sometimes rather quickly and unexpectedly. Standard project management practice offers techniques such as risk management, configuration management and change control to manage these. However, the authors suggest their data shows that,  “the nature of change considered by existing approaches is limited and that such programmatic responses may be inappropriate.” They go on to state, “Such dissatisfaction with traditional requirements engineering and command-and-control project management strategies has lead to an interest in agile project management approaches.” These statements will ring true for  those who have been burned by  the limitations of traditional project management methodologies.  Agile techniques embrace change; traditional methodologies seek to control it (and do so unsuccessfully, one might add).  The implicit acceptance of change in agile methodologies make it consistent with the dynamic model of managerial complexity proposed by the authors.


The paper describes an empirical model of managerial complexity in projects. From my (admittedly incomplete) reading of the literature, the model is more comprehensive than those that have been proposed heretofore. Further, it captures structural, dynamic and interactive aspects of elements that make a project complex and hard to manage. The model challenges current practice as embodied in traditional, “big-bang” approaches to running projects, but is consistent with Iterative/Incremental methodologies which form the basis of agile techniques.

The authors end with a brief description of some areas for further research. Some of these include:

  • Refining the dimensions of complexity and finding the key drivers of each.
  • Determining whether compexity can be quantified.
  • Exploring the possibility of managing complexity.

We are still a long way off answering these questions, and thus developing a quantitative, controllable understanding of project complexity. Yet, the model presented provides at least a partial answer to the question: What makes a project complex to manage?


Maylor, Harvey.,  Vidgen, Richard, & Carver, Stephen., Managerial Complexity in Project-Based Operations: A Grounded Model and Its Implications for Practice, Project Management Journal, 39 (Supplement), S15-S26. (2008).


1 See this post for more on structural and dynamic complexity.

Written by K

September 18, 2008 at 11:08 pm

Project complexity redux

with 5 comments

In recent years there has been much discussion on complexity in project management (see this book or this standard, for example).  Unfortunately, the term “complexity” has been interpreted in all kinds of different ways, creating more confusion than clarity. So, despite all that’s been written and said, project management practitioners are still left wondering what is meant when the words “project” and “complex” (or its variants such as “complexity”) are strung together. This post is aimed at clarifying some of the confusion.

In the natural and social sciences, the term complexity is used to describe systems that consist of several interacting parts.  However, there’s more to complexity than just that. Complex systems  display several characteristic features including nonlinearity, continuous interactions with their environment (open systems) and complex feedback loops. Many complex systems also display emergent behaviour – i.e. behaviour that is more than a sum of the the behaviour of individual components. The collective behaviour of bird flocks is an example of emergence: individual birds follow a relatively simple set of behaviours or rules based on the movements of their neighbours, giving rise to a stable flying pattern on the scale of the entire flock. This large-scale flocking pattern is an emergent phenomenon, not easily discernable from the simple rules followed by individual birds.

Now, as I’ve mentioned in a prior post,  the term complex is used in at least two distinct senses in the project management literature. These are:

  1. Projects that are difficult or complicated because they are high risk or involve a multitude of management and technical factors. I have used the term in this sense in my post entitled a short note on project complexity. This kind of complexity is relatively easy to measure, at least qualitatively if not quantitatively. 
  2. Projects that are complex in the sense of complex systems as discussed above. This type of complexity is typically hard to measure, even qualitatively.

Although it is possible (and not uncommon) for projects to be complex in both senses described above, it is important to make a distinction between the two for reasons that I discuss below.

For starters,  to ensure consistency with other disciplines the adjective “complex” should (ideally) be used to refer to projects that are complex in the second sense. That brings us to the nub of the matter: how are we to know if a project is complex in this sense or not? This question remains open at this time. As yet no one has devised a metric, scale or even a definition  by which one would be able to determine whether a project is truly complex or not. Nevertheless, it is worth looking at project complexity from a couple of  perspectives in order to get a feel for what a definition of a complex project might look like. I do this in the next few paragraphs, with the caveat that my discussion is more vignette than panorama. Those looking for the latter may want to read the review paper published by Cooke-Davis and others in 2007. If wading through a research paper sounds uninviting, I can recommend my post entitled rumours of a new project management paradigm, which is basically a summary and review of the paper.

Moving on, in a recent paper, Jon Whitty and Harvey Maylor discuss the nature of complexity in projects. They point out that there are two elements to complexity – structural and dynamic. In the context of projects, the structural aspect consists of individual elements that make up the project and its environment – stakeholders, project tasks, etc. – and the interactions between these. In contrast, the dynamic aspect refers to changes in elements, the consequent changes in their interactions, and the further changes in the elements as a result of changing interactions. Whitty and Maylor suggest that a project be termed complex only when it displays both structural and dynamic complexity.   By this token, many projects currently classified as complex are incorrectly deemed so, because they display mainly structural, not dynamic, complexity. Put another way, they exhibit complexity in the first sense described earlier, but not the second. For example, many large projects consist of a large number of interacting elements (and hence display structural complexity), but the elements and their interactions are relatively stable (and hence not dynamically complex).  At the other end of the spectrum, one could have small projects that do display dynamic complexity. Size by itself is not a good measure of dynamic complexity.

Whitty and Maylor’s discussion suggests that structural complexity maps to complexity in the first sense  described above (i.e. complicated projects) and dynamic complexity to the second (i.e. truly complex projects). In what follows below, the term complex should be read as dynamically complex. 

Although the definition of a (dynamically) complex project is still an open question, Whitty and Maylor look into what might be meant by “managing a complex project”. In general, it is difficult (and often impossible) to predict long-term emergent behaviour in complex systems. In complex projects this lack of predictability is a consequence of complicated, dynamic interactions between various project elements such as resources, tasks etc. Note that this is lack of predictability, in principle – i.e.  it is not  a consequence of incomplete knowledge (such as incomplete scope definition) or any other controllable cause. This being the case, many of the tools used in conventional project management, which includes all Big Design Up Front methodologies, would simply not apply to complex projects. For example, how can one build a (long-term) schedule if one doesn’t know what’s going to happen? Further, it is also clear that any methodologies that use short development cycles, which includes all  iterative / incremental approaches, would have a much better chance of success here. In this context, the terminology used by the adaptive approach is particularly apt: faced with uncertainty, one doesn’t plan, one speculates. To sum up, although we don’t know what exactly a complex project is, we do know – broadly speaking – which project management approaches might work with them (and, more importantly, which won’t!).

For another perspective on project complexity, let’s turn to a paper entitled, Dilemmas in a General Theory of Planning, published by Rittel and Webber in 1973. The paper focuses on the characteristics of many social problems or issues – such as education, crime etc. – which can’t be solved (or even formulated!) in a conventional, scientific sense. The authors coin the term wicked problem to refer to such problems.  In contrast, problems that can be analysed and solved using known techniques are referred to as tame problems. In their paper, Rittel and Webber propose the following as defining characteristics of wicked problems:

  1. There is no definitive formulation of a wicked problem.
  2. Wicked problems have no stopping rule.
  3. Solutions to wicked problems are not true-or-false, but good or bad.
  4. There is no immediate and no ultimate test of a solution to a wicked problem.
  5. Every solution to a wicked problem is a “one-shot operation”; because there is no opportunity to learn by trial-and-error, every attempt counts significantly.
  6. Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan.
  7. Every wicked problem is essentially unique.
  8. Every wicked problem can be considered to be a symptom of another problem.
  9. The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem’s resolution.
  10. The planner has no right to be wrong (planners are liable for the consequences of the actions they generate).

Although these characteristics are qualitative, they are relatively unambiguous – i.e.  given a problem, we can figure out whether it is wicked or not.  Looking through the list, it is tempting to draw a link between wickedness and complexity. Although I’m out on a limb here, other writers have commented on  the similarity between complex systems and wicked problems too. 

In an article  published in 2002, Mary Poppendieck dubbed a wicked project as a project that tackles a wicked problem as though it were a tame one. I would simplify the definition to: a wicked project is one that tackles a wicked problem. Then, assuming a  connection between wickedness and complexity exists, one would have the basis for a qualitative definition of a class of complex projects. I say “a class” because even if it is true that wicked problems are complex, the converse doesn’t necessarily hold – i.e. not all complex problems are wicked.

All the above – some of which is speculation –  leaves open the question of how a project is to be deemed complex or not. This, as mentioned earlier, awaits an unambiguous definition (and measure) of project complexity. We’re a long way off from that at present.  So, at least for now, one has to be careful when labelling a project “complex” because the term has a very precise meaning in the social and natural sciences.  Given this, it may be best to refer to so-called complex projects by other adjectives such as complicated, difficulthardintricateconvoluted or  even labyrinthine. Any synonymous term would get the point across, whilst sparing the project management community a whole lot of confusion.

Written by K

July 2, 2008 at 9:40 pm

Posted in Project Management

A short note on project complexity

with 2 comments

The adjective complex is often used to describe projects that are in some sense hard. I’ve used the term without defining it in a few of my previous articles on this blog  (see my post entitled, rumours of a new project management paradigm, for example).  I’m sure most project managers (PMs) have at least a qualitative notion of what makes a project complex. However, if you ask a bunch of PMs what the term means, you’d probably get answers varying from, “large projects involving many people” to “projects involving unfamiliar or new technologies”. It is worth gaining a general understanding of  the term because it is often used in project management practice and research. Hence my motivation for this short, critical look at a few definitions and measures of project complexity.

A good place to start is with Dr. Lew Ireland’s paper entitled Project Complexity: A Brief Exposure to Difficult Situations. In the paper, Dr. Ireland identifies two dimensions of project complexity:

  • Technical Complexity: This includes all technical aspects of the project, such as,
    • Number of technologies involved
    • Familiarity of team with technologies
    • Bleeding edge or well established technology.
    • Number of technical interfaces
  • Management Complexity: This includes all business and organisational aspects of the project, such as,
    • Project staffing and management (team composition, size, management hierarchy etc.)
    • Number of parties involved (external vendors, internal departments etc.)
    • Change-related issues.
    • Stability and complexity of requirements
    • Political issues
    • Time / cost issues etc.

Dr. Ireland also highlights the need to identify and understand the elements of complexity in every project.  He does this by describing a few real-life cases of complex projects which went wrong.

The approach described above is similar to that outlined in The Project Manager’s Desk Reference by James Lewis. In the book, Lewis identifies four kinds of projects on the basis of the two dimensions listed above (note that he uses the term business complexity instead of management complexity). These are:

  • Type IV (Routine project): low technical and business complexity
  • Type III: low technical complexity but high business complexity
  • Type II: high technical complexity but low business complexity
  • Type I (Complex Project): high technical and business complexity

One can get quite specific in defining dimensions, but some caution is necessary. As the number of dimensions increase, individual dimensions become narrower in scope and there’s a danger that some elements of complexity will not be captured.  How this might happen is best illustrated through an example. Consider this project complexity model which uses the following eight dimensions:

  1. Time / cost
  2. Team size
  3. Team composition
  4. Competing demands
  5. Problem / solution clarity
  6. Stability of requirements
  7. Strategic importance / political implications / number of stakeholders
  8. Level of change

Question: Look at these measures carefully. Is there something missing?  

Answer:  All the listed measures relate to business complexity. There is no measure of technical complexity!

So I end  this note with the following: It is important to understand what is meant by project complexity because the term is often used by project management professionals in conference presentations, trade journal articles and research papers (and blogs!). However, it is equally important to ensure that the elements used in a definition capture all relevant aspects of complexity in projects.

Written by K

May 1, 2008 at 9:22 pm

Posted in Project Management

The resource allocation syndrome in multi-project environments

with 18 comments


In many organisations, employee workloads consist of a mix of project and operational assignments.  Due to endemic shortfalls in staffing, such folks – particularly those who have key skills and knowledge – generally have little or no spare capacity to take on more work.   However, soon comes along another “important” project in urgent need of staffing and the rest, as they say, is tragedy:  folks who are up to their necks in work are assigned to work on the new project. This phenomenon is a manifestation of the resource allocation syndrome, discussed at length in a paper by Mats Engwall and Anna Jerbrant entitled,  The resource allocation syndrome: the prime challenge of multi-project management?. The present post is a summary of the paper.


Scheduling and resource allocation is a critical part of project planning in multi-project environments. Those who work in such settings know (often from bitter experience) that, despite the best laid plans, it is easy to be over-allocated to multiple projects. Engwall and Jerbrant’s work delves into the factors behind resource over-allocation via a comparative case study involving two very different environments: the contracts department of a railway signalling equipment firm and an R&D division of a telecoms company.

Specifically, the work addresses the following questions:

  1.  Are there any (resource allocation) issues that are common to multi-project / portfolio environments?
  2. What are the mechanisms behind these issues?

As they point out, there are several articles and papers that deal with the issue of resource allocation on concurrent projects. However, there are relatively few that tackle the question of why problems arise. Their aim is to shed light on this question.

Methodology and the case studies

As mentioned above, the authors’ aim was surface factors that are common to multi-project environments. To this end, they   gathered qualitative data from a variety of sources at both sites. This included interviews, studies of project and technical documentation, company procedures and direct observation of work practices.

The first study was carried out at the contract division of a mid-sized railway signalling equipment firm.  The division was well-established and had a long history of successful projects in this domain. As might be expected given the history of the organisation, there was a mature project management methodology in place. The organisation had a matrix management structure with 200 employees who were involved in executing various projects around the world. The work was managed by 20 project managers. Most of the projects were executed for external clients. Further, most projects involved little innovation: they were based on proven technologies that project teams were familiar with. However, although the projects were based on known technologies, they were complex and of a relatively long duration (1 to 5 years).

The second study was done in the R&D division of a telecom operator. The division, which had just been established, had 50 employees who worked within a matrix structure that was organised into five specialist departments. Since the division was new, the project management procedures used were quite unsophisticated. Projects were run by 7 project managers, and often involved employees from multiple departments.  Most of the projects run by the division were for internal customers – other divisions of the company. Also in contrast to the first study, most projects involved a high degree of innovation as they were aimed at developing cutting-edge technologies that would attract new subscribers. However, even though the projects involved new technologies, they were of relatively short duration (0.5 to 2 years).

Important, from the point of view of the study, was the fact that most employees in both organisations were engaged in more than one project at any given time.

For those interested, the paper contains more detail on the methodology and case studies.


As might be expected from a study of this nature, there were differences and similarities between the two organisations that were studied.  The differences were mainly in the client base (external for the contract division, internal for the other), project complexity (complex vs. simple) and organisational maturity (older and mature vs. newly instituted and immature).

Despite the differences, however, both organisations suffered from similar problems. Firstly, both organisations had portfolios with extensive project interdependencies. As a consequence, priority setting and resource (re)allocation was a major management issue. Another issue was that of internal competition between projects – for financial and human resources.  In fact, the latter was one of the most significant challenges faced by both organisations. Finally, in both organisations, problems were dealt with in an ad-hoc way, often resulting in solutions that caused more issues down the line.

From the common problems identified, it was clear that:

In both organizations, the primary management issue revolved around resources. The portfolio management was overwhelmed issues concerning prioritization of projects and, distribution of personnel from one project to another, and the search for slack resources. However, there were no resources available. Furthermore, when resources were redistributed it often produced negative effects on other projects of the portfolio. This forced the management to continuous fire fighting, resulting in reactive behavior and short-term problem solving. However, the primary lever for portfolio management to affect an ongoing project in trouble was resource re-allocation.

There are a couple of points to note here. Firstly, resource re-allocation did not work. Secondly,  despite major differences in between the two organisations, both suffered from similar resource allocation  issues. This suggests that this resource allocation syndrome is a common problem in multi-project environments.

Understanding the syndrome

Based on data gathered, the authors identify a number of factors that affect resource allocation.  These are:

  1. Failure in scheduling: this attributes the resource allocation syndrome to improper scheduling rather than problems of coordination and transition. The fact of the matter is that it is impossible for people to shift seamlessly from one project to another. There is – at the very least – the overhead of context switching. Further, projects rarely run on schedule, and delays caused by this are difficult to take into account before they occur.
  2. Over commitment of resources: This is another common problem in multi-project environments:  there are always more projects than can be handled by available personnel.  This problem arises because there is always pressure to win new business or respond to unexpected changes in the business environment.
  3. Effect of accounting methods: project organisations often bill based on hours spent  by personnel on projects. In contrast, time spent on internal activities such as meetings are viewed as costs. In such situations there is an in-built incentive for management to keep as many people as possible working on projects. A side-effect of this is the lack of availability of resources for new projects.
  4. Opportunistic management behaviour: In many matrix organisations, the allocation of resources is based on project priority. In such cases there is an incentive for project sponsors and senior managers to get a high priority assigned by any means possible. On the other hand, those who already have resources assigned to their projects would want to protect them from being poached to work on other projects.

The above factors were identified based on observations and from comments made by interviewees in both organisations.

Resource allocation (as taught in project management courses) focuses on the first two points noted above: scheduling and over-commitment. The problem is thus seen as a pure project management issue – one that deals with assigning of available resources to meet demand in the most efficient (i.e. optimal) way. In reality, however, the latter two points (which have little to do with project management per se) play a bigger role.  As the author’s state:

Instead of more scheduling, progress reports, or more time spent on review meetings, the whole system of managerial procedures has to be reconceptualized from its roots. As current findings indicate: the resource allocation syndrome of multi-project management is not an issue in itself; it is rather an expression of many other, more profound, organizational problems of the multi-project setting.

The syndrome is thus a symptom of flawed organisational procedures. Consequently,  dealing with it is beyond the scope of project management.


The key takeaway from the paper is that the resource allocation issues are a consequence of flawed organisational procedures rather than poor project management practices.  Project and portfolio managers responsible for resource allocation are only too aware of this. However, they are powerless to do anything about it because, as Engwall and Jerbrant suggest,  addressing the root cause of this syndrome is a task for executive management.

Written by K

April 27, 2011 at 5:20 am

Dialogue Mapping: a book review

with 11 comments

I’ll say it at the outset: once in a while there comes along a book that inspires and excites because it presents new perspectives on old, intractable problems. In my opinion,  Dialogue Mapping : Building a Shared Understanding of Wicked Problems by Jeff Conklin falls into this category. This post presents an extensive summary and review of the book.

Before proceeding, I think  it is only fair that I  state my professional views (biases?) upfront.  Some readers of this blog may have noted my leanings towards the “people side” of project management (see this post , for example). Now, that’s not to say that I don’t use methodologies and processes. On the contrary, I use project management processes in my daily work, and appreciate their value in keeping my projects (and job!) on track. My problem with processes is when they become the only consideration in managing projects. It has been my long-standing belief (supported by experience) that if one takes care of the people side of things, the right outcomes happen more easily; without undue  process obsession on part of the manager.  (I should clarify  that I’m not encouraging some kind of a   laissez-faire, process-free approach, merely one that balances both people and processes). I’ve often wondered if it is possible to meld these two elements into some kind of “people-centred process”,  which leverages the collective abilities of people in a way that facilitates and encourages their participation. Jeff Conklin’s answer is a resounding “Yes!”

Dialogue mapping is a process that is aimed at helping groups achieve a shared understanding of wicked problems – complex problems that are hard to understand, let alone solve. If you’re a project manager that might make your ears perk up; developing a shared understanding of complex issues is important in all stages of a project: at the start, all stakeholders must arrive at a shared understanding of the project goals (eg, what are we trying to achieve in this project?); in the middle,  project team members may need to come to a common understanding (and resolution) of tricky implementation issues; at the end, the team may need to agree on the lessons learned in the course of the project and what could be done better next time. But dialogue mapping is not restricted to project management – it can be used in any scenario involving diverse stakeholders who need to arrive at a common understanding of complex issues. This book provides a comprehensive introduction to the technique.

Although dialogue mapping can be applied to any kind of problem – not just wicked ones – Conklin focuses on the latter. Why? Because wickedness is one of the major causes of fragmentation: the tendency of each stakeholder to see a problem from his or her particular viewpoint ignoring  other, equally valid, perspectives.  The first chapter of this book discusses fragmentation and its relationship to wickedness and complexity.  Fragmentation is a symptom of complexity- one would not have diverse, irreconcilable viewpoints if the issues at hand were simple.  According to Conklin, fragmentation is a function of problem wickedness and social complexity,  i.e.  the diversity of stakeholders.  Technical complexity is also a factor, but a minor one compared to the other two. All too often, project managers fall into the trap of assuming that technical complexity is the root cause of many of their problems, ignoring  problem complexity (wickedness) and social complexity. The  fault isn’t entirely ours; the system is partly to blame:  the traditional, process driven world is partially  blind to the non-technical aspects of complexity.  Dialogue mapping helps surface issues that arise from these oft ignored dimensions of project complexity.

Early in the book,   Conklin walks the reader through the solution process for a hypothetical design problem. His discussion is aimed at highlighting some limitations of the traditional approach to problem solving. The traditional approach is structured; it works methodically through gathering requirements, analysing them, formulating a solution and finally implementing it. In real-life, however,  people tend to dive headlong into solving the problem. Their approach is far from methodical – it typically involves  jumping back and forth between hypothesis formulation, solution development, testing ideas, following hunches etc. Creative work, like design, cannot be boxed in by any methodology, waterfall or otherwise. Hence the collective angst on how to manage innovative product development projects. Another aspect of  complexity arises from  design polarity;  what’s needed (features requested) vs. what’s feasible(features possible)   –  sometimes called the marketing and development views.  Design polarity is often the cause of huge differences of opinion within a team;  that is,  it manifests itself as social complexity.

Having set the stage in the first chapter, the rest of the book focuses on describing the technique of dialogue mapping. Conklin’s contention is that fragmentation manifests itself most clearly in meetings – be they project meetings, design meetings or company board meetings. The solution to fragmentation must, therefore, focus on meetings.  The solution is  for the participants to develop a shared understanding of the issues at hand, and  a shared commitment to  a decision and action plan that addresses them. The second chapter provides an informal discussion of how these are arrived at via  dialogue that takes place in meetings.  Dialogue mapping provides a process – yes, it is a process – to arrive at these.

The second chapter also  introduces some of the elements that make up the process of dialogue mapping. The first of these is a visual notation called IBIS (Issue Based Information System). The IBIS notation was invented by Horst Rittel, the man who coined the term wicked problem. IBIS consists of three elements depicted in Figure 1 below – Issues (or questions), Ideas (that generally respond to questions) and Arguments (for and against ideas – pros and cons) – which can be connected according to a specified grammar (see this post for a quick introduction to IBIS or see Paul Culmsee’s series of posts on best practices for a longer, far more entertaining one). Questions are at the heart of dialogues (or meetings) that take place in organisations – hence IBIS, with its focus on questions, is ideally suited to mapping out meeting dialogues.

IBIS Elements

Figure 1: IBIS Elements

The basic idea in dialogue mapping is that a skilled facilitator maps out the core points of the dialogue in real-time, on a shared display which  is  visible to all participants. The basic idea is that participants see their own and collective contributions to the debate, while the facilitator fashions these into a coherent whole. Conklin’s believes that this can be done, no matter how complex the issues are  or how diverse and apparently irreconcilable the opinions. Although I have limited experience with the technique, I believe he is right: IBIS in the hands of a skilled facilitator can help a group focus on the real issues, blowing away the conversational chaff. Although the group as a whole may not reach complete agreement, they will at least develop a real understanding of other perspectives. The third chapter, which concludes the first part of the book,  is devoted to an example that illustrates this point.

The second part of the book delves into the nuts and bolts of dialogue mapping. It begins with an introduction to IBIS – which Conklin calls a “tool for all reasons.” The book provides a nice informal discussion, covering elements, syntax and conventions of the language. The coverage is good, but I have a minor quibble : one has to read and reread the chapter a few times to figure out the grammar of the language. It would have been helpful to have an overview of the grammar collected in one place (say in a diagram, like the one shown in Figure 2). Incidentally, Figures 1 and 2 also show how an IBIS map is structured:  starting from a root question (placed on the left of the diagram) and building up to the right as the discussion proceeds.

Figure 2: Legal Links in IBIS

Figure 2: Legal Links in IBIS

A good way to gain experience with IBIS is to use it to create issue maps of arguments presented in articles.  See this post for an example of an issue map based on Fred Brooks’ classic article, No Silver Bullet.

Dialogue mapping is issue mapping plus facilitation. The next chapter – the fifth one in the book – discusses facilitation skills required for dialogue mapping. The facilitator (or technographer, as the person is sometimes called) needs to be able to listen to the conversation, guess at the intended meaning, write (or update) the map and validate what’s written; then proceed through the cycle of listening, guessing, writing and validating  again as the next point comes up and so on. Conklin calls this the dialogue mapping listening cycle (see Figure 3 below).  As one might imagine, this skill, which is the key to successful dialogue mapping, takes lots of practice to develop. In my experience, a good way to start is by creating IBIS maps of issues discussed in meetings involving a small number of participants.  As one gains confidence through practice, one shares the display thereby making the transition from issue mapper to dialogue mapper.

One aspect of the listening cycle is counter-intuitive – validation may require the facilitator to interrupt the speaker.  Conklin emphasises that it is OK to do so as long as it is done in the service of listening. Another important point is that when capturing a point made by someone, the technographer will need to summarise or interpret the point. The interpretation must be checked with the speaker.  Hence validation – and the  interruption it may entail – is not just OK, it is absolutely essential. Conklin also emphasises that the facilitator should focus on a single person in each cycle – it is possible to listen to only one person at a time.

Figure 3: Dialogue Mapping Listening Cycle

Figure 3: Dialogue Mapping Listening Cycle

A side benefit of interrruption is that it slows downs the dialogue.  This is a good thing because everyone in the group gets more time to consider what’s on the screen  and how it relates (or doesn’t) to their own thoughts. All too often, meetings are rushed, things are done in  a hurry, and creative creative ideas and thoughts are missed in the bargain. A deliberate slowing down of  the dialogue counters this.

The final part of the book – chapters six through nine – are devoted to advanced dialogue mapping skills.

The sixth chapter presents a discussion of the types of questions that arise in most meetings. Conklin identifies seven types of questions:

Deontic: These are questions that ask what should be done in order to deal with the issue at hand. For example: What should we do to improve our customer service? The majority of root questions (i.e. starting questions) in an IBIS map are deontic.

Instrumental: These are questions that ask how something should be done. For example: How can we improve customer service? These questions generally follow on from deontic questions. Typically root questions are either deontic or instrumental.

Criterial: These questions ask about the criteria that any acceptable ideas must satisfy. Typically ideas that respond to criterial questions will serve as a filter for ideas that might come up. Conklin sees criterial and instrumental questions as being complementary. The former specify high-level constraints (or criteria) for ideas whereas the latter are nuts-and-bolts ideas on how something is to be achieved. For example, a criterial question might ask: what are the requirements for improving customer service or how will we know that we have improved customer service.

Conklin makes the point that criterial questions typically connect directly to the root  question.  This makes sense: the main issue being discussed is usually subject ot criteria or constraints. Further, ideas that respond to criterial questions (in other words, the criteria) have a correspondence with arguments for and against the root questions. This makes sense:  the pros and cons that come up in a meeting would generally correspond to  the criteria that have been stated. This isn’t an absolute requirement – there’s nothing to say that all arguments  must correspong to at least one criterion – but it often serves as a check on whether a discussion is taking all constraints into account.

Conceptual: These are questions that clarify the meaning of any point that’s raised. For example, what do we mean by customer service? Conklin makes the point that many meetings go round in circles because of differences in understanding of particular terms. Conceptual questions surface such differences.

Factual: These are questions of fact. For example: what’s the average turnaround time to respond to customer requests? Often meetings will debate such questions without having any clear idea of what the facts are. Once a factual question is identified as such, it can be actioned for someone to do research on it thereby saving a lot of pointless debate

Background: These are questions of context surrounding the issue at hand. An example is: why are we doing this initiative to improve customer service? Ideas responding to such questions are expected to provide the context as to why something has become an issue.

Stakeholder: These are the “who” questions. An example: who should be involved in the project? Such questions can be delicate in situations where there are conflicting interests (cross-functional project, say), but need to be asked in order to come up with a strategy to handle differences opinion. One can’t address everyone’s concerns until one knows who all constitute “everyone”.

Following the classification of questions, Conklin discusses the concept of a dialogue meta-map – an overall pattern of how certain kinds of questions naturally follow from certain others. The reader may already be able to discern some of these patterns from the above discussion of question types. Also relevant here are artful questions – open questions that keep the dialogue going in productive directions.

The seventh chapter is entitled Three Moves of Discourse. It describes three conversational moves that propel a discussion forward, but can also upset the balance of power in the discussion and evoke strong emotions. These moves are:

  1. Making an argument for an idea or proposal (a Pro)
  2. Making an argument against an idea (a Con)
  3. Challenging the context of the entire discussion.

Let’s look at the first two moves to start with. In an organisation, these moves have a certain stigma attached to them: anyone making arguments for or against an idea might be seen as being opinionated or egotistical. The reason is because these moves generally involve contradicting someone else in the room. Conklin contends that dialogue mapping takes removes these negative connotations because the move is seen as just another node in the map. Once on the map, it is no longer associated with any person – it is objectified as an element of the larger discussion. It can be discussed or questioned just as any other node can.

Conklin refers to the last move – challenging the context of a discussion – as “grenade throwing.” This is an apt  way of describing such questions because they have the potential to derail the discussion entirely. They do this by challenging the relevance of the root question itself.  But dialogue mapping takes these grenades in its stride;  they are simply captured as any another conversational move – i.e. a  node on the map, usually a question.  Better yet, in many cases further discussion shows how these questions might connect up with the rest of the map. Even if they don’t, these “grenade questions” remain on the map, in acknowledgement of the dissenter and his opinion.  Dialogue mapping handles such googlies (curveballs to baseball aficionados) with ease, and indicates how they might connect up with the rest of the discussion – but connection is neither required nor always desirable. It is OK to disagree, as long as it is done respectfully. This is a key element of shared understanding – the participants might not agree, but they understand each other.

Related to the above is the notion of a “left hand move”. Occasionally a discussion can generate a new root question which, by definition, has to be tacked on to the extreme left of the map.  Such a left hand move is extremely powerful because it generally relates two or more questions or ideas that were previously unrelated (some of them may even have been seen as a grenade).

By now it should be clear that dialogue mapping is a technique that promotes collaboration – as such it works best in situations where openness, honesty and transparency are valued. In the penultimate chapter, the author discusses some situations in which it may not be appropriate to use the technique. Among these are meetings in which decisions are made by management fiat. Other situations in which it may be helpful to “turn the display off” are those which are emotionally charged or involve interpersonal conflict. Conklin suggests that the facilitator use his or her judgement in deciding where it is appropriate and where it isn’t.

In the final chapter, Conklin discusses how decisions are reached using dialogue mapping. A decision is simply a broad consensus to mark one of the ideas on the map as a decision.  How does one choose the idea that  is to be anointed as the group’s decision? Well quite obviously: the best one. Which one is that? Conklin states, the best decision is the one that has the broadest and deepest commitment to making it work. He also provides a checklist for figuring out whether a map is mature enough for a decision to be made. But the ultimate decision on when a decision (!) is to be made is up to group. So how does one know when the time is right for a decision? Again, the book provides some suggestions here, but I’ll say no more except to hint at them by paraphrasing from the book: “What makes a decision hard is lack of shared understanding. Once a group has thoroughly mapped a problem (issues) and its potential solutions (ideas) along with their pros and cons, the decision itself is natural and obvious.”

Before closing, I should admit that my experience with dialogue mapping is minimal – I’ve done it a few times in small groups. I’m not a brilliant public speaker or facilitator, but I can confirm that it  helps keep a discussion focused and moving forward.  Although Conklin’s  focus is on dialogue mapping,  one does not need to be a facilitator to benefit from this book; it also provides a good introduction to issue mapping using IBIS. In my opinion, this alone  is worth the price of admission.  Further,  IBIS can  also be used to augment project (or organisational) memory.  So this book potentially  has something for you,  even if you’re not a facilitator and don’t intend to use IBIS in group settings.

This brings me to the end of my long-winded summary and review of the book.  My discussion, as long as it is, does not do justice to the brilliance of the book. By summarising the main points of each chapter (with some opinions and annotations for good measure!), I have attempted to convey a sense of what a reader can expect from the book.  I hope I’ve succeeded in doing so. Better yet, I hope I have  convinced you that the book is worth a read, because I truly believe it is.

%d bloggers like this: