[465] in Project_DB
Re: A Proposal For Moving Forward on Project DB (3/31)
daemon@ATHENA.MIT.EDU (Robert V. Ferrara)
Fri Apr 9 17:09:11 1999
In-Reply-To: <4.1.19990409084917.00ccc300@po8.mit.edu>
Date: Fri, 9 Apr 1999 17:10:28 -0500
To: Mike Barker <mbarker@mit.edu>, Bill Cattey <wdc@mit.edu>
From: "Robert V. Ferrara" <rferrara@MIT.EDU>
Cc: Mike Barker <mbarker@mit.edu>, Tim McGovern <tjm@mit.edu>,
project-db@mit.edu
Hello to Mike in Japan,
Here's another vote for the kludge. If I understand it right, at each
transition (e.g., discovery -> delivery) the same project would acquire a
(slighltly) different name.
Cheers, Bob
At 8:49 AM -0400 4/9/99, Mike Barker wrote:
>[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
>:)
