Using Cynefin to make sense of projects

Since a couple of years we have been using Cynefin to help our customers to make sense of the different domains of projects they are executing. The motivation for doing so, is that we strongly believe that the one-size-fits-all approach that dominates most of the thinking today, is a major source of project failure.

In general we have found that most organizations do have projects that very much align with the different Cynefin domains. These domains include the following types of projects:

Routine projects (ref. Cynefin “simple/known” domain)

These are projects that the organization is executing on a very regular basis with very low risk and high predictability. The challenge in this domain of projects is not in the delivery of a single project but the increasingly efficiently delivery of many routine projects with increasing levels of quality. Consider for example a web-site development company that delivers web sites on a very regular basis (1 per week) with a relatively standard process and within relatively standard constraints. The organization has developed a routine for delivering such projects. It needs to ensure that it is increasingly efficient and quality is continuously improving. Often times the work is routinized to the extent that it is considered to be a continuous service rather than individual projects.

Of all “project management” approaches, Kanban is most appropriate in this domain. The Kanban properties of visualizing the workflow,  limiting work in progress, measuring and managing flow, making process policies explicit, using models to recognize improvement opportunities are critical in the routine domain.

Extension projects (ref. Cynefin “complicated/knowable” domain)

These are projects that are in extension of the organizations current capabilities and expertise. While there may be a certain level of uncertainty involved, this uncertainty can be assessed by experts in the organization. Uncertainty may be both on the side of the value of the project (do we know what we need to build?) as well as on the side of the execution (do we know how to build it and do we have the capabilities?). Most importantly the risk can be assessed and managed. Typical for this project domain is also that risk can be managed by close interaction with the customer (i.e. there is a trust relationship that allows close interaction between project team and customer and iteration to a solution). Many development projects are in this area if they are properly set up (if they are not properly set up, they will end up in the sensitive domain below).

In the domain of extension projects, project managers need to be equipped to manage project risk by means of iterative delivery of the project results. Kanban can be extended into this domain as explained in the post on end-to-end project cycle.

Emergent projects (ref. Cynefin “complex” domain)

These are the projects where there is a large uncertainty about the value of the project (we may not even know who the real customers are) but we have ways to do experiments with low cost of failure and where we can quickly learn from these experiments. Project objectives are emergent based on direct customer feedback. True innovation projects that are properly set up fall into this domain.

In the emergent domain notions like iterative customer discovery as advocated by the lean start-up community are critical.

Sensitive projects (ref. Cynefin “chaos” domain)

These are the projects where there is a (lethal) combination of uncertainty about the value of the project and the execution of the project (how to deliver the value). In other words there is a combination of human uncertainty and technological uncertainty. Typically, these are projects surrounded by conflict, disagreement and ambiguity. It is exactly the combination of human uncertainty and technological uncertainty that is the breeding ground for rapidly cascading failure in these projects. Typical projects in this domain are large projects with substantial re-architecting of the existing infrastructure or capabilities.

Many development projects (that should be in the extension domain) also end up in the sensitive domain because of lack of trust between the customer and the supplier or lack of knowledge of how to set up such projects (E.g. setting the project up as a waterfall instead of iterations). Often times organizations move themselves into the sensitive/chaos domain by not properly aligning themselves around a common purpose. Whatever the reason for this – lack of trust, lack of vision, lack of management know-how -, in the end it leads to local optimization.

Still, often times the chaos/sensitivity comes from external factors. As in the large re-engineering project that was mentioned above. The organization is confronted with a rapidly changing technology landscape and needs to adapt its (large and complex) software to that and at the same time there is a high pressure to deliver new features as the competitive pressure in the market grows. It needs to change the engine of the car while driving at 100mph so to speak.

This seems to be more and more the new normal. It seems that in today’s business environments, dealing with contradictory and contingent goals (or objectives if
you like) can not be done away with as an anomaly but are an essential part of doing business. This poses – in my opinion – a serious challenge for how we think about management and project management in particular as our dominant models seem to rely on clear, consistent, stable goals.

In the domain of sensitive projects, project managers need to understand how to deal with contradictory goals, cascading failure, etc. This requires an insight in complexity models just like Cynefin which brings us back to the topic of this post – the need for project managers to take a broader view and abandon the one-size-fits-all approach. Herein lies the fundamental next step in delivering projects more successful.

About these ads
This entry was posted in Uncategorized. Bookmark the permalink.

One Response to Using Cynefin to make sense of projects

  1. Professionals that truly master the project management practices indeed are proficient in using those bits and pieces from his own and other’s experiences, standard methods & models, etc. adapt it and make it work. The differentiation of project types along the levels of uncertainty and complexity is essential.
    A common inhibitor to this advanced practice is the company policy for compliance to the corporate PM methodology which is based on a particular standard such as Prince2 or PMBOK.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s