Skip to content
ITSM.tools
  • Articles
    • Hot Topics
    • ITIL
    • ITSM
    • Self-Service & Chat
    • Service Desk
  • Tool Reviews
  • Resources
    • Premium Content
    • Events
    • Newsletter
  • About Us
    • Who We Are
    • Meet The Team
    • Get Involved
  • Contact Us
  • Search

The Value of the Cynefin Framework to ITSM

Akshay Anand
November 14, 2017
Hot Topics
Share on facebook
Share on twitter
Share on linkedin

In November 2017 (or back in November 2017, depending on when you're reading this), I will have (or have had) the privilege of speaking at the annual itSMF UK conference (ITSM17) on the value of the Cynefin framework to IT service management (ITSM). There is so much that I could say about this topic; in fact it was all my conference buddy (the sagacious Daniel Breston) could do to prevent my talk from becoming a two-day lecture!

The Cynefin framework has previously received an enthusiastic reception from governments, NGOs, think tanks, and the Agile community. However, surprisingly, there is limited knowledge and adoption within the service management community, which is something I feel needs to be addressed.

I don’t intend to repeat my presentation here, so I’ll assume you understand the terms I’m about to use.

While it’s tempting and easy to categorize our organizations and ITSM departments into one of the domains, reality is rarely that neat – in fact, your organization is likely occupying at least three domains: “Obvious”, “Complicated”, and “Complex”, and has the ability to slip into “Chaotic” when bad decisions are made, or a bad situation is left unchecked. I like to say that the “IT” in ITSM will more likely act in the ordered domains, while the “SM” in ITSM will more likely be in the unordered domains.

Here’s an example of that distinction: in my talk, I describe the difference between technical cause (the event of transaction leading to an incident, which can be discovered with sufficient analysis) and root cause (the underlying “environmental” conditions that allowed the incident to occur). In other words, technical aspects of what we call “root cause analysis” can be considered to be sitting in the “Obvious” or “Complicated” domains, but the human or “environmental” aspects would sit in the “Complex” domain.

But what does it mean to be in the “Complex” domain … or more generically, what is a “complex adaptive system”? There's a lot of science behind those words, but let's focus on some commonly accepted properties, and how they apply to the field of service management:

  1. The number of "agents" (or parts) in the system are sufficiently large that conventional descriptions are impractical, or may even harm our ability to understand the system.The traditional ITIL® definition breaks a service down into people, processes, products, and partners (the "4P model"). That's a deceptively small list, which could be expanded to cover IT teams, non-IT teams, contractors, consultants, trainers, tool vendors, auditors, regulators, and various technical systems and components (and that isn't an exhaustive list, either!) We can't possibly hope to model or discover every link (and the way those links change over time) between every agent.If we were to run a series of simulations of a complex system, using the same starting conditions, we would get different results every time. Einstein is broadly credited with saying “The definition of insanity is doing the same thing over and over again, but expecting different results.” I wonder if he’d withdraw that quote after reading up about complex systems!
  2. There is no single leader co-ordinating every agent in a systemLook at that list of agents above – there isn’t a single leader directing their actions (conspiracy theories aside).
  3. Individual agents follow simple rulesAt a micro level, we can predict the behavior of an individual component with relative ease. Consuming a service will increase my bill at the end of the month. A red light on a monitoring dashboard will create a ticket. It’s when we put everything together at scale that we lose the ability to model the system – in other words, the system is greater than the sum of its parts.Fun aside: in Isaac Asimov’s Foundation series, the technique of Psychohistory depended on the idea that while we cannot foresee the actions of a particular individual, mathematical techniques could be used to predict the general flow of future events.
  4. The interactions of large groups of agents will generate emergent patternsThe dynamics between agents in a complex system will give rise to novel patterns or structures. Some of the best ways to explain this are in nature – a snowflake looks nothing like water. Unofficial support groups, or shadow IT, emerge as a result of perceived failures in a support organisation.
  5. The system adapts around, or reacts to, interactions, emergent patterns, or alterations. Outputs feedback as inputs.As various agents interact, and as patterns emerge, a complex system will adapt and mould itself around these patterns. For example, changes to your service desk policy will make the business change the way it behaves with customers, with IT, and other agents in the system. This in turn will change the way the IT organization (and the service desk) behaves, and so on.Each little change to an agent has the potential to change the system.

So how can we possibly hope to manage our complex, adaptive IT services? There are many possible techniques that could be used, but I would like to return to the Cynefin framework, where the rule of thumb is to “Probe, Sense, Respond”.

  1. Probe: Make a small change to an agent under your control. Modify the service desk policy to limit interactions to email-only. Introduce standard, pre-approved changes.
  2. Sense: Recognize the pattern and behaviors that have emerged from your change. Using the above examples, perhaps the number of service desk contacts have dropped, but business satisfaction has increased (perhaps due to shadow IT … or is it bad metrics?) Perhaps the number of successful changes has increased, but the number of incidents has also increased (perhaps due to lower service resilience … or is it because the larger changes are not being adequately tested as resources are tied up with routine change?)
  3. Respond: Figure out how you can encourage the behaviors or patterns you want, and discourage those you don’t want. But remember – the encouragement/ discouragement itself will change the system!

There’s a lot of literature describing properties and behaviors of complex systems, as well as writing on relevant management techniques. I would encourage service management professionals to take a look at Cognitive Edge and the Cynefin framework if you wish to learn more.

Share on facebook
Share on twitter
Share on linkedin

Want ITSM best practice and advice delivered directly to your inbox? Why not sign up for our newsletter? That way you won't miss any of the latest tips and tricks.

Sign up now!
Akshay Anand Photo
Akshay Anand
ITSM Service Architect and Product Manager at AXELOS

Akshay Anand is an IT service management professional, with over 13 years'​ global experience in designing and implementing ITSM , and managing IT services. He has extensive experience in delivering ITSM transformations, leveraging tools such as ServiceNow and holds the ITIL Expert Certification. He is currently the ITSM Service Architect and Product Manager at AXELOS.

More Articles That You May Like

Stephen Mann
Oct. 17, 2017
10 Tips for IT-Support Chat Success
In aiming for chat success, it’s worth comparing chat with the currently-far-more-popular IT self-service. There are many similarities, here we aim to dive into them in a little more detail.
Continue Reading
Vladimir Leinov
Mar. 08, 2018
Garry Protter and the Order of ITIL Change Management
See how ITIL change management works in real life – practical advice, with a pinch of drama. Read more about Garry Protter here.
Continue Reading
Parit Patal
Feb. 23, 2017
The self-service approach to customer service has gone too far. Can we shift the burden onto an Artificial Intelligence system instead?
Continue Reading

Write Your Opinion

avatar
wpdiscuz_captcharefresh
avatar
wpdiscuz_captcharefresh
  Notifications  
Notify me about
Twitter Facebook Linkedin
Crafted with by Maurice Hason
  • Terms & Conditions
  • Privacy Policy
  • Transparency Statement
  • Editorial Guidelines
Menu
  • Terms & Conditions
  • Privacy Policy
  • Transparency Statement
  • Editorial Guidelines
We use cookies to ensure that we give you the best experience on our website. By continuing to use this site, you agree to the use of cookies.
OK, I Accept No, I Reject
Find out more.
wpDiscuz
Scroll to Top