Subject: Owens' projected milestones
From: Tom Owens <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Date: Tue, 25 Jul 1995 10:43:36 EDT

Introduction:  Essentially my argument is that the nature of
defined development methods (I dislike the word "methodology")
lead inevitably to their eventual failure.  Failures can be 
immediate because the processes do not reflect enterprise environments
(Productivity Plus, I suspect) or because the plans are rigid and lack
staff commitment.  Inevitably, however, I believe, as time passes, 
even the best detailed methods tend to fall into disuse.  Staff 
move on and new staff lack commitment to the method; managers move on
and new managers lack commitment to the method.  The method develops
small problems which lead to larger problems which lead to distrust
and dismissal.  This leads to a cycle of increasingly independent
development, crisis, and a new method.

Believing this, I think the primary thing we should do is to
address these problems and create an evolutionary, self-healing,
autodidactic methodological environment.  If that environment exists,
the method(s) will eventually develop and sustain itself.

    -  Aug 12 - Deliver plan to gather information

Again, based on the goals I've outlined, we would primarily
investigate why methods fail in general and why they fail at MIT in
particular.  Secondarily, we would investigate existent methods at
MIT, strengths and weaknesses, and how those plans fit into our
requirements.  Lastly, we would investigate methods outside MIT and
how the various phases in our requirements have been implemented.

       Sep 15 - Deliver set of principles based on gathering

Our principles, in my scenario, would be those things which we believe
allow methods to succeed, those things which lead to failure, and how
to sustain the correct environment through an indefinite future.

       Oct  7 - Deliver document detailing proposed process

The process, as I envision it, would concentrate of the developmental
environment and offer differing versions of methods which meet the
phases listed in the Requirements Document.  These versions should
have a fairly good chance of being successful, however, I believe we
should concentrate not on the actual development methods which can
evolve properly later, but on the recursive, self-selecting nature 
of the environment.

       Oct 28 - Deliver modification to proposed process, based on
                review

Ditto

       Nov  4 - Implementation plan

The implementation plan should probably give clues about how to
determine success and failure of a method and suggest the kinds of
projects that should be selected for beta testing.

       Dec  2 - Conduct post-mortum and deliver results

The post-mortem should be focused on the environment rather than 
the success or failure of any specific method proposed and tested.

thanks,
--
Tom Owens
MIT Library Systems Office
[email-masked]
617-253-1618 voice 617-253-8894 fax