Part 6 - What Didn’t Make It Into The Book
(Part 6 in a series celebrating the 5th anniversary of my book The Complex Project Toolkit. You can catch up on the previous newsletters here)
When I wrote The Complex Project Toolkit, I set out to answer a single question: Why do capable people, using well-established methods, keep struggling with their hardest projects?
My answer was that the common methods were built for a different kind of problem. That standard project management tools were built for predictable problems, not complex ones.
The book therefore focused on capability. The mindsets, practices, and skills that help leaders and teams focus on learning, rather than relying on prediction.
Five years on, those ideas still hold. But reflecting on the core concepts for this newsletter series has brought forward three ideas that add more nuance to the model.
1. Increase Capability or Reduce Complexity?
The focus in the book was building capability to match the level of complexity you face.
However, while recently assessing a client's program, we realised that it would take a significant jump in capability to have any chance of success. So, the discussion turned to the complexity we could eliminate or at least reduce.
We realised that no amount of capability development would stop the organisation from flip-flopping on decisions when politically convenient. Scaling back the scope (or at least dividing it into bite sized chunks) was the best way to reduce the complexity, and the most practical way to reduce risk.
Rather than making capability cover the situation, we reshaped the situation to match the capability we could realistically build. The connectedness of complexity can make it difficult (or expensive) to unbundle into pieces, but the reduced risk profile improves your chance of delivery.
Takeaway: When designing your program, test if reducing complexity is a feasible way to bridge the complexity – capability gap.
2. More Than Wicked
In the book, I focused heavily on the social, 'wicked' dimensions of complexity - the emergent, shape-shifting dynamics that align with Snowden’s Complex and Chaotic domains.
But we can’t underestimate the Complicated. These are the projects that have a technical element that makes it difficult for mere mortals to fully grasp the significance of decisions.
Technicians can see a level of complexity that is often invisible to others (such as the implications of deviating from the IT architecture or the underlying reason for safety protocols).
Too often, technical experts complain about being excluded. When a project is deeply technical, specialists must be given a voice. But at the same time they have to lift their level of thinking to be able to provide high-level guidance that understands the business trade-offs.
Takeaway: When the topic is specialised, the technical can’t be ignored. But specialists must be challenged to elevate their perspective to see the whole system.
3. Use Experience Carefully
One dimension of complexity is uniqueness - this team trying to solve a problem they have never encountered in their specific organisation. Conversely, a team that has navigated similar terrain already knows where the hazards and surprises will come from.
Sourcing experience can be more valuable than trying to build capability from scratch. However, context is everything. Finding the right experience becomes the focus. Someone arriving with supreme confidence saying, "I’ve seen this before," can either be a valuable shortcut or a dangerous liability if they miss subtle contextual differences.
I have seen a number of times when someone with a good resume has not been able to adapt their ways to the specific situation. Successfully delivering one $100m project does not automatically mean you can deliver any $100m project.
Takeaway: Sourcing experienced talent can bypass steep learning curves, but ensure their expertise fits the context. A similar looking project isn't the same project.
Five Years On
The original premise of the book was that complexity is driven by the emergent and social nature of the situation, and purely analytical approaches can make things worse.
While that still holds true, and is the most misunderstood element of delivering projects well, taking a view across all types of projects requires a broader lens.
A project’s nature is shaped not only by how ill-defined or ambiguous it is, but also by:
The degree of technical specialisation required
The underlying motivations of key stakeholders
The team’s context-specific experience
All of these attributes combine in different ways to create the personality of your particular project.
Understanding this, and building your operating model to match it, is the way to success. I’m going to explore these themes in my next book… but more on that shortly.
Want to dive deeper into these ideas?
Download the first section of the book for free at www.kieranduck.com.
Grab a copy on Amazon or email me directly at kieran@kieranduck.com if you would like a signed copy.
