[174] in Project_DB
DRAFT of Project DB Web page (all ascii, without html)
daemon@ATHENA.MIT.EDU (Mike Barker)
Thu Jul 24 11:57:34 1997
To: rferrara@MIT.EDU
Cc: project-db@MIT.EDU, pbh@MIT.EDU
Date: Thu, 24 Jul 1997 11:56:54 EDT
From: Mike Barker <mbarker@MIT.EDU>
Since I had trouble reading it, and I know there may be others, here
is a pure ascii copy. I also did a quick HTML conversion and put a
copy of this in http://web.mit.edu/project-db/www/whatin.html
mike
What do I put in the Projects Database.......and Why?
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/S activities to
staff and other interested people.
(RECRUITING) To make I/S 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 resources. Also, the plan is to make the
database fully useable by all I/T teams.
All formal 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, has some internal structure and interdependencies, and
represents a formal I/S commitment, usually by a given date, to an
external customer. Operationally, Process Directors or Team
Leaders can identify a major I/S commitment as a PROJECT.
People are also encouraged to include informal projects may also
be included in the database. These kind of projects are
characterized by a lack of a firm I/S commitment, no specific
identified resources or timetable. Many are of the kind that are
useful that we would do "if we can get to it".
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.
CRITICAL TASKS, on the other hand, should be included 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 the Project team. An example might be the
Ksign component supplied by the Personal Computer team to the
ECAT project.
