[464] in Project_DB
Re: A Proposal For Moving Forward on Project DB (3/31)
daemon@ATHENA.MIT.EDU (Mike Barker)
Fri Apr 9 08:53:29 1999
Date: Fri, 09 Apr 1999 08:49:38 -0400
To: Bill Cattey <wdc@MIT.EDU>
From: Mike Barker <mbarker@MIT.EDU>
Cc: Mike Barker <mbarker@MIT.EDU>, Tim McGovern <tjm@MIT.EDU>,
project-db@MIT.EDU
[the copy of this I got seemed to be mangled, so here's another try]
First cut -- what's the purpose of the database entry?
Basically, I think it's to provide an entry for the directors to keep track
of the projects. So the real question is whether they see projects
"sliding" across the processes or not.
From a historical perspective, I suspect that when there are major changes
in a project (e.g., the project leader, project team members, etc. may
change when it slides across processes) we probably should track that.
Right now, I think that means we put it in as a "new" project, probably
maintaining a link through the name.
Do names have to be unique? If not, we could handle this easily, just
putting in a "new" project with the same name and different process.
One slightly radical approach would be to admit that the project database is
basically ONLY the current projects, nothing historical. So we don't really
need to keep historical info in it -- although we may want to remind people
that they should keep it in the project notebook?
I think Bill's got it right -- for now, we're going to have to kludge with
the existing kinds of projects. For the longer term re-work, we should
think about how to handle the lifecycle of a project...
thanks
mike
At 06:45 PM 4/5/99 -0400, Bill Cattey wrote:
:)Tim:
:)
:)I was going to forward a suggestion to Mike about how to answer your
:)request, but he's gone for two weeks. Ultimately, he's the project
:)leader, and may be able to give a better answer than this, but I wanted
:)to provide to you something.
:)
:)First off, thanks for the idea.
:)
:)I can see how there might very well be two projects, that are, from the
:)standpoint of meeting a business need, the same project, but from the
:)standpoint of Process, are very different projects indeed.
:)
:)For example, Electronic Reserves: If it were to become a Delivery
:)project, it would have very different work and people than the current
:)Discovery project. It's the same project from one viewpoint, and 2
:)different projects from another viewpoint.
:)
:)Chatting informally with Miki about this, we concluded that the change
:)to the schema to allow one project "NAME" to refer to two whole projects
:)in the database with different "PROCESS" fields as the differentiator
:)would be a non-trivial amount of effort.
:)
:)Miki suggests the admittedly kludgy approach of assigning long names to
:)projects, for example Electronic Reserves Discovery and Electronic
:)Reserves Delivery.
:)
:)When Mike comes back he will give you the official answer, but I think
:)the answer to your question is, "Yes it would be useful functionality,
:)but the cost of implementing it is beyond the scope planned for the
:)effort this time around. So we should remember to put into the hopper
:)with the stuff considered for the larger scope follow-on Discovery
:)project."
:)
:)-wdc
:)
