The Paradigm Trap
A “paradigm trap” is a situation in which people, teams or organisations can’t think outside a particular paradigm that they have been using. This “trap” therefore actively prevents them finding alternative solutions to their problems. It could also be called the “Paradigm Black Hole” in reference to how light is “trapped” by the gravitational force of the star at its centre.
In the world of Project Management, the “paradigm” is the particular methodology that is used to orchestrate planning and execution, e.g. plan-based methodologies based on PMBOK, or a derived internal equivalent. Or the paradigm could be an Agile approach to software development, for example: Scrum.
This situation is well understood across many domains of experience and professional practise: it is also known as the “law of the instrument” or “déformation professionnelle”.
This situation is classically illustrated by Maslow’s quote:“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail” – Abraham H. Maslow (1962), Toward a Psychology of Being
If you are building a house, you won’t succeed by following the directions in the user manuals for your power drill, angle grinder and electric plane. You need to follow a higher-order house design and a set of guidelines in how to approach building the house. The house design is informed by human requirements for a particular environment and lifestyle, and the house-building strategy is informed by experience.
I used to be in the “paradigm trap”: There was a time when I spent a lot of time, both work and personal, in developing my understanding and expertise in project management tools and techniques. When I managed teams of Project Managers, I spent a lot of time trying to standardise their approach to tool and process use. My PMO and I invested time in developing and extending systems and processes to manage the overall team’s work.
But not much changed. I ended up with the view that I could spend an infinite amount of time on the paraphernalia of project management and still have the same types of problems.
So in my view, the solution to project delivery problems is not more methodologies, training or processes; it’s not more emphasis on execution effectiveness.
In discussing this with staff and colleagues it became obvious that many people do not think this way. It seems that it is very difficult for people who are invested in a particular methodology to think in other ways: they’ve fallen into a situation called a “paradigm trap” which actively prevents them finding alternative solutions to their problems.
How do we avoid the Paradigm Trap?
In the project management world, we need a way to more reliably ensure that we are always aligning our activities to our project goals. Something that we can rely on to help us discriminate between useful work and that which is not useful. This guidance needs to stand outside the methodological paradigm so that the methodology is itself subject to this guidance.
I know from experience that if the guidance is inside the methodology, when things get tough we look to the methodology to help us. But if the problems are related to the methodology then there’s nothing that can help us.
I’ve come to the view that in any endeavour, we need guidance at a level that is outside our day-to-day activities. A higher-level guidance that doesn’t get trapped in the problems, tensions, and difficulties of our day-to-day lives. It doesn’t need to be anything mystical or faith-based (although obviously it can be).
We need to be sure that we don’t “throw the baby out with the bathwater”. We don’t need to throw away my knowledge of tools and process that can be used when appropriate. We need to ensure that we select the right tools and processes to solve the problems that we are actually finding.
The Solution: Principle-based Project Leadership
We need to be better at delivering the benefit outcomes required by the project’s customers and/or sponsor rather than be better at operating the logistical minutiae of Project Methodologies.
This approach is common in many fields of life: it was certainly what drove George Patton in his pursuit of excellence on the battlefield:“to be a successful soldier you must know history. Read it objectively …. What you must know is how man reacts. Weapons change but man who uses them changes not at all. To win battles you do not beat weapons… you beat the … man…. You must read biography and especially autobiography. If you do, you will find that ware is simple“ – General George C Patton in a letter to his son in 1944
Patton is saying that in the practise of warfare weapons and tactics can come and go, but the fundamental principle is that the campaigns are conceived and executed by human beings.
In order to improve we need to be guided by a set of higher-order guiding principles that give us direction and prioritisation what you do, and helps us select the “weapons” we employ.
Principle-based project leadership means deliberately setting up a small but very clear set of fundamental principles that will help guide your activities across the whole project delivery process from end-to-end. These principles are generic in that they can be used unchanged from project to project, but they are crafted very specifically to the practice of project management.
The principles you use should be immediately actionable: they should drive valid project management actions that will inform, enable or support your project’s end goals.
The efficiency benefit from these principles happens when we can reliably perform actions “in the moment” that deliver goal-service outcomes without a layer of methodological overhead.
Perhaps not every action, but our KPI is to drive the ratio of direct vs managed actions further towards the “direct” side of the scale, without compromising our risk profile.
If we are conceiving, designing and delivering projects in an environment of complexity and rapid change, we cannot afford unnecessary overheads: speed and flexibility are the key. But we need to be mindful that some activities do require a level of process, technique or a tool in order to manage risk.
Guidance on when we should be employing these tools is necessary, and this guidance should come from outside any methodological toolset.
I have created a set of 5 “Project Action Principles” which fit my needs for this high-order guidance for project success.
Check them out, as well as the other resources available, using the links below.
Five Project Action Principles
The Five Project Action Principles are expanded upon in the below articles
- 5 Project Action Principles
- PAP #1: Achieve Outcomes, Rapidly
- PAP #2 : Fulfill Customer Value, Interactively
- PAP #3 : Build Shared Models, Verifiably
- PAP #4 : Eliminate Teaming Threats, Ruthlessly
- PAP #5: Suppress Project Entropy, Selectively
- Project Action Strategies Index Page
- Project Action Models Index Page
- Project Action Techniques Index Page