[179] in Project_DB
Second draft of Project DB Web Page
daemon@ATHENA.MIT.EDU (Robert V. Ferrara)
Tue Aug 5 11:57:22 1997
Date: Tue, 5 Aug 1997 12:01:01 -0400
To: itlt@MIT.EDU
From: "Robert V. Ferrara" <rferrara@MIT.EDU>
Cc: project-db@MIT.EDU, pbh@MIT.EDU
People, here's the second (final?) draft of the Project DB web page.
Most people seem to like it and several provided helpful comments, all
of which have been incorporated. So now I'm asking Dani to put an
agenda item at a future ITLT regarding adoption of this web page.
Thanks, Bob
-------------------------------------------------------------------------------
<fontfamily><param>Times</param><bigger><bigger>
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/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
eventually make the database fully useable by all I/T teams.
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.
People are also encouraged to include informal projects 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 tasks 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
if they are not already listed under a high priority project. 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.
</bigger></bigger></fontfamily>
