The Cynefin framework identifies five domains within which systems and environments can co-exist. In summary the five domains are:

  • The ‘Simple‘ Domain – characterized by clear cause-and-effect relationships, with well-defined rules of engagement that call for the use of best practice approaches.
  • The ‘Complicated’ domain – where the relationships between cause-and-effect are not straight forward but are discernible subject to some level of analysis or investigation with the application of expert knowledge.
  •  The ‘Complex‘ domain – where the relationship between cause-and-effect can only be perceived in retrospect
  • The ‘Chaos‘ domain – where uncertainty is abound and no discernible cause-and-effect relationship are known to exist.
  • Disorder‘ – when no clear realization exists regarding the state at which the situation is and where no clear action can be taken due to conflicting views and complete lack of leadership.

When tying the concept of software development estimation with the Cynefin framework one has to consider (or rather ‘sense’) in which domain the system and the environment are and, based on that assessment, tailor the estimation process to account to that situation. The situations most likely to be present at the outset of the estimation process are as follows: Cynefin combinations Some of the objections to carrying out estimates touch on the variability (or rather uncertainty) associated with the state of either the System or the Environment. The Cynefin Framework recognizes the difficulty associated with managing complex situations and suggests an approach to effectively get them managed. Tackling complexity requires resident knowledge about the system and its environment and, more importantly, requires adaptation and openness to learn about them. Experimentation management is the key to overcome the fear of tackling the unknown. Rather than adopting an attitude of ‘it cannot be done’ I would suggest that an attitude of ‘let’s put in a place a process of experimentation so we can tackle the unknown’ would better serve the needs of both those delivering the estimates and those requiring them for business decision-making. Think about it!                       aaa

Print Friendly

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...


  1. It might be useful to gather enough data to identify the distribution of actual IT projects among those seven combinations of system and environment, in both the number of projects and dollar value. Of course, one man’s chaotic is another man’s complicated, so you’d need some objective measures. Then, you could do an analysis of the projects actually being executed using the #NoEstimates approach to see how their distribution compares to those attempting to make estimates in order to project ROI, assess alternative investments, and prioritize.

    I’m a big fan of the Proof of Concept for applying new technology to a new problem. A limited scope, limited duration project to gain enough experience and knowledge to make decisions about whether to proceed can be invaluable. But at the end of the pilot, the team better have learned enough to make useful estimates of cost, schedule, quality, business benefit, and risk profile, or I’m going to shovel dirt down that rabbit hole so no one trips over it again.


    • Hi Gordon, thanks for your comment.

      I didn’t elaborate in this post on the fundamentals of Cynefin. Cynefin is a sense-making framework, not a categorization one. As such, to the best of my understanding, the determination of whether a system or an environment are simple, complicate, complex or chaotic are subjective (as you correctly observe) but also carry a tinge of objectivity in that if you sense your circumstances as being Simple but the future evidence suggests that things do not work out as you believed they would, that will objectively prompt you to re-evaluate and re-consider your position (re-sense).

      Two other points:

      1. My point about #NoEstimates was about their broad brush determination that everything is Complex (at the very least) or even Chaotic and thus does not lend itself to estimation. I challenge this view without the need to run a survey. My own experience (and that provided by other project managers) tells me that non all projects are born in a chaotic environment and my own experience tells me that estimates are not always utterly wrong. That should be enough to suggest that given a broad understanding of system theory one would need to re-consider the #NoEstimates hypothesis.
      2. I agree with the notion using POCS to narrow down options and reduce uncertainty. In fact, that, to some degree, is how Agile meant to work. Having said that, again – based on the Cynefin framework – not every situation requires the application of POCs. Simple or Complicated scenarios, where known practices, or practices known by expert advice, do not necessarily need that level of risk reduction and funds would be better spent on ‘doing the work’ rather than exploring the work.

      Cheers, Shim.


Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: