[410] in Project_DB
Philosophical Ponderings of PDB Schema
daemon@ATHENA.MIT.EDU (Bill Cattey)
Tue Dec 29 18:38:23 1998
Date: Tue, 29 Dec 1998 18:38:19 -0500 (EST)
From: Bill Cattey <wdc@MIT.EDU>
To: project-db@MIT.EDU
I apologize in advance for the length of this note. I am trying to carry
the discussion forward from where Bob left it. The ideas here are
interrelated.
I wanna inventory where we agree, propose some changes, and examine the
areas where we're having trouble converging.
-- Principles we seem to agree on as of now --
It sounds like we're coming to consensus on some aspects of the Project
Database:
0. We should use the project-db list to review and discuss changes
before making them.
1. The focus of the project-db should be on making it easy to inform
others about the status. and resources of projects.
2. The present system would benefit from pruning away data elements that
are not used, and don't add a lot of value.
3. The user interface should change to make certain things easier.
-- Data Elements I propose we prune --
Tim, Bob and I all agree that the following can be pruned:
- Implementor/Owner
- Scheduled end date
- Quarterly Report Achievement
- Quarterly Report Goal
- Customers
As part of a larger effort, I propose that these be CHOPPED. Are there
objections to this?
-- A suggestion regarding Tasks --
I think I would like to keep tasks, and try and find the resources to
write an improved interface for creating and editing them.
-- Documents: Why we should go with ONE document only --
While I agree with Bob that people find it useful to have different
kinds of documents available through the Project Database, I believe the
better way is to have a SINGLE field which will be a URL pointing at the
Project Home page which serves as the project notebook.
There are three reasons why I like this: It gets us out of the ongoing
maintenance task of adding new kinds of documents. It allows a jumping
off point for a much more flexible approach to documenting projects. It
imposes a requirement for a SINGLE item to be entered by a project
manager.
I see one disadvantage: By pointing at a project home page, it takes us
out of the business of suggesting a possibly beneficial structure to how
projects are documented. Even this disadvantage, however plays well: I
don't think it is the place of the project database to impose that kind
of structure. I think an evolving sense of "the right thing to put in
the project notebook" is required. The project database is a crude and
inflexible instrument to help in that evolution.
-- Status/Process/Practice/Phase/Committment --
Here, I believe we need to do some soul searching.
The present set of data elements is poorly understood, inconsistently
used, and ends up not serving the intended needs. Here are some summary
ideas of where the different elements came from:
There seems to be a requirement to delineate projects that have a formal
IS committement behind them, but also a requirement to allow projects to
be put into the project database in the absense of such a formal
committment.
There seems to be a requirement that a particular practice and/or
process take ownership of a project for which there is a formal
committment.
There is definitely a requirement to know if a project is Planned,
Active, On Hold, Completed or Terminated.
There seems to be a further requirement to record what phase of work the
project is in (discovery, delivery, service/support). (We continue to
suffer from the fact that projects can be owned by Processes having the
same names as processes that are phases of a project life cycle.)
Our challenge is to come to consensus on what the real requirements are,
and how they can be implemented with real and easily comprehensible data
elements in the Project Database.
Here is a straw man proposal:
Eliminate Process, Practice, and Commitment as fields that are set.
Instead maintain a list of "Directors" which is a 3-tuple of strings:
Name, email, Affiliation
Example:
Bob Ferrara, rferrara, Delivery
Dennis Barron, dbarron, VDI
In order for a project to get an INTERNAL "formal committment" bit set,
a member from the list of directors must appear in the "Sponsor" data
element. Any director can put themselves into that slot. As soon as
that slot is filled, the project moves to be a FORMAL project. That
slot can be CLEARED. When it gets cleared, the project moves to being
an INFORMAL project.
This means that we would continue to think of projects as being
sponsored, or in some sense OWNED by a process, but we'd get into the
habit of saying that the project, for example is sponsored by Susan
Minai-Azary in Integration, or by Jim Bruce in the Office of the Vice
President.
Add a data element PHASE, which would have one of these values:
Discovery
Delivery
Service/Support
Not Applicable
This phase thing provides the useful information of what part of the
life-cycle the project is in.
Cut back the STATUS field to the set Tim recommended:
Planned, Active, On Hold, Completed or Terminated
The search page should be able to search by:
Sponsor -- you pick one from a supplied list.
default to ANY
Status -- you pick one from the supplied list.
default to Active
Project Name -- string as now.
Project Leader -- string as now.
----
Ok! Your turn! What do you think of what I propose?
-wdc
