Date: Wed, 3 Mar 93 08:49:44 CST
From: brianm (Brian Miezejewski)
Message-Id: <9303031449.AA27756@ses.com>
To: turpin, marke, palmer, neuse, clarke, kss, kim, jay
Subject: AN interesting line in comp.software-eng
Status: R

In article <1993Feb23.043640@eklektix.com>, rcd@raven.eklektix.com (Dick
Dunn) writes:
|>reidyj@storm.CS.ORST.EDU (Jay Reidy) writes, _inter_alia_:
|>>When less that one percent of the large SW projects come in on time
|>>and on budget reflect the fact that teams aren't working well and the
|>>product is not being designed well, if at all...
|>
|>Maybe, maybe not.
|>
|>It could mean that the scheduling process doesn't work well, if at all.
|>
|>I'm serious.  There are too many games played in scheduling projects to
|>say that if a project doesn't meet its schedule there is something wrong
|>with the project team, etc.  I'll give two examples of schedule games; I'm
|>sure you can find others.
|>
|>1.  The Incredible Shrinking Schedule.  I'm watching a company near here
|>trying to commit corporate suicide by this schedule game.  The basic rule
|>of the game is that the schedule is shortened every time it goes up a notch
|>in management.
|>
|>You start by working out the tasks and having engineers make schedules.
|>Naturally, being engineers, they mostly give you fairly optimistic sched-
|>ules.  Some of them may use phrases like "assuming we have fribble by this
|>date" or "assuming all goes well with blarch" or "in the best case"...but
|>these conditions will always be dropped (only for the sake of brevity, of
|>course:-) as the individual schedules are compiled and moved up a level. 
|>Moreover, the same tendency--to paint the most optimistic picture possible--
|>applies at each level up the chain.  Call it drive; call it career aspira-
|>tions; call it brown-nosing.  Anyway, what started out as five people for
|>fifteen months becomes five people for a year, 4-5 people for a year, 4
|>people for a year...
|>
|>Now, the company I mentioned above has a large project, and has a LOT of
|>bureaucracy, hence a lot of management levels...so the schedule-shortening
|>process happened many times before it hit the top.  Not too long into the
|>project, they announced the product according to the schedule as it came to
|>upper management.
|>
|>It's now hideously over that schedule (more than a year, for a high-tech
|>product).  Project failure?  No, scheduling failure.  The product will
|>probably come out pretty close to when the actual bottom-level engineers'
|>schedules would have predicted.  The lesson of course, is that you should
|>always *increase* the time on a schedule as it moves up the tree.  Among
|>other things, you're dealing with additive uncertainties and you're trying
|>to keep a handle on overall worst case, but mostly you're trying to compen-
|>sate, rather than exacerbate, the tendency to be optimistic.
|>
|>
|>2.  End-Date Scheduling.  This happens to products more than anyone likes
|>to admit.  It works like this:  You figure out a product, then you figure
|>out the "market window" (the interval of time during which you can bring
|>the product out and make money).  If you're too late, there won't be enough
|>demand; you won't be able to sell enough of the product to recoup the
|>development cost and make money.  Now, the obvious way to deal with the
|>"market window" problem is to do the schedule (with all the probabilities
|>and risks), then see what the chances are of hitting the market window.
|>
|>But people easily dissuade themselves from doing the obvious:  If the
|>product looks plausible at all, they decide *first* to go for it, and
|>*then* create a schedule which, if met, will allow it to happen.  Thus,
|>"end date scheduling"--the scheduling process is driven by the end date.
|>Well, reality cannot be denied; if the schedule is impossible it won't be
|>met no matter how important it is.
|>
|>Knowing the end date *can* help with scheduling--if the first cut at a
|>schedule misses by a small margin, it becomes worthwhile to re-examine it,
|>see if adding people to do things in parallel, or omitting features not
|>clearly needed, will bring it in.  This process is necessary, but seductive
|>and dangerous...it is SO easy to force-fit a schedule to an end date by
|>making slightly unrealistic assumptions.
|>
|>I remember a meeting of the engineering group for a product some years ago,
|>in which the engineers were expressing severe doubts about being able to
|>meet the target release date for the product.  The CEO of the company stood
|>up on his hind legs and proclaimed "If I don't have this product out by
|><the desired delivery date> I'm going to have me a new engineering group."
|>Well...the threat, of course, was not really being delivered against the
|>engineers, but against reality itself.  The target date could not be met,
|>it was not met, and the engineering group eventually ceased to exist...as
|>did the company.  Project failure?  No.  Team failure?  No.  Scheduling
|>failure.
|>
|>
|>Anybody got other schedule games?  I know of some other mistakes; the two
|>above are just what I've taken time to characterize.
|>-- 
|>Dick Dunn    rcd@eklektix.com   -or-   raven!rcd    Boulder, Colorado USA
|>   ...Simpler is better.