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!