[86] in Project_DB
Re: Directors: Is this change to Project DB OK?
daemon@ATHENA.MIT.EDU (Jeffrey I. Schiller)
Tue Apr 1 10:44:00 1997
Date: Tue, 1 Apr 1997 10:42:44 -0500
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: wdc@MIT.EDU
Cc: ITLT@MIT.EDU, project-db@MIT.EDU, nschmidt@MIT.EDU
In-Reply-To: <cnE4LScGgE47F44QwO@mit.edu> (message from Bill Cattey on Mon, 31
Mar 1997 18:16:46 -0500 (EST))
Date: Mon, 31 Mar 1997 18:16:46 -0500 (EST)
From: Bill Cattey <wdc@MIT.EDU>
Cc: ITLT@MIT.EDU, project-db@MIT.EDU, nschmidt@MIT.EDU
References: <199703312312.SAA00643@road-warrior-177.mit.edu>
...
I think we are not a "Command and Control" environment, but that we
still have some hierarchy, and some amount of collective oomph that is
directed towards some things and away from others.
Speaking as a team leader, I find it disappointing that I cannot
"Officially" start a project without approval from a Director. I
didn't think that was what our new organizational structure was
about. Keep in mind, not being able to mark it as "Official" in the
database won't really prevent me from starting important projects. It
will just force me to bother a director (which one?) to have the bit
set. It isn't worth it to me to go through the hassle just to get the
bit set.
What this means is that the database will not accurately reflect what
we are really doing. Keep in mind that things happen whether or not
they are recorded in the database. To me, easy update of the database
will make it likelier that it will contain accurate
information. Inhibiting people's ability to make updates will not
improve the organization, it will only reduce the usefulness of the
database itself.
Consider: I (or another team leader) creates a project and marks it as
official. Presumably this implies that such a project really exists in
some form. Now ITLT members may take issue with the project or how we
are going about it. As leaders, they can speak with me or others to
influence us to change or cancel the project. Hopefully things work
out OK. Now if I create a project and don't mark it as official, then
there will be a temptation by our leaders to ignore the project
(after-all it is marked as unofficial) because they have more
important issues on their plates. However being marked as informal
doesn't prevent the project from happening, or more to the point, it
doesn't prevent customers from hearing commitments. So the first
chance that the leadership may wind up dealing with the project is
after a customer commitment has been made or implied.
In summary we should not use the database and its access mechanisms to
attempt to enforce an organizational mandate. If someone shouldn't be
starting projects (or projects of a certain type), they should be
aware of this and behave appropriately (and if they don't, that is an
issue between them and their management). It shouldn't be the role of
the project database to "prevent" them.
-Jeff
