Conference 7.286::digital

        Re:< Note 243.0 by EXODUS::SEGER "this space intentionally left blank" >

                I don't  think so.  Hindsight is always 20/20.  Also, the
        real picture is far more complex than the analysis suggests.
        
        Anker

    There are some who think OFIS lives on.  The language, KOALA, certainly
    does.
    
    survivor,
    ed

	You call that living? More like "The Blob"!

That people could still, at this date, believe that OFIS did not fail shows
exactly how great the magnitude of OFIS's failure was.

I agree with Anker that there's little to be gained by dissecting this
particular set of corpses.

--PSW

We are getting into speicifics.
Back to the original question.    
    
    There is something in our culture that says new things are great
    -forget the old. I have seen numerous instances of learning by doing,
    and tripping up a bit, where the learning already exists, but in
    another group.
    
    Its a question of whether we want individuals to learn from their
    own mistakes, or those that someone else has already made !
    
    David Skyrme
    RES 1-5
    Reading.
    

    When a project fails for technical reasons, it is worthy to take
    a good look at why it failed.  It may tell something about underlying
    problems that will need to be addressed seperately.
    
    When a project fails because of a personality clash, lack of communi-
    cation, etc., you have to have a "feel" for exactly what happened. That
    involves getting into a lot of very personal details, which often turn
    out not to be terribly useful to different people in different
    situations.  (Interesting, yes, but only as gossip.) 
    
    Personal details are inappropriate material for exposure and extended
    prodding in a public conference.  All the people involved in a failed
    project have presumably since gotten on in their careers and it would
    be unfair to have their past mistakes spread before the DEC public and
    discussed ad infinitum in an open forum. 
    
    Finally, my experience with notes suggests that the medium does
    well in discussing technical issues technically, but people issues
    get discussed in a more general way.  It takes a special kind of
    experience to discuss people-issues disinterestedly and rationally
    which you won't get in a broad-based discussion.
    
    Therefore, I submit that a discussion of project failures should be
    limited to technical reasons that projects have failed by people with
    the technical skills to evaluate and compare these failures. Such a
    discussion drifts a bit from the people-oriented direction of this
    conference and so would best take place somewhere else. 
    
    Now where? 
    
    							Ralph 

    More common than "technical reasons" or "personality reasons" are
    what I would classify as "management reasons." Managing challenging
    projects is not easy. It is also not easy to get agreement during
    a post-mortem on the reasons for a failure. It would be harder still
    to get a well reasoned consensus through electronic conferencing,
    although you are welcome to try.
    
    One of the better books on project failure that I have ever read
    is The Mythical Man-month by Fred Brooks. It recounts the experiences
    of designing OS/360, written about a decade later by a principal.
    It takes a rare talent such as Brooks to make the story meaningful.

    Re: Personality reasons
    
    For over 3000 years the human species has had various problems "getting
    along" with one another. I agree that we will probably not solve
    the problem of personality conflicts here, but I still think we
    should gain some insight into what can be done to MINIMIZE personality
    conflicts effects on projects.
    
    There need not be names mentioned here. The names could be changed
    to protect the innocent. The idea I'm trying to point out is that
    if by some magical chance we discover a method of reducing the impact
    of personality conflicts on a project we will have more SUCCESSFUL
    projects. 
    
    A ridiculous example of the obvious would be: what if Einstein had
    had large personality conflicts with some of his peers? Would he have
    accomplished as much as he did? 
    
    At our site here (in my department) there are a minority of people
    who others consider hard to get along with or hard to get an agreement
    from. I have NO such problem, but then I've learned to ignore petty
    personal biases, and unless the "problem person" is a prime case
    of the Peter Principle, I feel a little EXTRA tolerance for others
    is ALWAYS in order.
    
    Nuff said.
    
    						Warren
    

    re: re: re: personality, project failure
    
    Perhaps because it is generally so difficult to understand human
    interaction, we tend to think that it is impossible.  President Kennedy
    set up a special commission after the Bay of Pigs fiasco to find out
    what happened.  The commission attributed the disaster to "groupthink",
    and recommended ways to deal with it.  When the Cuban Missle Crisis
    came along, the White House Staff was better prepared, and many
    of the personality and management mistakes of Bay of Pigs were avoided.
    
    There are also some management firms in Boston that specialize in
    diagnosing "corporate neuroses".  If these firms can do it (admittedly,
    they are called in when things get VERY bad), then perhaps we can
    also analyze some of the more obvious flaws in our thinking and
    interacting.  The news media have made a lot about how KO has been
    able to learn and adapt; cn't we do the same thing on a smaller
    scale?

    Re .7:  
    
    Actually, Peter, personality problems are generally management
    problems, since it is a manager's responsibility to make sure that such
    problems are neutralized to insure the success of the project, right?
    (Along the lines of "Authority should be delegated; responsibility
    can't".) 
    
    Re .8:  
    
    I'm still not sure we can tell much about the personality problems
    without identifying individuals.  However, not naming names will
    limit the audience who can identify them to those who were close
    enough to the project to know who was responsible for what.
    OK.  Just be very careful, everyone.

    Re .9:  KO learning and adapting; us learning and adapting "on a
            smaller scale".
    
    Actually, in the personal sense, this is learning and adapting on a
    larger scale.  Instead of one person (albeight one very influencial
    person with heavy responsibilities) learning and adapting from several
    peoples' mistakes, it involves a large number of people trying to learn
    and adapt based on a few peoples' mistakes. 
    
    It will take a management effort to keep that sort of discussion from
    being a "well, whose fault was it?" scene.  The only way such
    discussion could be effective is to create an "egoless" environment
    with no concept of "so-and-so should have done this" but only of "this
    could have been prevented by so-and-so doing this". 
    
    Enough of my 2� until there is actually something to discuss.
    
							Ralph

I agree with Peter.  Just about all of the failures I am familiar with
(all in software) have been failures of management.  Specifically, they
were breakdowns in the "process" of product management.  Figuring out
just who the customer was, what he wanted, what he NEEDED, and when it
needed to be finished.

Specific faults I have seen:

1)  Carrying out the strategy, regardless of its faults, in the face of
	conflicting information.
2)  Failure to enforce the phase review process.  THIS ONE IS DEADLY.
	When phase one is closed, it should stay closed.
3)  Attempting to get "buy in" from too many groups.
4)  Relying on raw market size numbers from which ever consulting group
	happens to have numbers matching your plans.  Some consultants
	have better reputations than others.  Watch out for business plans
	that quote studies from just one consultant.
5)  Trying to do too much at once, resulting in a group that is too big.
6)  Treating writers as though they are not part of the design team.
7)  Having too many writers.  This lets you think you can get away with
	a more complex design.
8)  [extension of #5]  The project requires synchronized contributions
	from more than one development group (cost center).  Goals often
	not compatible.
9)  [variation on #8]  Requiring synchronized contributions from groups
	widely separated by geography, or in different countries.  It just
	doesn't work.
10) Ignorance of state of the art from other companies.
11) Choosing to write a DEC version of something even though perfectly
	good (or better) programs are available from others.  (NIH)
	Especially stupid when those others are our own SCMPs.
12) Failing to design SWS opportunities into the product.
13) Thinking that a DEC customer buys ALL of his hardware and software
	from DEC.  The field and marketing know better, but engineering
	sometimes forgets.

I would like to recommend two good books that deal with managing projects. 
These books are both fairly recent and both deal directly with the problems
in managing software projects.


  SOFTWARE PROJECT MANAGEMENT
    written by Rosenau and Lewin
    published by Lifetime Learning Publications, 1984


  SOFTWARE ENGINEERING CONCEPTS
    written by Richard Fairley
    published by McGraw-Hill Book Company, 1985

    Other NOTESfiles that discuss this topic are:
    
    	SAHQ::PSS		SWS Professional Services
    
    	JAWS::PROJMGMT		Project Management
    
    There is a list of reference books in PSS.  Also, some 'sanitized'
    versions of 'problems' encountered in field projects, along with
    suggestions.
    
    	-Barry-