Mushrooming Clouds!

Mushroom cloud from a hydrogen bomb test

All hierarchical and process-bound organisations are guilty of "mushroom management" at some point or another. Mushroom management is a satirical metaphor for a situation when access to information and decisions are restricted to employees and furthermore when the information is conveyed, it is inaccurate, incomplete and full of hyperbole. It is like being kept in the dark and having the dirty stuff thrown at you. Even if you are mildly ambitious this style of leadership will curtail your creativity and hold you back.

Business today is about change and adapting to it. Nowhere else is this more evident than in the software industry. Free flowing and ubiquitous communication are the corner stones to innovation, good customer service, high retention and change. You would think that with the Internet, email and mobile phones communications would have improved by leaps and bounds. But it turns out this is not really true. If you ask most people what they would like their supervisors or managers to do to make the work environment better, you will hear "communicate better" most of the times. In my opinion this is the case because, email and mobile phones have substantially increased the quantity of communication but they have had a damning effect on the quality. The tools are improving but the content is deteriorating creating a rude deception!

Keeping a tight rein on information has never proved to be a good management strategy. The most famous example of this was the Teamster's strike at UPS in 1997. It is estimated that UPS lost nearly $700 million in revenue apart from the loss of credibility with its customers and employees. Many commentators argue that as part of its negotiations the management held a lot of information close to it's chest. It turned out that this flawed strategy caused many loyal employees to feel betrayed because they simply did not know what was going on. As a consequence they simply decided to leave. The lack of information caused a backlash with anger, resentment and  loss of revenue. 

Functional groups in organizations need to be "high-access" with communication at the center. Good communication will invariably lead to high retention. On the other hand "low-access" groups are characterized by constricted communication flows where people find themselves kept in the dark like mushrooms, stuffed in silos of job descriptions, rankings and the organizational chart. It is but natural that these groups have trouble responding to change and wavering customer needs which is a reality of the modern software producing work environment. The mantra has to be "when in doubt, over communicate!".    

All in all mushroom management in the software product development world is an anti-pattern that will only end up producing mushroom clouds. 

  

  

The Dangerous Chicken

Angry Birds

Chicken is a fairly well modelled conflict pattern in game theory circles. It is a simple game really where each player tries not to yield to the others. The worst possible outcome of the game though occurs when none of the players yields. You would have seen this situation depicted in many movies. Two gang brats with their snappy cars set out to prove something to their cronies or settle a dispute. They get into their cars and a skimpily clad hottie flags them off at warp speed towards each other. The brat who blinks first and veers off the path is the "chicken" while the other one gets the bragging rights and probably the flag bearing hottie as a bonus. If neither of the hooligans swerves of the path, the result is a crash which will probably be deadly producing the worst outcome of the game.

In the software industry especially in project management the game of chicken manifests itself in scheduling and is often referred to as "Schedule Chicken". The condition occurs when teams start committing to unrealistic schedules assuming that other dependent teams are crunching their schedules even more.

Project delivery dates, especially so for new product development, are ridiculously difficult to estimate primarily because:

• Uncertainty is inherent and inevitable in software development processes and products - Ziv’s Uncertainty Principle 
• For a new software system the requirements will not be completely known until after the users have used it - Humphrey’s Requirements Uncertainty Principle 
• It is not possible to  completely specify an interactive system – Wegner’s Lemma
• Ambiguous and changing requirements, combined with evolving tools and technologies make implementation strategies unpredictable.

It might seem like I am stating the obvious but these tenants do not seem to be very well accepted. "The management" is always looking for a "date" for obvious reasons, irrespective of the uncertainty and the ambiguity. They are in most cases pulling in an untenable date that can be sold to the bosses which in turn is sold to their bosses and so on. To arrive at a date there is bound to be a lot of analysis with:

1. Requirements being gathered and formally written 
2. Big designs being made upfront
3. Project estimation being made and
4. Complex interrelated plans being drawn up. 

With all the requirements being far from clear since customers themselves only have a vague idea of the final product, the analysis phase in most cases will turn into an "analysis paralysis". There is absolutely no tangible functional value created with the steps mentioned above. There may be some organizational value but that can almost be equated to bureaucracy! It is not surprising then that analysis paralysis is commonly referred to as an anti-pattern. All the analysis though takes a lot of time and since it is not producing tangible results is, in effect, creating a "value" debt for the project which will always be looming large.

Even if you were to be brutally honest with every dependency analyzed (which is pragmatically impossible), the date you come up with is never going to be accepted because somebody up the hill won't be able to fit it into his presentation. The inevitable advice will be to slash the estimations which will end up making the already shaky estimates absolutely and firmly unattainable. That the dates don't work is now a open secret in every sense of the word. That said, we live in a dysfunctional corporate culture where you are discouraged from being forthright with the messenger always being the first guy to be shot. The value debt and the culture together setup this cult-like delusion where the dates are committed to in unanimity.

Now the question is how long is this charade going to last? Most likely till the the first significant milestone in the project. The next obvious question is who is the guy who is going to blink; who is the chicken? Most likely it is going to be a "not so experienced" project manager or a service vendor. The chicken in most cases is crucified and accused of every incompetence conceivable under the sun. Once the chicken has been labeled an outlier, shot and killed; everyone else readjusts the dates and the game starts over to find the next chicken.

The real problem with Schedule Chicken is that it delays the inevitable, hurting the project schedule and driving up the cost. It prevents the stakeholders from looking at the root cause of the problems and taking corrective action early on.

The bottom line is that the game of chicken will not only disembowel the chicken but will also nuke the project. Schedule Chicken is a dangerous game to play!