Microsoft Solutions Framework Essentials: Building Successful Technology Solutions - a book on Microsoft Solutions Framework (MSF) by Michael S. V. Turner talks about the Standish Group 10th Annual (2003) CHAOS Report which mentions that only 34% of the projects in a sample size of 30,000 projects are successful. A staggering 51% are badly challenged --- the kind I like to call 'successful failures'.
To add to that 15% of them take a nose-dive to a down right catastrophic failure.
When I was doing a post on the fact that the success or failure of your project depends on the competence of your team and not other complicated factors like 'lack of a systematic process' one question that kept pinching me was why didn't project managers around the world just 'get it'. Why did they keep finding refuge in complicated terminology and jargons.
To find the real answer to the question; dear reader; you have to dive in the human mind and how it works. Besides the fact that complicated reasons give young and budding managers a curtain of crap to hide behind; I am also starting to believe that there is more to this phenomenon that just the prickdom of the young and budding managers or the desire of developers to save the skin of their other fellow developers.
Study how the human mind thinks or works and you'll find that there are two primary reasons why project failure analysis never produces any real concrete reasons for the project's failure.
The first one being; the fact that the human brain is often incapable of comprehending the implications small things can have on our lives and our projects. Malcolm Gladwell describes this phenomenon in his book - The Tipping Point - where he offers his readers a simple hypothetical puzzle:
| Consider, for example, the following puzzle. I give you a large piece of paper, and I ask you to fold it over once, and then take that folded paper and fold it over again, and then again, and again, until you have refolded the original paper 50 times. How tall do you think the final stack is going to be? In answer to that question, most people will fold the sheet in their mind's eye, and guess that the pile would be as thick as a phone book or, if they're really courageous, they'll say that it would be as tall as a refrigerator. But the real answer is that the height of the stack would approximate the distance to the sun. And if you folded it over one more time, the stack would be as high as the distance to the sun and back. This is an example of what in mathematics is called a geometric progression. |
Bring this to the world of software development; and we often tend to miss out of the ramifications of slightly in-competent programmers in our teams or organizations. Anyone who reads legendary author Steve McConnell knows that a competent programmer is ten times more effective than an incompetent one.
Having one ass-hole or a monkey is enough to screw up your next project.
So; that lowering of the selection criteria during your interview process obviously has a impact which is large enough to cause your projects to go for a catastrophic nose-dive while your brain struggles to comprehend how relaxing the selection criteria in an interview 'slightly' can cause projects to fail.
The other part of the answer; lies in the fact that that human beings by their very nature are pathetic risk assessors. Steven D. Levitt and Stephen J. Dubner describe this problem much more articulately in their book Freakonomics. The explain this phenomenon using two simple examples. In the first example they site the example of deaths caused by having guns in home; vs. deaths caused by having swimming pools:
| Consider the parents of an eight-year-old girl named, say, Molly. Her two best friends, Amy and Imani, each live nearby. Molly’s parents know that Amy’s parents keep a gun in their house, so they have forbidden Molly to play there. Instead, Molly spends a lot of time at Imani’s house, which has a swimming pool in the backyard. Molly’s parents feel good about having made such a smart choice to protect their daughter. But according to the data, their choice isn’t smart at all. In a given year, there is one drowning of a child for every 11,000 residential pools in the United States. (In a country with 6 million pools, this means that roughly 550 children under the age of ten drown each year.) Meanwhile, there is 1 child killed by a gun for every 1 million plus guns. (In a country with an estimated 200 million guns, this means that roughly 175 children under ten die each year from guns.) The likelihood of death by pool (1 in 11,000) versus death by gun (1 in 1 million-plus) isn't even close: Molly is roughly 100 times more likely to die in a swimming accident at Imani's house than in gunplay at Amy's. But most of us are, like Molly's parents, terrible risk assessors. Peter Sandman, a self-described "risk communications consultant” in Princeton, New Jersey, made this point in early 2004 after a single case of mad-cow disease in the United States prompted an anti-beef frenzy. "The basic reality," Sandman told the New York Times, "is that the risks that scare people and the risks that kill people are very different." |
Bring the idea over to your project and evaluate what is more likely to kill your project; having incompetent assholes; no customer feedback and a thousand other really small things or lack of a 'formal communication plan and scope control document'.
Most so called traditional project managers around the world will give you hours worth of free lecture on why a Process (with a capital 'P') is vital to your project.
Why they do this can be best explained with the whole idea of perception of control called the 'control factor'; described rather articulately by Steven D. Levitt and Stephen J. Dubner in Freaknomics. The book explains:
| But fear best thrives in the present tense. That is why experts rely on it; in a world that is increasingly impatient with long-term processes, fear is a potent short-term play. Imagine that you are a government official charged with procuring the funds to fight one of two proven killers: terrorist attacks and heart disease. Which cause do you think the members of Congress will open up the coffers for? The likelihood of any given person being killed in a terrorist attack are infinitesimally smaller than the likelihood that the same person will clog up his arteries with fatty food and die of heart disease. But a terrorist attack happens now; death by heart disease is some distant, quiet catastrophe. Terrorist acts lie beyond our control; french-fries do not. Just as important as the control factor is what Peter Sandman calls the dread factor. Death by terrorist attack (or mad-cow disease) is considered wholly dreadful; death by heart disease is, for some reason, not. |
Obviously; the young and budding manager is more concerned about the 'Process' than he is concerned about 'hiring'. 'Change of Process' and 'Control' mechanisms happen now. Besides; the standard issues that most BDUF processes try to address are just an inherent part of software development. The chaos can hardly be eliminated.
Trying to do formalized 'Change Control' mechanism instead of embracing change and focusing on quality people; is much like trying to control terrorists when the French-fries of simple and subtle incompetence might be destroying your project right now as you read this.
Understanding the human mind has huge implications on how we run and manage our projects. Understanding three things when analyzing project failures is hugely critical:
- Our brain has a hard time relating to how small things; like lack of customer feedback; slightly lowered selection standards etc. can have huge impacts on the project.
- We are terrible risk assessors; what seems to be the most probable cause of failure for project to us; most probably; isn't.
- The 'control factor' can make you do stupid things and lose focus on the much bigger problems at hand.
Now; you can go there and spend thousands of man-hours and dollars defining a 'Process' (with a capital 'P'), a formal 'scope control' document, a formal 'change management' document, and a formal 'risk assessment plan' followed by a million other documents which make you feel in 'control' or you can hire a team of seriously kick ass programmers; set them lose and spend your time listening to your customers.
The complicated reasons why you were told your last project failed; probably aren't true.
With this post; all I am trying to do; dear reader; is suggest that maybe; just maybe; your project failed because of completely different reasons which were not as 'sexy'; not as 'urgent' and not has 'seemingly big' as 'A Formal Process'.
Now; you can get back to watching the CNN report on terrorism on Television as you munch on super-sized packet of french-fries and then when you get a heart attack go blame the terrorists. As absurd as that sounds; and as unlikely it is that you will do that in your real life; that is precisely what most managers do when it comes to project management.
I leave you; dear reader; with a thought worth harping on.
Go take a journey into the depths to time and try to figure out why; any project that you may have been a part of or you may have witnessed failing; failed.
This time; for a change; try to be completely honest to yourself.
Maybe the real reasons for the project failure were not all that complicated after all.
Remember - behind every failed project are reasons which are simple and straight forward; sometimes so simple that our brain has a hard time comprehending them.
Comments are closed.