Role of Integrative Thinking in Project Management
I just finished reading the brilliant “The Opposable Mind” by Roger Martin. He introduces the notion that we all possess the so-called “opposable mind” which has this amazing capability to simultaneously hold two contradictory views about a problem.
The conventional wisdom is to try to find a via media but that is perhaps meekly surrendering to complexity by taking a short-cut to a suboptimal solution. He argues that the some of the most exceptional leaders do not succumb to the obvious “either/or” thinking but rather work patiently towards synthesizing the best from both of these opposing views to create a best-of-breed solution that is far superior to either of these. He calls it “integrative thinking”.
Martin writes, and I quote:
“…the leaders I have studies share at least one trait, aside from their talent for innovation and long-term business strategy. They have the predisposition and the capacity to hold two diametrically opposing ideas in their heads. And then, without panicking or simply settling for one alternative or the other, they’re able to produce a synthesis that is superior to either opposing idea. Integrative thinking is my term for this process – or more precisely this discipline of consideration and synthesis – that is the hallmark of exceptional business and the people who run them.…Human beings, it’s well known, are distinguishes from nearly every other creature by a physical feature known as the opposable thumb. Thanks to the tension we can create by opposing the thumb and fingers, we can do marvelous things that no other creature can do – write, thread a needle, carve a diamond, paint a picture, guide a catheter up through an artery to unblock it. All those actions would be impossible without the crucial tension between the thumb and fingers.…Similarly, we were born with an opposable mind that we can use to hold two conflicting ideas in constructive tension.”
The book is a treasure trove of how go develop integrative thinking, but I was struck by how much it is relevant to each one of us at all levels, not just for the leaders at the top. The field of project management is all about making sensible but often hard trade-offs. Effective management of Project Management Triangle is literally the holy grail of project management – one that not only is the nemesis of every project manager but is also, in fact, the genesis of modern project management. In layman terms, what we mean is that out of Scope, Cost and Time, you may pick up any two, but can never meet all the three of them at the same time. So, if the requirement is to build replica of Eiffel Tower in just three months and ten thousand dollars, then yes, it can be built but it might look more like a school project. If it is a fixed-scope project like migrating all tax payers to a new software by close of the current financial year, then one might need to look at costs involved without which either one of the scope of the time might not be possible to meet.
However, what ends up happening in reality in many situations is that a project still ends up taking the amount of money that is takes, and yet the scope delivered is too little, too late!
If one were to look at modern project management (though most of us in software industry would probably call it as ‘traditional project management’), I think we just don’t have any similar notion of integrative thinking. The only treatment I have seen is perhaps in the Theory of Constraints where the approach is more holistic.
In software development, the conventional project management is modeled around industrial model of a production process – the so-called waterfall. In a linear, sequential flow done by silos that specialize in a single functional area, there is natural tendency and inclination to optimize the area of responsibility. For example, a design team might be most concerned with how elegant their design is, whether is meets the future issues of maintainability or portability or not. Similarly, the high wall between developers and testers is industry-famous – which is a major reason why developers don’t trust testers (“they will come up with only Sev 3 bugs and kill us with volumes towards the release, and expect us to fix them all before GA”) and in turn, testers don’t trust developers (“they can’t write clean code”, “if only they did better code reviews and unit testing and found all code-level defects, we could do such a better job of finding all Sev 1 bugs and focus on performance and reliability aspects”). Clearly, such a process breeds a mutual trust deficit, and the narrowly focused project roles simply perpetuate it further. What happens is the tragic story of optimization of parts at the cost of sub-optimizing the whole – completely anti-lean approach!
Agile software development (the concept, not a particular methodology) helps by offering to eliminate such artificial boundaries that force “either/or” thinking. Instead of taking a monolithic approach of meeting 100% of the project triangle, it offers to simultaneously meet part of the scope at part of the cost in fraction of time that what would normally be needed in a waterfall model. However being recently introduced to this concept of integrative thiking, I am still thinking if agile philosophy fully addresses it, and on the surface, it doesn’t look like. However, I have been proven wrong in the past, so we will see…