Knowledge Matters

Understanding knowledge relationships

Cynefin, Complexity and Project Management

I've done a good deal of reading lately around my usual themes of knowledge management, project management, and network analysis. I've also been reading a good deal about chaos, complexity, and systems, which are other areas of interest. In synthesising all of these disciplines I've come to realise just how useful Dave Snowden's Cynefin Framework actually is, and I have decided to incorporate it into my doctoral thesis. I just wish Dave would publish his long promised and overdue book. So I can gain a greater understanding of his framework I've decided to enrol in his next course in Australia , but I digress.

In an earlier blog I mentioned of Remington and Pollack's book "Tools for Complex Projects ". They classify projects as being structurally complex, technically complex, directionally complex, and/or temporarily complex. Now it seems to me their classification and the Cynefin Framework fit together very nicely, as shown in the illustration.

Cynefin Framework and Project Management

Structurally complex projects are large projects with many different interconnected tasks and activities. They are complicated rather than complex, and are managed using good or best practice techniques. Typically they are decomposed into many small deliverables, which are managed as discrete units based on the assumption that when delivered they will come together to form the whole. They therefore sit either in the complicated domains or the edge of the simple domain. The management aim is to push them completely into the simple domain.

Technically complex projects have multiple inter-dependent solution options. They are complex rather than complicated, and are managed using emergent practices. Typically they have ill-defined design or outcomes, or there are no known precedents. They therefore sit in the complex domain, and the management aim is to push them completely into the complicated domain.

Complexity in directionally complex projects results from ambiguity caused by unshared goals, hidden agendas, and unclear objectives. These projects are often chaotic rather than complex or complicated. They are socially and politically challenged projects, where project success is highly dependent on understanding and managing stakeholder relationships, expectations and requirements. The management aim is to establish shared understanding from multiple perspectives, and move them into the complex or complicated domains as soon as possible.

Complexity in temporally complex projects arises from fluid environmental and strategic factors. This fluidity destabilizes the project and results in further organizational and system uncertainty. These projects are complex or chaotic rather than complicated, and typically require understanding of the relationships between multiple inter-dependent solution options, stakeholders and project artifacts.

Now in my experience most large projects have two or more of these qualities. For example, a structurally complex project can also be temporally complex, and a technically complex project is often directionally complex. It seems to me understanding of relationships and networks at the artefact, project team, intra-organisational and inter-organisational is vital to success. I know how to do this using Business Network Analysis™ techniques, and I'm looking forward to Dave's course to see how his methods can add to deconstructing complexity. As I've argued for some time now linear project management methods are insufficient; they work in simple domain, but as soon as complexity of any type is introduced they begin to fail. Understanding portfolio complexity matters if all projects are to be delivered on time, at quality, and to budget.

Regards Graham

Copyright © 2004 -2012 Knowledge Matters™ - all rights reserved
The Webpages and Occasional Blog of Graham Durant-Law
E-mail: graham@durantlaw.info

Clicky