decision making for a complex world

decisionmaking My post mission is ripe for disruption stimulated a lot of thought about the way forward for mission agencies.  Most people agree that we are operating in a time where the pace of change means that we need to develop agile systems and procedures.  However we all seem to be getting stuck on answering the question of what these agile systems and procedures will look like? and how will we get there?  Moving forward is not just about changing systems and procedures to move into the new way of working and being in the world.   Organisations need to develop new ways of making decisions.  Many of the old fashioned organisational decision making procedures (like a swot analysis for example) are based on the simple notion that what worked in the past will work again in the future.  To move forward we must acknowledge that we can no longer rely on that notion.  What worked in the past can no longer be counted on to inform our work in the future. So we need to develop new ways of making decisions. In the September issue of the Missions Interlink Bulletin (More about MI here) Jay Matenga introduced the Cynefin framework as a base for understanding agile decision making.  Steve Pavarno then discussed how this could be applied to mission organisations.  (I am re-printing their comments here with permission).

The Cynefin Framework

Cynefin [Kih-NEH-vihn] is a Welsh word for “habitat”, with a meaning very similar to the Maori word, turangawaewae. It conveys a sense of belonging to a place, where you feel empowered and connected. It describes the largely implicit relationship between a person and their place of birth and upbringing, the environment in which they live and to which they are naturally acclimatised. It is a domain you are used to.

Welsh theorist Dave Snowden co-opted the word and its concepts to map a paradigm (framework) to help explore relationships between people, their experience, and their contexts (including their historical and cultural contexts, which are predominantly implicit). The aim is to help discern how best to respond to a situation given the particularities of it—from simple to chaotically complex. It is ultimately a sense-making model (making sense out of data) to assist with decision making in the midst of increasing uncertainty. Depending on which territory you find yourself in, you need to think, analyse and respond differently. This model helps us navigate increasingly unknown territory.

cynefin-framework

 

The Cynefin framework (above) has five domains, like geographic domains separated by flexible and porous borders. The left two are the unordered domains (complex and chaotic), the right two are both ordered systems.

The five domains are:

Obvious. The relationship between cause and effect is self-evident to all. To apply best practice you simply sense the data, categorise it and then respond, step by step by the book (which is already written). This is the bureaucratic domain.

Complicated. The relationship between cause and effect requires some form of expert investigation and/or the application of expert knowledge. To apply good practice you need to sense, and then expertly analyse in order to develop an appropriate (fresh)response. This is the realm of expert consultants.

Complex. The relationship between cause and effect is perceived in retrospect, rarely in advance. You don’t even know what questions to ask beforehand. To discern emergent practice you  need to probe and examine to gather more data, then experiment to get a sense of how to respond tentatively. This usually requires an iterative (trial/error) process before the right response emerges. This is the habitat of collaborative strategists.

Chaotic. No discernible relationship exists between cause and effect at a systemic level. You need to do whatever you have to to contain the situation. You could intentionally enter this territory for innovative purposes but if you accidentally find yourself here it requires urgent attention. This will require novel practice, so you act, then sense, responding quickly and as necessary to escape the territory. It is like a hospital ER where you act quickly to stop the bleeding before looking more intently to figure an appropriate way to heal the situation. Autocrats, Dictators and Commandant types thrive here.

Disorder is the fifth domain (the dark mass in the middle), which is where you have no idea what sort of causality exists. You don’t know which domain you’re in. There is just confusion. This is no-man’s land. In this realm, people revert to their own comfort zone practice in making a decision. Here you will default to your personal preference for action, but you cannot survive here. The objective at this point is to move the situation to another part of the map to better engage with it.

Another critical aspect of the Cynefin framework is the boundary between the Obvious and Chaotic domains (which has been interpreted as a cliff, with a wave at the bottom, represented by the curious squiggle). It is too easy to become complacent in the Obvious realm (remember, this is the land of bureaucracy and clear cut policies and procedures) and drift toward the boundary into Chaotic territory. All other boundaries allow for transitions but with this one crossing the boundary is deemed to be catastrophic (hence the cliff)—you fall over the edge into a (very costly) crisis.

The recommendation is that organisations manage in the top two domains which allow for variability and flexibility and only occasionally in the Obvious domain because it is too prone to rapid and accelerated change toward the Chaotic.

The Cynefin Framework in the Software Industry

Big multinational mission agencies have operating models that are increasingly struggling with the environment they are operating in (both the sending or receiving environments). From the turn of the century the software industry has had to operate in complex and chaotic environments. These parallels offer value to the missions community, but it is first helpful to identify where we’re at. The Cynefin Framework describes successful behaviours for industries facing disruption.

Many mission organisations are operating in the “Obvious” quadrant (see diagram): applying best practices because those practices have worked in the past or are required by their international head office or other compliance regulators. But with pressure from stakeholders, they are finding best-practice is no longer enough. One size is not fitting all. To thrive, missions must adopt an operating model appropriate to the domain their industry is in (see diagram).

When best practice is no longer enough, we need to build organisations that are more agile, able to move and adapt easily, to grasp and implement new opportunities as they arise, take more risks, and even be willing to fail sometimes.

The software industry has learned agility the hard way, from many expensive failed projects. In the old days, we used “Big Design Up Front” to design software. Teams of analysts would meet for months to design a requirement’s specification. This would be handed off to systems architects, then “thrown over the wall” to programmers who would spend years writing the code, before handing it over to the testers. When it finally got to the end user, the original need had often disappeared or changed so dramatically that the product was useless. We could call this the “Ready-Aim-Fire!” cannon methodology.

In 2001 a group of developers decided to move away from traditional methods of software development, towards what they called “agile” project management. The Agile model prefers a lightweight “Ready- Fire-Aim-Aim-Aim” guided missile methodology. It prioritises relationships, communication and results over policy and documentation. It picks the most valuable (important, urgent) piece of a business problem, builds and delivers a working solution to that one piece, and then goes back for the next most important problem. Along the way, it applies learning from the previous stages with constant customer feedback to shape future decisions.  Development cycles are a few hours to a few weeks long, rather than the months or years taken by traditional methods. Google and other large tech companies run multiple parallel experiments to see what works (multivariate testing). Google have launched and later cancelled quite a number of unsuccessful products, yet the company as a whole remains very successful. This pragmatic strategy works well in a Chaotic domain (see diagram) where they have tried something, seen what works, then decided what to do next in evolutionary or progressive steps.  It’s like firing a lot of guided missiles at a swarm of moving targets.

How might agile methodology work for mission organisations?

To start, we will have to undo decades of habits and institutional inertia.

Agile software teams have a saying, “Do the simplest thing that can possibly work”.

Missions are often crippled by poor IT infrastructure and heavy administrative responsibilities, with staff running hard just to keep up. Finance systems can be antiquated or pieced together from off-the-shelf solutions that don’t integrate well. HR systems rely heavily on time consuming email and spreadsheets. Donor or stakeholder management is ad-hoc and misses opportunities to engage with people in the most appropriate ways. New initiatives are subject to lengthy Board or committee approval processes. And, funding is not available for research and development to find better ways of doing things.

Realising that we are no longer in the Obvious domain (see diagram), a first step into new territory, towards a becoming more agile, is to build agile systems (digital platforms) that automate the boring stuff. Digital transformation (if done well) can relieve humans of boring busywork and release them for building relationships and making informed decisions. Human time is far too precious to be spent copying data from one platform to another.

What would it take to become agile, to do the simplest thing, to strip away some of the habits, spreadsheets, approval cycles, policies from your organisation?

What tools (e.g. cloud services) could you use to automate workflows?

What would happen if you simply stopped doing some of the things you have done for years, or did it a different way that only took half the time?

How can you free up time and money to begin to experiment and explore?