Managing complexity is tough. Especially if you can’t agree on where the complexity lies.
Sometimes decisions are easy.
You have the data you need. You know what you want to achieve. You know how things work – if we do this, then that will happen. So you connect the dots, make the decision, and all is well.
Make the same decision often enough, and you’ll define a standard, even a ‘best practice’.
Other decisions are a lot fuzzier. The data is ambiguous. It’s probably not complete.You may have conflicting goals.
It’s not at all clear how the system will behave – your actions often have unintended consequences.
For a decision like this, even if you’ve made it a hundred times before, you need to be constantly watching the results, adjusting course as the situation evolves. The Cynefin framework reckons that you’re now dealing with complexity.
Does that sound familiar to you?
Complexity kills a lot of projects.Firm milestones and budgets don’t sit well with complexity. There is no clear, single critical path. Specifications aren’t stable. Requirements change as you learn more about your customers, about the technology, about the wider environment.
Or rather, mismatched expectations about how to deal with complexity kills a lot of projects.If you think the situation is simple, then you see milestones and budgets as fixed.
Fail to hit them, and the project has failed. But if you think the situation is complex, then you see milestones as checkpoints: places to take stock, re-examine objectives, adjust course as necessary.
If you know your project is complex, you manage it very differently.
So it’s worrying that people have such different perceptions of complexity. I’ve been doing some research. Talking to people in project and product teams about what’s simple and what’s complex in their environment.
There are some pretty big divergences.For example:
Choosing a development process
Project managers see the software development process as simple.They’ve seen the process documentation and best practices.They’ve heard of the methodologies. They just want their developers to choose one and get down to work.
Developers, on the other hand, so the development process as complex. It needs to be tailored to the technology you’re using. It needs to fit the team.
Make a change to that team, or to the environment they’re working in, and the process will change, often in unforeseen ways.You don’t choose a process, you evolve it.
You need to constantly put time into it to get it right.
I think you can see the scope for misunderstanding here…
Developers often see prioritisation as simple.Ideally, someone will just rank order everything from highest to lowest.
At worst, you set up some weighting scheme to account for cost, value, timeliness, then let a spreadsheet decide. How complex can that be?
Product managers see the complexity.They know how fuzzy the projections of market size and value are, how they change under different assumptions.
They see the nonlinearities – change the delivery date, for example, and the value changes too.Above all, they’re involved in all the political infighting that goes on around prioritisation. Simple it ain’t.
For techies, this is easy. There may be a lot of factors to consider, a lot of trade-offs to make.You need time and data. But underneath it all, it’s simple.They know what they’re dealing with.
For project managers, technology is complex. Maybe they see the wider connections – choosing a technology means choosing a vendor to support that technology.
This may mean damaging relationships with other vendors. Politics intrudes again. Or maybe they’re just uncomfortable with technology.
(These examples are based on a fairly small sample – about 20 organisations. Your company may be different. But the trends are clear: I’ve never come across an organisation where there weren’t notable differences in people’s perceptions of where the complexity in their projects lay).
I said these different perceptions are worrying. That need not be true. They may actually be signs of strength.
Differing perceptions come from our different states of knowledge and skills. I may think something is complex because I don’t understand it; you see it as simple because it’s within your expertise.
Or alternatively, I may see it as complex because I know something you don’t – there’s a devil in the details that you’re not aware of.
If we can pool our knowledge, we’re better able to understand and manage the complexity.If we can pool our skills, we have more options available to us to deal with it. That’s what teams are about.
What really is worrying, however, is that most organisations aren’t aware that these different perceptions exist. That’s the source of a lot of miscommunication and mismatched expectations. And that’s what kills projects.
When you kick off a project, it’s worth spending some time talking about complexity. Find out just where everyone perceives it to be.
And where there are differences, find out why – that could just be the clue to success.