[216] in I/T Delivery
Project Database portion of Joint Project Leaders meeting 1/15/1999
daemon@ATHENA.MIT.EDU (Bill Cattey)
Thu Jan 28 03:24:57 1999
Date: Thu, 28 Jan 1999 03:24:50 -0500 (EST)
From: Bill Cattey <wdc@MIT.EDU>
To: delivery@MIT.EDU, fortoul@MIT.EDU, tjm@MIT.EDU, brendakg@MIT.EDU,
jjv@MIT.EDU, pbh@MIT.EDU, mca@MIT.EDU, thorne@MIT.EDU, dania@MIT.EDU,
repa@MIT.EDU, tytso@MIT.EDU, gii@MIT.EDU, kelley@MIT.EDU,
bobmah@MIT.EDU, reidmp@MIT.EDU, pakulat@MIT.EDU, jives@MIT.EDU,
cgteam@MIT.EDU
15 January 1999
Project Team Leaders Meeting
Project Database Discussion
Summary:
At long last the effort is being made to extend discussion about the
evolution of the Project Database to the Project Leaders charged with
using it daily.
Most of the discussion that took place on the 15th centered around what
should be in the Project Database, and getting a clearer common vision
of what the Project Database should be for.
There was some discussion of the Draft "Work Flow Analysis" that
presumes to identify who uses the Project Database and for what.
Expect to see a more widely published version of the Work Flow Analysis
that incorporates the feedback from the meeting.
Expect to see an announcement of what short term steps are going to be
taken to enhance the ease of use of the Project Database, and to clear
up areas that the discussion called out as still being confusing.
--------
Detail:
Overview:
It is long past time to more actively involve Project Leaders in the
evolution of the Project Database. This discussion was the first piece
of doing so.
A "Work Flow Analysis" that identifies who uses the Project Database and
what for has been drafted. The discussion elicited comments on this
draft. Those comments will be incorporated in a subsequent draft that
will, we hope, be a powerful and sensible guide to further work on the
Project Database.
There has been discussion about what data should be in the Project
Database amongst a small group of people. The discussion at the Project
Leaders meeting served as a good starting point to extend that
discussion to the wider audience of Project Database users. The
comments made are affecting the long term and short term direction of
the Project Database.
----
Agenda:
Review and discuss what fields are in the Project Database Today (15 Mins)
Discuss DRAFT flow analysis (15 Mins)
Possible outcomes into the Future? (5 Mins)
--------
The rest of this note covers the discussion itself:
Goals for Project Database:
Make it a reasonable tool for Project Managers
Make it easier to use.
Use it to help with communication.
----
Comments on the Project Database
What's good, bad, indifferent, confusing, etc.?
There are two perspectives on the Project Database:
Provider, and Consumer
Provider Issues:
Use by Project Manager to help manage a project.
Consumer Issues:
Creation of a new project in the DB is much harder than modifying one.
Meanings of the terms used are unclear
e.g. status, "commons", priority.
More help is needed, perhaps a glossary or links.
Other issues:
Internet Explorer doesn't work with MIT certificates. (Being worked on.)
Clarify what items entered show up in which reports.
Think about what reports should be viewable.
What is the right unit of focus? project? process?
It should be possible to view project documents associated with
particular phases of a project, discovery, delivery, etc.
But this might be best done in outside the Project Database, perhaps
in the Project Notebook/Homepage.
Is the need for a historical record/point in time picture or as
ongoing project information?
Expect archiving practices will evolve over time.
Can the Project Database help move work forward by showing when a
project is in need of one final push into the next phase?
Can useful dates be shown from a higher level, perhaps an audit trail
of which dates were set when for review of how estimates are done?
Calculate deltas from estimates to improve estimation skills.
Does the Project Database have applicability as a tool for I/T outside
of IS?
Is the Project Database a tool to help to manage the day-to-day work
of a project, or for reporting status?
Tool survivability issue: What are the commonly understood data elements
that will survive the current implementation?
Proposed Directions:
Get Project Database out of the business of imposing a methodology.
Suggested changes:
Add a link to the project home page or project notebook to the
project list page.
Fix HTML word wrap.
Give hot links to REAL definitions for terms in pick lists.
Discussion of specific Database fields:
Change the "Team Leader" item to "Team Members" to show membership, and
to reflect requirement to give all members ability to modify project
entries.
Some objected to elimination of Quarterly Achievement/Goal fields
Specify that "Contact Information" is how to contact the Project Leader.
"Change Implementor/Owner" to "Project Leader"
----
Comments on the Job Flow Analysis
Trying to confirm we know who uses Project Database
and what for.
Possible missing Stakeholders:
jdb? Can he be grouped with "Directors"?
Service?
Support?
Future direction:
Find a way of creating a Mini Project Database with all the fields of
as we currently know them, but accessible as a separate universe of
projects.
This would be useful for other IT organizations at MIT.
It would be useful for teams who want a tool for internal project
discussion/management.
Need a tool with common terms that can survive across organizations.
(e.g. IS Processes don't map to other organizations.)
Non IS use:
Current implementation contains many IS specific aspects.
How to define the future Project Database
Need to decide what is god for IS within current Project Database.
Need definitions of Sponsor/Stakeholder, customer list
Who is doing this work?
----
People interested in working Project Database issues should contact
project-db@mit.edu
or
wdc@mit.edu (or Bill Cattey in person.)
Suzanna Lisanti has volunteered to help work the project notebook issues.
----
Conclusions:
Project Database does serve a useful function as a gateway/entree to
more detailed information on IS projects.
The Project Database needs to continue to evolve as a tool, but with
enhanced ease of use and flexibility.
Next Steps:
Incorporate the changes in the Work Flow Analysis, and publish it.
Inventory the requested changes, cost them out, and schedule such
work as is appropriate.
Note: The inventory should be publicised for feedback on which changes
are considered by the users to have the highest value.
