[26] in Project_DB
Re: Few clarifications needed
daemon@ATHENA.MIT.EDU (Bob Ferrara from home)
Tue Feb 25 21:10:59 1997
Date: Tue, 25 Feb 97 21:10:50 EST
To: miki@MIT.EDU, tjm@MIT.EDU (Tim McGovern)
From: Bob Ferrara from home <rferrara@MIT.EDU>
Cc: project-db@MIT.EDU
At 04:20 PM 2/24/97 -0400, Tim wrote:
>At 3:27 PM 2/14/1997, miki@MIT.EDU wrote about various things...
>
>I have made my comments separate from the text to which they apply; Miki's
>original message is included at the end of my comments.
>
>Here's what I think:
>
>Relaxing the requirement for a Not NULL Practice may suffice for the
>short-term, but if we're serious about our new organization, we shouldn't
>allow this to persist..
>
>WRT the list of I/T Practices: I could live with ACADEMIC, OFFICE,
>VOICE/DATA/IMAGE NETWORKING, and COMMONS or INFRASTRUCTURE (yes, this is a
>new one!!!). All of the rest should go away. Heck, I could even live with
>the first three!
OK. I'm serious about our organization but also recognize there is currently
plenty beyond it. What if we make push to add non-IS projects, like the
MITSIS efforts, and have to invent a practice. My preference is to leave the
options open for now, and expect people like me and you, Tim, to look at
this often enough to work out any anomalies. In other words, have the list
of 5 but allow other responses, including NULL. If it stays NULL for a week,
one of us should react.
>
>This list of 28 statuses is ludicrous. I fear our "process-centered"
>organization is doomed if there are really this many different ways to say
>"I have no idea what the status of a project is..." Can't we do ANY better
>than this?
Well, I think I disagree again. Maybe there is a better way, but I actually
assigned most of these and did not choose one of the limited defaults
because I thought the "free form" answers conveyed more information and
precision. In most cases, I had an idea of the status and found the defaults
too limiting. Please try this exercise with actual, varied projects such as
we have. The utility of this approach can be debated, but remember
yesterday's alternative was NO information except the grapevine. We're way
ahead of that game.
Cheers, Bob
>Regards,
>Tim
>
>-----
>
>From: miki@MIT.EDU
>Date: Fri, 14 Feb 1997 15:27:09 -0500
>To: project-db@MIT.EDU
>Subject: Few clarifications needed
>
>
>
>
>
> Looking at the schema, erd and the Data that I have as initial data to
>the Project DB we have the following issues :
>
>
> a. The Practice is not allways filled in. I decided to relax the requirement
>for a Not NULL Practice in the DB's schema.
>
> b. We have many values for practice, which are not among the 3 (or 4)
>practices of MIT. I will list the practices as they appear in the data
>and ask for a resolution of what are the final values to be put in the DB.
>I would prefer to know what are the values for practice now, as the Web
>interface does not allow for the update of the practice table. (The values
>for practice could be changed only by somebody who is logged into the
>server machine and knows sqlplus).
>
> The values in the data I received are :
>
>ACADEMIC
>OFFICE
>MIT External
>I/T INTERNAL
>SAP / OFFICE
>INFRASTRUCTURE
>I/T INTEGRATION
>I/S INTERNAL
>
> d. The status of a project should be a value people may like to search on.
>I will put in few status values at the initial load of the DB and latter
>new values may be added. Looking at the data I have, the status has too many
>values. They are :
>
>requirements
>completed discovery
>implementation
>alpha test
>service handoff
>on hold
>in-progress
>completed
>potential
>DESIGN
>RESEARCH PHASE
>ANALYSIS: PROTOTYPE BEING BUILT
>UNDER REVIEW
>Close to implementation
>NEARING PRODUCTION
>DETAILED DESIGN
>CODING
>FINAL TEST
>SOME PORTS COMPLETE
>DESIGN: PROTOTYPE BUILT
>AWAITING IMPLEMENTATION
>COMPLETE
>PRODUCTION
>TEST
>COMPLETE as of January, 1997
>NEARING IMPLEMENTATION
>IN PROCESS
>COMPLETED DISCOVERY
>
>
>
>
>
