[212] in magellan
DRAFT Notes from Discussion of June 18, 1999
daemon@ATHENA.MIT.EDU (Bill Hogue)
Mon Jun 21 21:52:07 1999
Message-Id: <v02140b00b39491af6ecf@[18.162.2.132]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 21 Jun 1999 21:58:11 -0400
To: support-tl@MIT.EDU, rferrara@MIT.EDU, azary@MIT.EDU, ganderso@MIT.EDU,
magellan@MIT.EDU, delivery@MIT.EDU, integration-ptl@MIT.EDU,
tregan@MIT.EDU, vkumar@MIT.EDU, dbaron@MIT.EDU, clwood@MIT.EDU
From: hogue@MIT.EDU (Bill Hogue)
Below are transcribed notes captured on flipcharts, with some additional
details of discussions that took place in two of the teams at the meeting
of members of Discovery, Delivery, Integration, and Support (DDIS) on June
18, 1999. If you spot any glaring mistakes of interpretation please let me
know.
(Bob, Susan, Greg -- please forward to the appropriate distribution lists
if I've missed someone.)
TOPICS/ISSUES TO PURSUE
1. Integration of Support into projects early rather than waiting for a
hand-off - e.g., documentation ready as a project ends. ISSUE: Support
members of the team throughout the project, or as consultants along the
way....how and when to decide.
2. It is an important piece of a good business model for the the final
implementation plan to be considered early in the project (Discovery).
Insure that costs and financing are in place as the project moves into
Support/Service.
3. Defining Support requirements is hard -- "it depends." Moving toward
better definition of requirements will help the effort toward more
collaborative work.
- We need an improved mechanism to help conversations with Support.
A smaller subset of Support could be identified for advice, discussion of
issues, etc.
- We need an clearer description of Support: who, how we work,
what we do.
4. Individual Support representatives may not be able to speak for all of
Support; this may indicate the need for multiple representatives from
Support on a project team -- or perhaps none in some circumstances. <n.b.
- "no representation" does not indicate lack of communication>
5. Use business models to help define Support roles and responsibilities.
- There is a need for more cross-functional exchanges across
projects and standing teams in Support.
- Formalize the grapevine... we need a logical place to understand
the scope of what's going on.
- Communicate early and often. Creators and users sometimes have
differing points of view... reconciliation of this differing views is a key
issue.
- "User visible changes" is a concept from Athena development days
that may be worth resurrecting and adapting to current needs and practices.
6. Communication to/from frontline Support...
- Make it clear, highlight issues (e.g., printing). Say what is
important.
- Support needs to communicate clearly to Service... maintenance
issues and bug fixes, for example.
- Guidelines or a checklist for the evolution of work into Support
would be helpful.
7. Recognize Support involvement/participation in projects as part of
performance appraisals, etc.
8. See it, own it, solve it, do it. Concept applies to both Support and
projects.
9. What kind of communication is needed for Support from projects?
- Provide enough information about design decisions, trade-offs,
constraints, context so that Support can interpret and interpolate.
Projects need to capture that information as discussions take place on
behalf of Support.
- When to communicate? As early as possible... e.g., visibility
and/or involvement in the design phase. (ATIC Lab re: accessibility, for
example)
- Invite people over, e.g. RCC meetings.
10. ADDITIONAL NOTES PROVIDED BY BARBARA GOGUEN.
There were some other interesting nuggets that our group discussed that did
not make it into the large group sharing.
- we noted that perceptions of one's role are often misguided. we tend to
think that the director you work for determines your role and your
competencies. example: oliver could only be a developer if he decided to
work for bob in the delivery process.
What Support requires
- "it depends"
- knowledge of all projects at all levels - underlying design, constraints,
decision-making process, what got left out as well as what got left in
- acknowledgement that we are often the spokespeople of IS, and can only
speak about what we know
When
- we need substantive involvement throughout; doesn't mean we need to be
active team members throughout
How
- we did note in the big group our idea to have a support review group,
along the lines of the itit review group. what we didn't note were some
further ideas along this path such as defining the competencies needed to
represent support concerns on the support review group and recruiting
appropriate staff with the right competencies into those roles. it would
offer some concrete professional development opportunities within support,
and potentially broaden the understanding within other processes of some of
the expertise that exists within support.
11. NOTES PROVIDED BY CRAIG COUNTERMAN.
- communication to front lines and -- when product is in production
-- communication of customer feedback
- consider a financial and resource allocation model right from the
beginning of a project, and consider having a Support member on a project
team from the outset
- articulate Support requirements for moving a product to
production, similar to those listed by Service.
==========================
NEXT STEPS
1. Transcribe and distribute these notes. (hogue)
2. Support to develop first iteration of guidelines for moving products
into the Support space. (team leaders, goguen)
3. Meet again, perhaps this fall.
- provide more time for discussions
- provide clearer instructions for sub-groups
- provide more time for reporting back
- fully devote the meeting to this kind of communication without
other competing agenda items.
