Its common to hear the “We need a UX expert” on our project, or more likely “We don’t need a Product Owner / Business Analyst on our project”. Its much more nuanced than that. First, lets stop talking about projects and treat them for what they truly are…. investments. Someone is investing time, money or expertise. They hope for a return, or more probably expect one. So when considering an investment, it is useful to consider which domains of the Cynefin framework the investment falls into before consider what is needed. Note that I said domainS (plural), and not domain (singular).
Simple / Obvious
In the simple or obvious domain you don’t need analysis or product management. Much of enterprise software falls into this domain. “I want this report but with this extra field.” The implementation pattern that Dan North calls “Ginger Cake” says it all really. The requirement is simply stated. This is the domain where inexperienced developers can wreak havoc with “Copy and Paste Coding” rather than refactoring the code so that it only exists in one place. Subsequent COPC leads to ever increasing complexity until the code ends up in the complex domain where the impact of changes is unknowable. (Note that the code does not fall into chaos because multiple safe to fail experiments can be run until the desired outcome is achieved.) Complex and Complicated code is likely to be written in a more elegant manner as more thought has to go into it.
Complicated
This is the realm of the Analyst and the Expert. This is the domain where the investment benefits from someone with Analysis Skills working out what is needed. From my banking background, this includes things like new Regulatory Requirements, New Products, Adding or Amending Taxes. The Outcome is known and the purpose of the analysis is to identify the changes necessary in all systems. The interesting thing about this domain is that it is characterised by a lack of choice for the users. The users have to use the system if they want to keep their job. I want to use a spreadsheet so I have to use the corporate standard, normally because there is additional code and macros I need to use.
Complex
This is the realm of product management. This is the realm where Data Scientists and UX Specialists come to the fore working together to create statistically viable multi-variate tests. Multi-hypothesis Safe to Fail experiments as Dave Snowden calls them. A portfolio of tests that includes one hypothesis at odds with the rest. Imagine several different screen layouts that make it easier for the user to achieve a specified task, and one that makes it harder. The harder option may activate “System 2” and give the user a more pleasurable experience, which is why it is there. The complex domain is characterised by the non-functional requirements… Performance, Cognitive Load, Ease of Learning, Risk. These come to the fore when the user can choose how they complete a particular task. How do I keep in touch with my friends and colleagues?
Chaos
OK. So no one really knows for certain. We can make educated guesses but there is no way to even test a hypothesis to tune our understanding. This is the realm where wisdom of the crowds comes to the fore. We want our analysts, experts and product owners to come up with an independent hypothesis and the answer is probably somewhere near the average.
The kind of questions you have are “Why are our customers leaving us?”, “What is the next big thing?”. They are the questions we ask when we can no longer feel the world beneath our feet as a business. Questions that come when the market shifts.
Sometimes we are going to get it wrong and have to play a game of catch up. In which case it might be nice to have some Real Options to help us catch up faster. This is the time that we realise a mono-culture is detrimental to the future of the organisation, and having a few heretics around the place is of huge value if we need to scale our experience. Many organisations fail with Agile because they do not have enough employees deeply engaged in the community to act as pilots steering them between the ice burgs.
Chaos sometimes comes from total choice to the user. How do I spend my free time? When I’m connected the interweb? And when I’m not? Getting them to chase after the football* at the birthday party long enough for me to perform some safe to fail experiments. If only someone would get rid of the rugby ball.
The implication for Business Analysis and Product Management
Each investment can be different. One investment might be to increase the network (Marketing), another might be to increase usage or conversion (Product Management), yet another to introduce a new tax law because the government want a slice of our success (Analysis). Then we need to improve the UI our employees use to improve speed and reduce errors (Product Management). Then we need to find a new market to play in (The Crowd) and then the CEO wants to add some new graphs to the investor reports (Ginger Cake).
If you are an analyst or product owner working on simple requirements, you are adding no value. Even worse, you are adding delay. You are a worse than a waste.
If you are iterating through a complicated problem, you are incurring unnecessary transaction costs and taking longer than you should. Your duration will be much longer than it needs to be.
If you are analysing complex problems hoping to identify the ideal solution, you will take significantly longer to find the optimum solution and the reality is you will find a sub-optimal solution and stick with it until your competition eventually steals the world away from you. You are like a mad man fighting the wind with a sword. A modern day King Canute.
Finally if you are trying to create hypotheses, or analyse in a Chaotic environment, you are simply blind to the world around you. Like a starving man digging coal with a golden spade. You are disconnected from Reality, a modern day Silas Marner.
An investment (Project) may involve a number of these. A portfolio of investments (A product or an organisation) certainly will. Its no longer a case of this approach being the best or that approach being the best. It a case of understanding that each investment might need a fundamentally different approach or even a different set of approaches. If you only have a hammer, every problem in the world starts to look like a nail. If you don’t understand the different approaches, you may be bashing your head against a screw.
Anyone who tells you they have the perfect tool is deluding themselves as well as you. Build your toolkit of options, and always be on the lookout for new tools that reveal a context you do not understand.
*Note for American readers. Soccer is a word made up by the English to help us spot Colonial Spies.
September 5th, 2014 at 1:52 pm
I think its worth noting that Chaos has distinct characteristics depending on whether it was entered deliberately or not: http://cognitive-edge.com/blog/entry/6004/chaos-disorder
September 5th, 2014 at 3:58 pm
Great post, Chris – this really hits home.
The very first sentence highlights the fact that different groups often make different assumptions about which domain is being operated in (even if they aren’t thinking about “domains” as such).
The old argument from engineer to customer goes “that’s harder than you think”. Translation: it’s complex not complicated (or not simple). It seems to be common for customers to “underestimate” the domain.
Equally, I think engineers (or engineering organization) can be too quick to operate as if everything was complex when some things really are just complicated. As you say, this leads to waste.
Cool.
July 22nd, 2015 at 4:01 pm
[…] user experience, and hardly any on product management. Chris Matts took a more thoughtful approach using the Cynefin model as a guide (). He suggests that business analysis activities are helpful in complicated domains, whereas […]
December 29th, 2015 at 2:48 am
[…] user experience, and hardly any on product management. Chris Matts took a more thoughtful approach using the Cynefin model as a guide. He suggests that business analysis activities are helpful in complicated domains, whereas product […]
September 29th, 2016 at 7:25 pm
[…] user experience, and hardly any on product management. Chris Matts took a more thoughtful approach using the Cynefin model as a guide. He suggests that business analysis activities are helpful in complicated domains, whereas product […]
October 5th, 2016 at 5:51 pm
I think you overshot on the complex description. While I agree this is the area where a data scientist would excel, the methodology isn’t spot on.
Hypothesis testing and multivariate analysis would still belong to the complicated domain. The methodologies are still linear in nature and causation is the privileged result.
Complexity science, at least in the philosophical foundations of cognitive complexity and distributed ethnography, is concerned with dispositional states and modification of these states within boundaries and attractors.
The application for business analysis would be particularly in the gathering and communication of requirements among users and developers or implementation team members.
By collecting targeted user narrative, indexed against useful tools like dyads/triads/stones, would harness the distributed information held in informal networks within the organization. These priorities would cluster in the visualisations of the responses and these narratives can be read and interpreted by the developers, along with the indexed data, in order to exercise their judgment in order to define a series of parallel interventions in the form of code or other technical solutions.
Further collection of micronarrative throughout the intervention process will determine which are producing desired results, and then should be given more resources/time/etc., and those that do not are decreased or axed entirely.
The Data Scientist(s) would be able to contribute in the analysis of the metadata collected throughout the process (albeit this would still be in the complicated). A good data scientist would recognize the mathematical foundations of the visualizations and would be able to provide some additional (non-linear) analyses to calculate, for instance, value to the organization (etc.).
It’s important to understand that the Cynefin framework is a sensemaking model, rather than a categorical model. There are flows among all four of the domains – as IT professionals interested in furthering the use of the Cynefin framework within our respective spaces it is imperative that we resist the urge to ‘hard code’ the methodology.
Context, human judgment and perceptions – the core of the user experience – cannot be manufactured; we provide the service to maintain an optimal user experience in real time. It’s not a one-off, factory-driven output, it’s a complex, adaptive system – a program rather than a project.
October 5th, 2016 at 6:04 pm
Hi Ian
It sounds like you have used sense maker as a business analysis tool. Could you share your experience?
I’ve heard Dave talk about the theory but it would be great to hear from someone who has applied the technique. What worked? What did not work? What tips would you share, especially if you have done large scale capture using the tool.
Thank you
Chris
March 1st, 2018 at 3:10 pm
[…] “we don’t need that role on this project.” It’s actually a lot more nuanced than that. Chris Matts explains why you need to understand whether your work is complicated or complex (as defined by the Cynefin model) and what implications that has for business analysis and product […]
March 11th, 2018 at 5:14 pm
[…] Before you start, you need to identify whether you should be doing Business Analysis, Product Management or JFDI. Cynefin is a particularly useful tool to determine which approach. […]
March 29th, 2018 at 4:15 pm
[…] The set of practices you use is based a great deal on your context. Chris Matts suggested that you can use an understanding of the cynefin model to determine which of these sets of techniques you… […]
July 2nd, 2018 at 3:39 am
[…] Before you start, you need to identify whether you should be doing Business Analysis, Product Management or JFDI. Cynefin is a particularly useful tool to determine which approach. […]