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

["Colleen McCarthy" <cmccarthy1 AT nc.rr.com>]

Hi Lee,

Yes, Nothing Outrageous Missed, I remember...

I still have Michele Lynch's "Brave New World", final edition, "20 Ways to
Know Your Reengineering Project is Not Working".  I'm not where I can
physically put my hands on it, but I'll quote from memory: "The coding is
almost complete, but the design specs will not be available until next
year", "Every executive has a clear understanding of the vision...but none
of the understandings match"  "Charts describing the vision are seen clearly
by pilots flying at 30,000 feet", "All non-decisions are clearly made at
noon to midnight meetings that end right where they started", "The coding is
Smalltalk, the project is Alltalk".  I can remember raising the issue of  a
lack design specs for the work our group was doing, and being told not to
worry about it.  The exact qoute was "If you put smart people in a room,
they'll know what to do".

I do think that the organization learned from this, however, and it's why
there was so much funding for project management initiatives that forced
discipline into many functional areas.  It was a costly way to learn, but I
do think that the company did learn.

Colleen

Colleen McCarthy, MT(ASCP), BSEE, MBA, PMP
LIS Administrator
Laboratory Information Services
UNC Hospitals/McLendon Clinical Labs
1106 East Wing
Chapel Hill, NC 27514
email: camccart AT unch.unc.edu
phone: 919-966-2059 beeper 216-1995
fax: 919-966-6407
home phone 919-460-0641




-----Original Message-----
From: internetworkers-bounces AT lists.ibiblio.org
[mailto:internetworkers-bounces AT lists.ibiblio.org]On Behalf Of BigLee
Haslup
Sent: Friday, February 28, 2003 3:42 PM
To: internetworkers AT lists.ibiblio.org
Subject: [internetworkers] Re: Software Development Nightmares


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


---
Come and play at the InterNetWorkers Web site!
http://www.ibiblio.org/internetworkers/
You are currently subscribed to InterNetWorkers mailing list
To unsubscribe visit
http://lists.ibiblio.org/mailman/listinfo/internetworkers