[411] in Project_DB
Re: proposed field changes
daemon@ATHENA.MIT.EDU (Mike Barker)
Wed Dec 30 22:10:20 1998
Date: Wed, 30 Dec 1998 21:50:03 -0500
To: project-db@MIT.EDU
From: Mike Barker <mbarker@MIT.EDU>
At 03:50 PM 12/23/98 -0500, Robert V. Ferrara wrote:
:)Hello from Chicago,
:)
:) This is a response to item 2 of Mike Barker's 12/15 memo. My action item
:)from that memo was to produce a list of recommended field changes. The list
:)below is offered for discussion only (not action) at this time. The
:)progress we make toward a direction will be reported by Susan, Greg, and I
:)at the 1/7/1999 ITLT.
Do I understand correctly? Susan, Greg, Bob are looking for feedback about
what we as an organization should do with the project database. They are
supposed to report to ITLT on Jan. 7. I would not expect any decision or
action to be taken before that report and the subsequent discussions.
This is going to be very "stream of consciousness" and way too long.
1. Job Flow Analysis: I think the first action item that the project
database group (or individuals within that group) need to undertake is to
make a list of the times and people that we expect to use the database. For
example, team leader starting a project should create an entry in the
project datebase. For each item on the list, we need to think about what
required information should be put into the database, what optional
information could be put in, and what information the database should provide.
When we know what information we want to get out of the database, we should
make sure that there is at least one point when the information is entered
into the database. And as Bob points out, if we enter information and never
use it -- let's not enter it.
These analyses of the functional use should be reviewed by representatives
of the people that we expect use the database. e.g., practice directors,
process directors, project leaders,...
I.e., instead of trying to guess at the implicit usage behind the choices
and rationales being presented, let's make the usage as explicit as possible,
then make our choices.
Some obvious examples:
1. Director is starting a project
2. Project leader is filling in project plan
3. Project leader is doing regular status reporting
4. Process Director is looking for overview of work in process
5. Practice Director is looking for overview
6. Customer is looking for current status
7. Someone is marking termination (done, killed, etc.) of a project
We need to do realistic ones and make sure that people reviewing are allowed
to say "I never do that" or "I would never record that in the Project DB".
On the other hand, since we are looking to change behavior, we should not be
afraid of saying we expect/want this to become the normal pattern, even if
it is not currently used. In those cases, we need people to walk through
the sequence as if they were really doing it.
2. I think if we concentrate on the project database software and fields,
we are starting with the wrong point. We need to think through how we
expect to use the information; what kind of training and documentation is
needed to make sure that the people entering, changing, and reading the
information are successful; and work through the feedback, rewards,
incentives and so forth that we are going to use. We need procedures,
training, documentation -- exactly as if we were providing a system for any
other group of users.
3. Based on the job flow analysis, we should have a much better idea of
what fields we want to retain, stop displaying, etc. we also should have a
better idea of the screen display(s) that are necessary or desirable.
If you're not interested in the field-by-field comments, stop here and
just take away the two points: we need to do serious job flow analysis
before deleting, adding, or changing the user interface; and, we need to
provide people with guidelines, training, and feedback about their use of
whatever we build -- just putting software out there isn't enough.
Pending that, however, here are my comments on the various fields:
:) The current 22 fields are listed below in order of appearance on the
:)Modify screen, followed by the recommendation. Also, several fields have
:)been marked Mandatory, to indicate that an entry is highly prized. Finally,
:)there is a trailing section on other fields that have been suggested but
:)never implemented.
mandatory? I believe this means the information is desirable, not that a
person filling out the form will be required to enter this information. I
also believe that delete in this sense does not mean to remove the field
from the data schema, merely that the screen display for entering the data
and showing the data should be removed.
:)1. Project name. Keep, Mandatory.
agreed.
:)2. Project headline. Keep
agreed, probably. we need to think about who puts this in, when it changes,
and who reads it. Then we need to make sure that the people we believe are
going to do this know about it, know what they are supposed to do and how,
and that we hold them accountable. we should also hold the users of the
data accountable for a while for rewarding the people who put the data in
(i.e., if the directors use this info, they should tell people thankyou when
they find correct usage).
:)3. Contact Info. Keep, Mandatory, usually project leader.
agreed. should normally be a mailing list, not an individual.
actually, we need to talk about and come up with some suggestions as to the
"normal" usage of this. I think it should be a mailing list to make
contacting the project team not depend on an individual, but we need some
guidelines for this.
:)4. Sponsor. Keep, Mandatory
agreed. however, I think we should attempt more definition as to what
sponsorship means and who can be a sponsor.
:)5. Implementor/Owner. DELETE. TJM and I agree. Any special arrangements
:)can be noted in the Description (field 19).
disagree. Specifically, I would like to rename this as project leader. I
consider it critical that there be identification of the person who is
running the project, and this is the only place that we keep that
information. (See note on team leaders -- let's call that team members
since that is what it is)
:)6. Start Date. Keep, Mandatory, but show on Project View Screen. Now it
:)never displays.
:)7. Scheduled end date. Delete. TJM and I agree. Also it does not appear on
:)either the View Project Page or the Summary Report. It never displays!
:)8. Actual end date. Keep, but show on Project View Screen. Now it never
:)displays
disagree. I believe we need clarity on the use of dates. I think we need
scheduled start date, actual start date, scheduled end date, and actual end
date. I think the scheduled (or estimated) dates should be the result of
project planning, and we need to track the actuals so that we can learn what
the variances are.
:)9. Process. Keep, Mandatory. See field 24 below for possible exctension of
:)meaning.
:)10. Practice. Keep, Mandatory.
Agree. If we are intending this to match the IS matrix organization, we
need these fields.
We also need common understanding of how a project "enters" a process, how a
practice relates to a project, and how these change.
:)11. Status. Keep, Mandatory. Not sure I yet see desirability of TJM's
:)limiting selections to just 5.
I believe Tim is pointing to the fact that we can barely get people to deal
with distinguishing planned, actual, on hold, completed, terminated -- the
broadest kind of status conditions. Again, I think some clear thinking is
badly needed about how we intend to use this status, who puts it in, who
keeps it up to date (when?), and who needs to read it. If we aren't using
it, trash it. If we are using it, make sure we have meaningful status
selections (for everyone we intend to use it) and reasonable expectations of
how this field will be updated.
:)12. Priority. Keep, Mandatory. Director should assign. It's real and
helpful.
So do all projects start with minimum priority? Until the director assigns
a different one? Is this the practice or process director who changes the
priority? What criteria are used to determine priority?
I suggest that the first problem with priority is deciding what criteria and
what meaning the priority categories have. Once we figure out who is
determining the priorities and how they are determined, we can look at the
use of the priorities, and work back to who sets them, when do they change,
and the other data entry questions.
:)13. Commitment. Keep. TJM would rather eliminate, but a few find it useful.
I think this depends directly on how we are going to use the database. If
it is the official IS project list, then we may want to "limit" it to
official IS projects. If it is an attempt to capture all of the work being
done by IS, then we may need to keep both kinds of projects.
We probably cannot do everything for everyone with one database. So let's
decide what we are trying to do and eliminate things that do not fit.
[speaking of eliminating -- we badly need a way to delete projects. For
example, I have "test" projects which I want to remove, but there is no way
to do this. We need to consider the system maintenance problems and provide
ways to take care of these.]
:)14. Description. Keep, but fix Internal Server error bug on longer ones.
How are we going to use this? Are there common elements we expect to see?
When is this description put in? When is it changed? Who reads it and for
what purposes?
:)15. Current Quarter Achievement. DELETE. TJM and I agree. The quarterly
:)reporting is not useful and really does not save time. It actually causes
:)confusion. Much prefer use of date/originator stamped Comments (field 19).
:)16. Next Quarter Goal. . DELETE. Reasons same as above.
Disagree. I thought this was the most useful addition to the database so
far. The fact that we didn't provide training, explanation, and so forth so
that it isn't being successfully used does not seem to be sufficient reason
to drop it.
However, I think we need to do the job flow analysis first, then decide
whether these fields are useful or not. If we decide they are useful, we
probably want to look at form design, guidelines for use, training, etc.
:)17. Customers. DELETE. TJM and I agree. Target customers should be
:)included, where appropriate in the Description (field 14).
I don't know. If we knew our market segments, we might want to have a pick
list of standard customers.
Putting this in the description field or another free-form place (such as
the project notebook) does mean that we will not be able to use the database
for statistics or other searches. For example, if there is some question of
how many projects are done for which customers, this field may be quite
important.
Do the job flow analysis. Then if we don't need it, get rid of it.
If we expect something to be included in the description or other free-form
place, we need to include it in the guidelines.
:)18. Team Leaders. Keep, Mandatory. This is useful and also serves as
:)authorization mechanism.
Agreed. However, let's rename it team members to match usage, since anyone
who may need to update the project information must be included in this list
(which should include all members of the project team).
Note: I assume that all members of the project team may need access to the
project information to keep parts of it up-to-date. Depending on exactly
what is kept in the project database, this may not be true.
:)19. Comments. Keep. These are useful, especially if quarterly reporting
:)items disappear. Put in bigger text block in Modify screen and allow
:)deletion like Tasks (or Bill's Milestones).
I think we need much better guidelines on what should or should not be
entered here. Especially if we are considering deleting comments, there
needs to be consideration of who puts what information in as comments when,
who deletes comments under what conditions, etc.
:)20. Documents. Keep. Tim proposes limiting this to just the Project
:)Notebook, but many are finding this a very useful field for other link types.
agreed, although I think the proposal that this be a single link to project
notebooks does have some advantages. In particular, if project notebooks
are somewhat standardized so that people know to go there to find the other
types of documentation links, and the other project-specific information,
then the project database can focus on information that is desired when
looking across projects.
:)21. Issues. Keep, but simplify per Bill and Tim's ideas.
Tim's note of December 1 says to eliminate all sub fields except the
description and the status indicator.
The four fields are category, status, owner, description.
If we were actually keeping track of issues on our projects, the owner field
would be useful (I'm assuming that issues sometimes are handled by different
people, or even change hands from internal staff to external). The category
field is less likely to be useful unless the project is large or long-term,
in which case the current project database probably doesn't provide a very
strong tool for managing the project. However, I'd again push for trying to
think through the usage, and seeing whether there is sufficient reason to
keep this or not.
I will argue that open, pending, and closed don't allow much distinction in
handling the status of issues. I'm not sure what other categories are
needed, though. Perhaps just open or closed is enough?
Incidentally, what is a pending issue? One that we can see coming but no
one else has noticed?
:)22. Tasks. Keep. See Bill Cattey message on making these Milestones as in
:)E-Reserves project. In any case, this is a useful for many projects.
Agree with keeping tasks, disagree violently with milestones. Although a
quick look at the suggested Electronic Submission of MIT Theses project
"tasks" makes me think this may be quibbling over terminology -- I don't
think the listed tasks are purely milestones. (draft, identify, review,
prototype, document, investigate -- these are not milestones)
If you want to change the label, let's go with project management standards.
Make it activities.
Activities are an element of work performed during the course of a project.
An activity normally has an expected duration, an expected cost, and
expected resource requirements. Activities are often subdivided into tasks.
Milestone. A significant event in the project, usually completion of a
major deliverable.
The work breakdown structure is a deliverable-oriented grouping of project
elements that organizes and defines the total scope of the project. It
defines all of the major project deliverables.
Based on the work breakdown structure, project planning does activity
definition.
I think we need to do the job flow analysis, consider how we want to use the
information, and then decide whether to work with deliverables, activities,
milestones, or something else. Given the relative inflexibility of the
project database, I would think about suggesting people use Microsoft
project which can now save to HTML.
This is also an area where guidelines, training, and some common
understanding are really necessary.
:)OTHER SUGGESTIONS. The purpose of the first two would be allow easy
:)extension of the Project Database to non-IS groups.
:)
:)23. Clickable Link. This is the mentioned Mike's item 1 in his 12/15 memo.
I still haven't heard anything about whether this is technically feasible etc.
:)24. Phase. This would be used to describe phase as opposed to the "Owning"
:)process. Values could be (small d) discovery, delivery, (upgrade?), or
:)production.
I am not sure what these are intended to reflect. Assuming we are talking
about projects, the PMBOK describes five processes: initiating, planning,
controlling, executing, closing.
In terms of project life cycles, they talk about various arrangements. E.g.
Determination of mission need
concept exploration and definition
demonstration and validation
engineering and manufacturing development
production and deployment
Business requirements
conceptual design
proof of concept
risk analysis
requirements, design, build, evaluation (repeated spiral)
deploy
Especially if we are generalizing the database for use by other groups, I
recommend we not constrain the kind of phases that they use to organize
their work.
:)25. Performing Organization. This is the one doing the work. In IS, one of
:)the Processes. For non-IS, the organization, like MR or CAO. Another
:)alternative is to extend the Process field above.
I guess I'm confused. I did not think that processes did the work --
project teams do the work. They are doing the work on behalf of a process.
:)In Dani's 12/3 ITLT agenda, several possible other fields were listed and
:)are discussed here for completeness sake.
:)
:)Staus Summary. Covered by status and comments.
:)Progress. Same as above but details in Project Notebook.
:)Attention Areas. Same as Issues.
:)Schedule. Detailed schedule in Project Notebook.
:)Deliverables. These would usually be included in the description and also
:)in the notebook, but maybe this merits its own field?
:)Technology. Resources,Goals for next Review. If captured, some of this
:)material would be found in the Description and more in the notebook.
If there are other discussions of fields for the project database, it would
be helpful if someone would summarize the discussion here. I'm assuming
that these fields were suggested as an outgrowth of the organizational
review work that Dani has been doing?
Two comments. First, if we expect anyone to provide any specific
information (detailed schedule, deliverables, etc.) either in the database
or in project notebooks, we need to let them know (provide guidelines),
teach them how, and provide feedback on the use. Second, the deliverables
list or work breakdown structure could be included, but we need to think
about how we intend to use this information. We have training for project
management that laid out scope statements, work breakdown structure, cost
and schedule estimation, risk management, activity networks and probably
other things -- should we use the standard terms, the approaches that people
have been trained in, and try to make use of this material?
Which reminds me -- as a suggested new field, should we include budget?
Probably an estimated figure and then actual final budget. Use a figure for
the estimated staff time, add-in equipment costs and such, and give a total
budget figure? I would think the directors might find such a number helpful
in comparing projects.
