We’ve all executed projects — temporary endeavours aimed at delivering a unique outcome. Whether it’s moving to a new place, organising a large party, developing a new product, or delivering an artistic project, the principles of project management are universal.
And although project management is common, it’s often a source of frustration and stress. Things don’t always go as planned. We forget things, new constraints pop up unexpectedly, and deadlines can seem like moving targets.
While many systematic approaches have been developed to reduce this frustration and stress, the reality is that we still often face the same challenges. The myth that one approach works for every type of project – “just follow a class and get certified” – is what I aim to bust in this article.
Cost of change & uncertainty
Before we dive deeper, let’s first examine two essential concepts: cost of change and uncertainty.
1 – Cost of Change refers to the effort it takes when we want to make a change after (some) work has already been completed. If you send me feedback about this blog post, and I make changes, it takes me just a few minutes. The cost of change here is low, both in terms of time and money. Now imagine you’re building a house. Once the bricklayer has finished, asking to extend the kitchen is much more complicated, costly, and time-consuming. Similarly, if I’ve ordered an injection mould and discover, during pilot trials, that a dimension needs to be changed, the cost of change can be substantial — both in terms of lead time and money. These are examples of projects where the cost of change is high.
2 – Uncertainty refers to the unknown factors that could affect the outcome of the project. Let’s say you’re organising a street party for the 10th year in a row. You probably have a playbook for all the preparations, and you have experience handling good and bad weather. While disasters can always happen, uncertainty is relatively low in this scenario. Contrast this with the development of a hydrogen-powered car. There are uncertainties around technology, permitting, refuelling networks, user adoption, and costs. Given that such a project runs over several years, many of these parameters are subject to change, which increases the level of uncertainty. As described in ‘The Lean Startup’ by Eric Ries, uncertainty can be broken down into three categories: technology, customers, and business (financial viability). All 3 must be managed.
2×2 grid
By combining these two concepts, we can create a 2×2 grid, first demonstrated in ‘When Agile Gets Physical’ by Katherine Radeka & Kathy Iberle.
This simple 2×2 framework shows that there is no one-size-fits-all approach. For example, Prince2 is not optimised for the continuous deployment of software products. And Scrum may not be a good fit for managing physical products with high costs of change.
Navigating the Spectrum of Project Management
My own journey with project management began with a Prince2-like approach, which I learned while working at P&G, where we developed new products and production lines. At the time, I couldn’t imagine how Scrum would fit into those projects.
As I moved into IT environments and then back into physical product projects and production processes, I began to see a significant knowledge gap. Very few people were familiar with Agile Project Management outside of IT. While literature exists, it is often too theoretical or disconnected from real-world applications, making it a struggle for many to bridge the gap.
I used to believe that an organisation had to choose the ‘best fit’ for project management. I later realised that different teams within the same organisation might have different needs. For instance, one team might be tasked with introducing a CRM system, while another team is developing a new production line for a new product.
It’s only recently that I’ve come to understand the importance of navigating the spectrum of project management approaches.
Consider a manufacturing innovation, such as using a camera to inspect product quality. The cost of change is higher here than in software projects. A project team might start with Agile Project Management (e.g. leveraging concepts from Rapid Learning Cycles) to develop and validate the solution. However, once the solution is proven, scaling it across the network of factories in a multinational would likely be managed using traditional project management approaches, like Prince2.
But here’s the thing: it would be foolish to assume that the solution will remain ’the standard’ forever. Once implemented, the operators in a factory might come up with an idea to improve the software, such as adding colour-coded indicators to highlight certain deviations more clearly. Since this is a software change, this adjustment would likely be managed using Agile approaches, such as Scrum. And actually, the team might even move from project management to ongoing product development.
What this demonstrates is that we need to have a deep understanding of different project management & product development approaches and how they apply to varying contexts. There’s no single magic bullet, but rather a toolkit from which we can draw.
What’s more, teams need to define a common language for project management in their organisation. This makes it easier to understand which tools and approaches are most appropriate for each project, and helps avoid confusion when switching between different methodologies.
Conclusion: One Size Does Not Fit All
In conclusion, selecting the right project management approach is not about finding a one-size-fits-all solution. Rather, it’s about understanding the interplay between the cost of change and uncertainty. The key to success is the ability to navigate across a spectrum of approaches — knowing when to apply traditional methods like Prince2, and when to lean on Agile methods like Scrum.
In an increasingly complex world, project management itself should be flexible, adaptable, and tailored to the unique needs of the project at hand.
So, the next time you embark on a project, remember that project management is not a rigid system — it’s a spectrum that you should navigate based on the nature of your project, your team’s capabilities, and the level of uncertainty and change involved.
Related blogs
‘The shortest distance between you and your product’ by Katherine Radeka