[181] in Project_DB
Re: Second draft of Project DB Web Page
daemon@ATHENA.MIT.EDU (Mike Barker)
Thu Aug 7 17:23:02 1997
To: "Robert V. Ferrara" <rferrara@MIT.EDU>
Cc: project-db@MIT.EDU
In-Reply-To: Your message of "Tue, 05 Aug 1997 12:01:01 EDT."
<v03020908b00cfd555af2@[18.142.3.161]>
Date: Thu, 07 Aug 1997 17:22:55 EDT
From: Mike Barker <mbarker@MIT.EDU>
Hi. I've updated the copy of this I've got in
http://web/project-db/www/whatin.html
I changed the format a bit, so it now looks like:
What do I put in the Projects Database.......and Why?
(revised Aug. 7, 1997)
To answer this, let's start with the why first. There were actually
several purposes this database was created. These are the chief
motivations:
(VISIBILITY) To provide general visibility of I/T activities to
staff and other interested people.
(RECRUITING) To make I/T staff aware of opportunities on
various projects.
(REPORTING) To simplify status and quarterly reporting.
(RESEARCH) To provide a starting point to find contacts and
related data on any project.
(MANAGEMENT) To provide rudimentary project management
tools for smaller projects.
In the future, we hope to add extensions to the database to better
illustrate the work of Standing Teams and to give better insight
into the deployment of I/S and I/T resources. Also, the plan is to
make the database fully useable by all I/T teams.
Now let's answer the question of "what do I put in the Projects
Database."
1.All formal I/S PROJECTS should be put in the Projects
database.
This naturally leads to the question "What's a PROJECT?". Any
definition is somewhat arbitrary, but for our purposes a
project is a group of related tasks that typically involves a few
person-months or more labor and has some internal structure
and interdependencies. In other words, it takes some time to
do and has some complexity. A project also represents a
formal I/S commitment, usually by a given date, to a customer.
The customer is usually external to I/S, but internal
commitments - infrastructure projects, for example - are also
common. Operationally, Process Directors or Team Leaders
can identify a major I/S commitment as a PROJECT.
2.People are also encouraged to include informal projects in the
database.
These kind of projects are characterized by lack of a firm I/S
commitment, absence of specific identified resources, or lack
of a well-defined timetable. Many are of the kind that are
useful that we would do "if we can get to it".
3.TASKS do not have to be in the database.
However, if a standing team wishes to aggregate or collect
projects under a Project, they are more than welcome to do so.
The definition of a task is also somewhat arbitrary. It usually
represents a single person's work over a period of days or
weeks, and has minimal outside dependencies.
4.CRITICAL TASKS, on the other hand, should be included in the
database
Most critical tasks will already be listed under a high priority
project. However, if they are NOT listed as part of a high
priority project, they should be "called out" in the database. A
Critical Task is a task upon which one or more projects have a
critical dependency and which is supplied, usually as a
component, to a Project team. An example might be the Ksign
component supplied by the Personal Computer team to the
ECAT project.
