[448] in Project_DB
Re: A Proposal For Moving Forward on Project DB
daemon@ATHENA.MIT.EDU (Robert V. Ferrara)
Tue Mar 23 11:25:35 1999
In-Reply-To: <oqxhtZQGgE6e18n_Y0@mit.edu>
Date: Tue, 23 Mar 1999 11:26:50 -0500
To: Bill Cattey <wdc@mit.edu>, project-db@mit.edu,
Mike Barker <mbarker@mit.edu>
From: "Robert V. Ferrara" <rferrara@MIT.EDU>
Hello,
After a discussion with Mike this morning, I'd like to add a fifth
principle, 2 amendments, 1 counter-amendment (to Bill) and add two
clarifications. If you are happy with these, then I think we have closure.
Principle 5. The director is responsible for the content and accuracy for
the material in the Project-DB. The Team Leader is responsible for the
content and accuracy for the project notebook. After the proposed changes,
there is simply not that much material in the Project-DB to maintain and
what is left is very appropriate for a director's attention and scope of
responsibility. A director could ask the team leader to initially populate
the DB for a project, but after that it's easy to keep updated.
Amendment 1. Using Bill's limited set of Status values, I believe this
status should be maintained in the Project-DB.
Amendment 2. Retain the Comments field in the Project-DB. No change need be
made (although a date-stamp would be nice). This allows a Director (or TL)
to post news or milestones for easy access. The Comments accumulate just
below the Description, which is appropriate.
Counter-Amendment 1. I think we should retain the "Practice" field since
these are defined globally already. For the other field, I think naming it
"director" connotes a personal relationship and what is desired is the
organizational responsibility. Therefore I think it should be called
"Process/Performing Organization". This combination works well for all the
IS and non-IS scenarios I can think of.
Finally, I would like to refine just two items Mike mentioned. First, the
near term effort would a add a live web link to the project list. Mike
suggests that if there is no project notebook or home page link, the
project leader's mailto: would be the default. Second, in order to live the
process model, we would do a Discovery effort - perhaps just of the "short
form" variety on the longer-term effort.
Thanks you for your attention to this. Wouldn't it be great to have
closure on this subject!!
Cheers, Bob
At 7:20 PM -0500 3/22/99, Bill Cattey wrote:
>Mike:
>
>Summary:
>
> I agree with almost all of what Mike Proposes
> I suggest a 4th principle.
> I suggest 2 amendments.
> I ask we try to improve on Priority and Commitment longer term.
>
>Amendment 1: Keep Status, but cut back to ONLY 5 values:
> Pending, Active, OnHold, Terminated, Completed
>
>Amendment 2: Get rid of Process and Practice and instead have Director.
>
>-wdc
>----
>Detail:
>
>That is an excellent analysis and proposal, and I agree with almost all of it.
>
>In hallway chat the other day, I tripped over another principle that
>should definitely underly the longer term work, and might be able to
>benefit the short term work:
>
>4. There is a need for structure in what is displayed about projects,
>and web page creation may or may not offer sufficient structure.
>
>I feel uncomfortable with the decisions you've proposed regarding
>Process, Practice, Status.
>
>My guess is that you moved Status out because it is volatile. I would
>keep it because I think it helps organize and group the projects. I'd
>propose cutting back the VALUES of Status to:
> Pending, Active, OnHold, Terminated, Completed
>Any other status information belongs, quite rightly, in the project notebook.
>
>I would advocate replacing Process and Practice with different entities.
> I feel that Process and Practice are too IS-centric, and do not capture
>the essense of what is needed. The problem is in getting consensus on
>what is needed. I can understand how it REALLY simplifies the
>short-term work if we just leave them as they are, try to clarify as
>best we can, and move on. I'll throw out ONE alternative:
>
>Remove Process and Practice, and replace it with "Director". If the
>director is not set, the project is informal, and has no committment of
>resources. If the Director is set with the ID of one of Jim, an Process
>Director, or a Practice Director, the project is formally committed and
>the director named is the primary director to talk to regarding issues
>of resourcing and prioritization.
>
>I'm a little uncomfortable leaving Priority and Committment in the db,
>simply because they've been so poorly used in the past. I'll not
>formally object, but I'd just ask that we try and improve upon
>Priorities of "Low, Medium, and High". I fear here, that priorities
>will end up being of the form "Project A is a prerequisit for Project
>B", and "Project X is of lower priority than Project Y, specifically."
>I think that that kind of information MAY be able to go into the longer
>term Projects Database Tool. I also ask that we try and be serious when
>we choose Formal and Informal committment levels.
