Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!agate!bionet!llustig!objy!server!bobm
From: bobm@server.Berkeley.EDU (Bob Muller)
Newsgroups: comp.object
Subject: Re: Object-Oriented Project Management
Message-ID: <1991Jun20.205907.25131@objy.com>
Date: 20 Jun 91 20:59:07 GMT
References: <1991Jun18.124041.11482@grebyn.com> <18860001@col.hp.com>
Sender: bobm@server (Bob Muller)
Reply-To: bobm@objy.com
Organization: Objectivity, Inc.
Lines: 57

In article <18860001@col.hp.com>, denisl@col.hp.com (Denis Lambert) writes:
|> Ron,
|> 
|> Although I have done only a small amount of OOP, we do use quite a bit
|> of iterative prototyping here, which may or may not be similar.  I can
|> comment on how the current offering of project management tools really
|> does fit into this environment.  I have not found it necessary to warp 
|> the project to fit the tool, or warp the tool to fit the project.  The 
|> problem with iteration lies in its perceived definition of: keep doing
|> something until you get it right.  If this is your definition, then
|> no project management tool or methodology will work.  I prefer to look
|> at "Objective or Goal Driven" iteration sets.  By this I mean that each
|> set of iterations should have a clear and well defined goal, such as to
|> understand the menuing interface system or in the OO sense to design an
|> implement class strings.  The trick is to decompose the project into a
|> series of well defined, goal driven iteration sets and to use the project
|> management tool for what it was designed for, as an overview tool to see
|> and control an entire project.

Take this a bit further and you are doing the same thing you are doing when
you design software.  Make the goals things--a prototype with certain features,
a design document, a design review, a test suite.  Then, when you model the
project, you are doing real object-oriented project management with much the
same design methods you would use to do object-oriented software design.

Ron proposes that we need tools geared toward iteration.  I feel this makes
too many assumptions.  A general project management system should model the
things you manage, and you should be able to adapt it to your process.

Most current tools, for example, have only limited abilities to model the
resources in a software project.  You have to fake out the tool by assigning
resources at some fake percentage of time, or worse, having to develop 2
separate resources that represent the same person in order to kludge the fact
they are working on two things at once.  This is a more basic problem than
not supporting a particular process model.

To model the kind of parallel, iterative tasks Denis lists, you would have to
show no dependencies between them, and you would have no way of showing that
having a first draft of the design document is necessary to the guy down the
hall doing the prototype of a certain feature defined in that document.  What's
important is not the iteration but the dependencies and managing the flow of
things through SOME process.

I would like to see a project management system that lets me model my process
first, then apply it to the production of things, which is what I really do
when I control a project.  I don't care that much about how tasks actually
get done, only about dependencies between things and how long it takes (and how
much it costs) to produce those things.  If I iterate to get there, fine; if not,
that's fine too--but the project management tool better let me figure out whether
I'm making progress toward getting the things I need to finish the project.

Now THAT's object-oriented :).

-- 
    -- Bob Muller
       Objectivity, Inc.
       bobm@objy.com