[16] in I/T Delivery
Response to Project Support Improvement Team
daemon@ATHENA.MIT.EDU (Robert V. Ferrara)
Mon Jan 6 19:15:02 1997
Date: Mon, 6 Jan 1997 19:18:01 -0500
To: tjm@MIT.EDU, ehoffer@MIT.EDU, wade@MIT.EDU, ldean@MIT.EDU, ljr@MIT.EDU,
ridgway@MIT.EDU
From: rferrara@MIT.EDU (Robert V. Ferrara)
Cc: itlt@MIT.EDU, delivery@MIT.EDU
Dear Team,
I felt you are owed a formal response to the 4 recommendations made in
your Discovery Report. Like most of our colleagues and your interviewees
who want to "improve the experience", the ITLT shares your interest in
executing our projects better and learning from past mistakes. We are also
committing to the idea that projects will be run similarly across
Processes, and rely on as similar a framework as possible. Specifically,
I'm proposing the following course of action, which has been reviewed by
Jim Bruce and the ITLT, for each of your four recommendations.
Recommendation #1: By pre-planning projects, concerns about staying
flexible in the tradeoff between resources, scope and deadline can be
addressed.
This recommendation can be implemented in a very straightforward fashion.
As a project is officially launched, the sponsor(s) and project team leader
should produce a preliminary project plan, which includes:
1.Project Charter
scope
vision
business strategy fit
priority
2.Project Resource Management
staffing estimates
time estimates
dollar estimates
3.Major Deliverables
completion criteria
4.Macro-level Work Breakdown Structure
5.Macrolevel Timeline
6.Team Membership Recommendation
key resources
key competencies required
plan for staff recruitment
7.Stakeholders/Decision Makers
who are they?
may be different
8.I/T process & practice impact/dependencies
9.Risks
dependencies on other tasks/projects
constraints
10.Communications Plan
decision making
status
go/no go points
project publicity
project reviews
It is the Process Director's responsibility to ensure that these items are
addressed and, ideally, written down in a Web-based project notebook. There
are cases where an item may not be applicable and that's fine, but at least
that judgement will have been explicitly made. The initial checklist above
came largely out of your Discovery report and has been refined by Tim
McGovern and Lorraine Rappaport. If there are other ideas for additional
improvements, please pass thses suggestions directly to them.
To make the assembly of these plans easier, there will soon be sample
material and templates from other projects on the Web. Expect a section on
"Projects in I/T" within a week.
Recommendation #2: By making team formation more public, and possibly more
inclusive, more staff will have broader opportunities to contribute to I/T
projects.
Again, we should be able to do an even better job rather quickly by
adopting the measures the Discovery Report suggests. First, we are setting
up a public "It-project-news" mailing list and archive. The list would
include most of the development community. Project leaders will be
encouraged to use this list to announce new project opportunities and like
news. This will be an "active" form of notification. Also, items on
planning staff recruitment and project publicity have been added to the
checklist of recommendation #1.
A more passive, but still very useful, means of communication is the
Project Database now being deployed by Bill Cattey and Micki Lusztig.
Project leaders will be required (e.g. your level 2) to maintain the
entries for their projects in this Oracle database via the new Web front
end.
Basically, the view is that if it's not in the Project Database, it's not a
serious project. All the Discovery projects, even the embryonic ones, are
ready to be downloaded; now it's up to the leaders in other processes to do
the same. A very good start has already been made with the 12/17 project
list that was distributed at recent ITLT and Delivery Team Leaders
meetings.
As soon as the Project Database is successfully deployed, the plans of Erin
Hoffer and the Competency Groups for a complimentary I/T Resource and
Skills Database can then receive more attention. The Project Database will
provide visibility into the "what" and "why" of I/T projects, while the I/T
Resource Database will help with the "who".
Recommendation #3: By communicating more consistently throughout the life
of a project, more staff will be aware of all of the work that is going
on.
Once again, much of what the team would like to see is readily doable.
First, there is the Project Database mentioned above. It has fields for
current status and for pointers to project notebooks. At this point, the
use of Web-based project notebook is still voluntary (Level 1). However,
very soon there will be a complete set of notebook examples and project
support
lists on the I/S Web pages. There are already several good examples of
project notebooks now on the Web under both the Discovery and Delivery
sections.
Once again, it falls to the project leader to maintain the project notebook
and to ensure the results of regularly scheduled project reviews are posted
in a timely manner. As you suggest, there are variety of more active
optional techniques available to the project team to keep people informed,
including e-mail lists, discuss, and now Webmeet.
Recommendation #4: By increasing awareness among all staff about different
project methodologies, we can help set expectations better of everyone
involved.
I think if we can implement the recommendations as discussed above, we will
in effect have a simple, small "m" methodology. As Bill Hogue has expressed
it, this collection of recommendations should become our usual "standards"
for projects. In this sense, they are much like the hardware or software
standards we all work with in other aspects of our jobs.
There is some interest in looking beyond these basic standards. Tim
McGovern and a few of us are checking out the Software Engineering
Institute's Capability Maturity Model. Several of the ITLT would also
consider sponsoring a Discovery Project to look further into both small "m"
and large "M" (formal) methodologies, starting with surveying what our
people know already. We have some of the work done by the MITSIS group on
this topic.
The above responses address all the key deliverables proposed on page 16 of
your report. Given this, I believe no separate Delivery Project is
necessary. We therefore request your advice and support to implement now
all the responses outlined in each of the above sections.
Thank you, Bob Ferrara
