[74] in Project_DB
Interesting feedback from Delivery Team Meeting
daemon@ATHENA.MIT.EDU (Bill Cattey)
Fri Mar 28 15:37:59 1997
Date: Fri, 28 Mar 1997 15:37:55 -0500 (EST)
From: Bill Cattey <wdc@MIT.EDU>
To: project-db@MIT.EDU
The minutes I sent out for the Delivery Team meeting of 28 March
contained some discussion about the Project Database that I would like
to share on this list:
Excerpts from mail: 28-Mar-97 Minutes: 28 March 1997 Deli.. Bill
Cattey@MIT.EDU (7012)
Project Database Update:
The Projects Database Implementation Implementation team met
yesterday and even caught Jeff to understand what he meant. Various
changes have been contemplated.
Wade asked what the resource requirements were expected for the
system. Bill Cattey answered that the team felt that one day a month
for a person or two was probably appropriate, and that the effort
estimate to make the contemplated changes was three days or so of work.
The Implementation team will meet again on Monday to further discuss
what to do.
Issues raised around the table:
Q: What is the cost of making no change?
A: Possibly harming the ability of the system to track projects because
there's an obstacle in the way of getting them in.
Q: What about making a director-restricted capability to turn a project
into a formal project from an informal project?
A: The team has considered that as one change to make.
Q: When will projects be deleted from the database?
A: Probably never. It was planned that it be an archive.
Q: Won't that make it hard to find projects?
A: Bill said he thought that in the 6 month timeframe, additional pages
that separate out formal, informal, completed, in-progress, and maybe
pending projects. But that's for when we have 1000 project we're
tracking. Adding new web displays is not hard.
Note also: As we've worked with the implementation, we've discovered
that the implementation of the initial requirements needed
simplification, and we did SOME of that, but worked at getting the
system out as QUICKLY as possible. There ARE holes -- if you know the
names of pl/sql procedures, you could probably do things you're not
supposed to. Making the contemplated changes may open up new holes,
even as we close such holes as make sense to close while we make the
changes. At some point we should schedule the work to do a cleanup so
that the system more robustly implements the requirements as we now know
them.
Bob (and others agreed) that it's better to just say what polite
behavior is, and let people know than to work super-hard to enforce it.
