Internetworkers: http://www.ibiblio.org/internetworkers/

[biglee at haslups.com (BigLee Haslup)]

This posting has two purposes, the first (and hopefully most interesting) 
is to contribute a few more scenarios to the software development 
nightmares thread. Here goes...
I had the dubious pleasure of being rather near the epicenter of a huge 
corporate re-engineering death march some years ago. It was at a large 
multi-national corporation that was divided into fiefdoms that lined up, 
roughly, along lines of market regions, business tool sets and 
technologies, and wildly different understandings of the common corporate 
data. There was a general understanding that this division of the company 
into "silos" was at best wildly inefficient and, more damaging, often 
pitted one part of the company against another. A decision was made to 
"re-engineer" the company, defining a new, common business process and, at 
the same time, develop a suite of new tools to support the new processes.
I was, at the time, the team leader and architect for a small team of 
Smalltalk coders working on a tool to do pre-order budgetary quotations. We 
had made the grave mistake of succeeding somewhat in excess of our mandate 
and, as the re-engineering effort got underway we found our tool selected 
to be the order-capture front end for the new order-processing tool suite. 
It is a great tribute to the talented team I had working for me, and to the 
flexibility of projects developed in Smalltalk, that we were largely able 
to keep up with the constantly changing requirements as the corporate 
process wars raged about us. In the end the quest for agreement on a single 
corporate business process failed and the project caved in; an expenditure 
of many tens of millions of dollars came up with nothing. All software that 
had been developed was scrapped since it was designed to facilitate a 
process that was nowhere adopted. A few aspects of the disaster 
particularly stick in my mind.
The 90 Day Wonder.
It first occurred to me that the people I was working with had gone mad 
when I heard a vice-president, while explaining the 90-day schedule, ask 
the rhetorical question: "Why can't a software development project be run 
in three shifts to get it done in one-third the time?" Everyone around the 
table nodded except me. That meeting launched a project that lasted, as I 
recall, somewhat more than a year but was, at all points, 90 days from 
completion by executive decree. As one set of executives lost credibility, 
another set would take over, but the 90 days to completion remained constant.
The Suicide Pact
Knowing that the 90 day schedule would be difficult to achieve a decision 
was made to pull most of the IT staff off of maintaining the existing 
systems so they could be deployed to help with the new systems. This meant 
that needed improvements were not made and new products were not added 
(because these issues would all be addressed by the new system.) The result 
was that as the unrealistic schedule slid there was no recourse but to 
panic, adding more resources and spending more money to get it finished as 
quickly as possible. By the time the plug was pulled the project had a cast 
of hundreds, many of the high-dollar outside consultants, and was burning 
money at an appalling rate.
The Butt-head du Jour
There was a series of overall project managers assigned to coordinate and 
facilitate the various process-reengineering and tool development efforts. 
Their primary task was to be confident at all times -- to *believe* that is 
was all possible and to rally the troops. They were swapped-out frequently, 
sometimes because of their allegiance to losers in the executive power 
struggles, but more often because they burned out like over-voltage light 
bulbs.
The Zone of Certainty
There were a few executives who seemed, for a while, to have pulled it all 
together. I remember one in particular who had a "Zone of Certainty" that 
extended about 400 yards in all directions from his person. While you were 
inside the zone everything seemed to make sense; you understood what you 
were doing, why is was needed and how to do it. It was probably an illusion 
created by his force of personality, and was ultimately unavailing in a 
geographically dispersed project (he couldn't be everywhere,) but I am 
still not sure that if we could have gotten the whole team inside the zone 
we might not have pulled it off.
The Tar Pit
There are certain serious problems that can never be addressed because they 
are complicated enough that any attempt to address them takes longer than 
the attention span of the executives. There are systems that were obsolete 
fifteen years ago that are still in use because each of the dozen attempts 
to replace them was abandoned because it was taking too long.
The Bad Attitude Group
Those who expressed doubts about the direction of the project were 
suspected of having a "bad attitude". One group so singled out took their 
affiliation with the group as a badge of pride. They periodically got 
together and held elections to designate a spokesman. His title was Head Of 
Software Engineering Bad Attitude Group (H.O.S.E.B.A.G.)
---------
My other reason to send this is to see if I am still a member of the group. 
I just tried to change my email address and to switch from digest mode to 
individual messages. The mailman web site now lets me log in using my new 
email address but has sent me notices that all of my changes were rejected 
because the confirmation code didn't match. Sigh.... why doesn't anything 
ever just work like it is supposed to?
BigLee Haslup