[380] in Project_DB
Re: The project DB needs "Milestones" not "Tasks".
daemon@ATHENA.MIT.EDU (Tim McGovern)
Tue Dec 1 13:08:32 1998
In-Reply-To: <oqN1tz0GgE6e1eB3c0@mit.edu>
Date: Tue, 1 Dec 1998 13:10:35 -0500
To: Bill Cattey <wdc@MIT.EDU>
From: Tim McGovern <tjm@MIT.EDU>
Cc: project-db@MIT.EDU, Greg Anderson <ganderso@MIT.EDU>
At 11:51 AM -0500 12/1/1998, Bill Cattey wrote:
>Tim:
>
>I think I agree with where you're heading with my suggestion.
>Say more about what things, specifically, you think should be hidden.
>
>-wdc
Before I answer, I need to say that I think the landscape has changed some
since we loaded up the project-db schema with a lot of data elements.
First, we have proven that most of the fields don't get much attention for
most project leaders, and projects. But more importantly, the idea of
project notebooks has begun to catch on. Because of this latter fact, much
if not all of what I'd do to simplify the project-db is accompanied with an
expectation that conscientious project managers will still be keeping track
of lots of stuff in their notebooks as their project management "styles"
and project needs dictate. With that said,for starters, I'd cut out:
- Implementor/Owner
- Scheduled end date
- Priority
- Commitment
- Quarterly Report Achievement/Goal
- Customers
- Team Leaders
- Comments
- Tasks
My "ideal" maintenance form would have the following look (with a few minor
field use / labeling changes):
- Project Name
- Headline
- Contact (99% this is a single name and the project leader,
occ. it might be a mailing list)
- Sponsor (100% this is a single name)
- Start date
- End date (blank if not completed/terminated)
- Process
- Practice
- Status (Allow one of these five values:
Planned, Active, On Hold, Completed or Terminated)
- Description
- Documentation (Eliminate all but one document type, the project notebook,
and have this field contain a URL pointing to it)
- Issues (Eliminate all subfields exc. the description and the
status indicator)
I really struggled with whether to keep Issues in or out of my ideal form.
In the end, I kept them in because ITLT users of the project-db benefit
from being able to see the kind of stumbling blocks a particular effort is
facing, assuming we can get the data entry done. These probably need to
appear, be more fully annotated, and be tracked in the project notebook.
Tim
