The Cynefin Framework

I recently built a deck for my mom in her backyard. It's a freestanding 10 by 10 deck. And you know one thing about decks, they eat nails. What do you think the right tool for that particular job is? Well, that's right, obviously it's a hammer. Now could I use a heavy duty set of pliers to put in the nail? Possibly, but it's not really what the pliers were intended for. It's not the right tool for the job. And if I did use that set of pliers, well then it'd probably take, you know, two or three times longer and there'd be all kinds of quality issues. So. So it's important to choose the appropriate tool for the job at hand. This is the same logic that applies to the domain of project management. So let me introduce you to a sense making framework for helping you sort of reason through the nature of the work that you're dealing with and the best project delivery approach to take. It's called the Cynefin Framework. The Cynefin Framework identifies four domains of decision making context. Let's start by looking at the clear domain. When we're working with clear systems, there's an obvious cause and effect relationship. Any reasonable person can see the relationship and just know exactly what to do, like turning on a light with a light switch. Most of the work that you'll encounter likely does not fall in the clear domain because it requires some certain subject matter expertise for us to understand. And that brings us into the complicated domain. Now with the complicated domain, we still have a cause and effect relationship, but the connection is not obvious and it requires subject matter expertise to see that connection. These are problems that have multiple possible solutions and they're not really self evident. It's like the electrical wiring for a whole building. Uncertainty with this type of work is pretty low. We know what it takes to wire the building, but we do need expertise to build the right plan and then to execute it. But the key with complicated systems is once you have that expertise, you truly can build a plan and execute that plan and you'll get the outcome you're after. And then there's complex. Now these are problems with many unknown factors. The solution begins to emerge through experimentation. These are filled with uncertainty. It's like managing the power grid during peak usage times. The operators have to constantly monitor, adjust and balance load to prevent outages. Systems in the complex domain, well, they're unpredictable. They have a high degree of uncertainty. These include systems like the economy or traffic, weather, organizations, relationships, and of course product development. These are all considered complex systems. Now why is that? Well, it's because they're filled with uncertainty. If we're building a new product or a new feature, it's often unclear what exactly we need to develop to get the customer to click the buy now button or whatever the outcome is that we're hoping for. So if you're working in a complex system, this sort of deterministic, you know, plan the work work the plan type approach is a kind of a recipe for disaster because that may lead us down the paths of building the wrong thing for the wrong person at the wrong time. This is the worst thing I have ever seen. Agile approach is helpful in this context because it provides a way for us to accelerate feedback, learning, customer engagement. These are absolutely essential. Lastly, we have chaos. In the chaos domain, we have to take immediate action. Do we have to stabilize whatever the situation is? Like if the light switch suddenly started sparking and smoking, you wouldn't take time to figure out the wiring. You need to act immediately. Now, hopefully you're not doing too much work in the chaotic dom. If you are, you have bigger fish to fry. Now, the last domain, sort of here in the middle, this is called disorder. You're working in the disordered domain when you simply don't understand the type of system you're dealing with. And unfortunately, this is the domain I see many project managers in. Most of the time they have one tool and every project gets whacked with it. It doesn't matter if the project's complicated or complex, they're all treated the same. And that's problematic because our industry is filled with failed projects, projects that are months over schedule or millions of dollars over budget, or. Or fail to deliver the outcomes that our customers need. So we, as project managers, we have to do better. And it starts by understanding the type of project we're being asked to manage and whether or not an agile approach will prove beneficial. Now think about a recent project that you've supported. Was it something you delivered many times before and that time would be no different? If so, then a sequential project management type approach, that's probably the right tool. Or instead, was it a project where the solution was novel, Something where there's a lot of uncertainty around, like what the specific requirements are? If so, so then you're likely dealing with complexity. Again, this is the sweet spot for an agile approach. The success or failure of your project hinges on the management approach that you choose. So choose wisely and use the Knevin model to help you and your stakeholders reason through the nature of the work and whether or not taking an agile approach is the right move.