For the last four months, I’ve been part of a tough project – tough on multiple dimensions, beset by every sort of calamity that one can dream up (every day was an example of Murphy’s law in action). That’s a nice way of saying – don’t give me grief on a lack of updates for that reason. Well, not really - blogging is therapeutic mostly.
But the point of this post is not to really go into the inanities of a project – it’s to place on the table the only free lunch in the world. So take from it what you will… Here’s what I learnt.
1. An unhappy client is not your fault, not the project’s fault.
Bang!! Front and center. Chances are that an unhappy client was unhappy long before you ever got there. In fact, unhappiness (both micro and macro) takes constant effort. It takes a whole lot of time and energy to be and remain unhappy. I’m not talking about the depressives or the manic-depressives but that class of people and organizations that are intent on getting there. An unhappy client is symptomatic of an unhappy culture or sub-culture of the firm and deeply unhappy ones are caught in a vortex – there is very little that one can do be it in through the project or as an individual to break the vortex. No measure of competency, delivery or solution can ever break the vortex – it has a life of its own. Like a demon. Such vortices don’t have technological solutions, project solutions or in some cases managerial solutions.
In nature, vortices dissipate because they encounter an environment capacitated to absorb the energy of the vortex. Vortices of sub-cultures ought to be dissipated by the larger culture of the firm. A vortex of culture within the firm cannot be dissipated inside the firm – these firms are dangerous to every thing around them and themselves. It is dissipated by the industry through the process of competition. And so on… Only competition, I believe, can break the vortex and this gets tricky at the team level but I see no other way to break the cycle. It’s something similar to what you might see on the Dog Whisperer where the energy of the pack is channeled into calming the dog that is freaking out.
2. Optimization is a mistake.
I love optimization. To me, it represents a curious blending of the platonic mathematical world and the real world – the world of the idea of the numeric colliding into the real where nothing of the sort exists. However, optimization (as is often sold to the business world) is first and foremost a terrible mistake. In a subset of these mistakes that businesses and firms make, it is the most important mistake that you need to make. Not in the sense that now that the firm has made it, walk away. No, once you’ve made the mistake of optimization, you’re ready to make the leap to the higher world of bigger mistakes. Such mistakes subside as you learn how to wield it properly.
However, most firms cannot deal with optimization. They (and by they I mean the people in the firm) are not able to deal with the intersection of the math and the real. They’re very content with their take on the real or other iterations on the real no matter how they’re being placed at a competitive disadvantage by those firms that not only invest in mastering optimization as a discipline but also as a way of approaching the business problem. Iterations on the real are reconceived processes, new technologies and the like. So most firms that take on the mistake of optimization treat it as a black box that keeps chugging away in the background telling them the “optimal” way to do things which passes through a gut-check filter and so it goes on… This is like buying a katana and using it for chopping vegetables.
Part of the issue with optimization is while there is an active movement to make supply chain a “C” level responsibility or at least have it on their radar – optimization (like statistics) is a nice to have. While the supply chain is an integrative activity of processes both inside and outside the firm, optimization is a quant backed way of executing the business (pun intended).
3. Plan – Do – Check – Act (PDCA)
While PDCA is quite important as far as continuous improvement goes and this simple concept underlies most of the continuous improvement methodologies out there, it has some relevance to the world of project delivery. For me, there has always been a question of which task do you start with: Is it Plan? Is it Check? or Does it even matter where you start? I now think that the right step to start with as far as project delivery / consulting projects go is to start with Check. The simple reason for that is that when you’re an external consultant, you’re essentially going by what you’re told. Often times, I find that there is a delta between what the client knows and what is actually present. The Check step is best visualized and not tabulated/reported. And its better to make it real-time in some way. Some people refer to this as analytics and that in my opinion is where any such project ought to start because it gives visibility of the changes that are going to happen or happening in execution. This has the added benefit of putting the client in the driver’s seat as you work on the engine while in motion.
