Software Release Draft October 20, 1999

1
Software Release Draft October 20, 1999

• Team MembersTheresa Regan, Team SponsorMike
  BarkerMary Ellen BushnellJonathan HuntSusan
  B.JonesLeonard KimbleJeff Pankin,
  FacilitatorGinny WilliamsAl Willis
• Mohammed Sharari
• Marshall Vale

2
Where we startedThe Charter

• Justification IS lacks a clear and consistent
  small-p process for recommending and releasing
  software to the MIT community. The current
  process cuts across all Practices and Processes
  to some degree
• A clear, consistent and replicable process for
  handling software recommendations and releases
  will alleviate much of MIT user and IS internal
  confusion.
• ScopeThis project will (focus) on the software
  recommendation and release process (for)
  Netscape, Eudora, Kerberos, HostExplorer, SAPgui,
  and MS Office

3
The Charter, contd

• DeliverablesThe major deliverables of this
  project are
• Archived project planproject notebook
• Full process design
• Customer feedback summary, perhaps via a pilot
• Detailed implementation plan for making the
  process designed a reality
• Final report, including recommendations for the
  redesign process, as well as for the level of
  staffing with required skills and competencies

4
What customers want

• Timely, seamless transitions to supported
  software.
• Current perceptionGet on the ball with new
  version support. The Eudora situation is
  embarrassing and very frustrating. Voice of
  the Customer Gartner Survey August 12,
  1999

5
What customers want, contd

• Consistent communications on the status and
  timeline for software releases.
• Current perceptionIS must think I can read
  their minds, for I havent been told anything
  about what will be released or when. Customer
  Interview Gartner Survey September, 1999

6
Where we need to be

• Benchmark In the business world, there is an
  expected benchmark for software releases of 6-8
  weeks for internal deployment with customization.
• IS should have a statement on whether and when a
  new product or product upgrade is to be released
  within one to 45 days of its announcement.
• IS should have an established process that
  becomes a routine way to accomplish software
  releases within a three-month timeframe.

7
What we didIdentified the software to be
delivered and delivered It

• Macintosh Windows
• Eudora 4.0.2 Eudora 4.0.2
• Netscape 4.6 Netscape 4.6
• BetterTelnet 2.0 HostExplorer 6.0.2
• MIT Kerberos for Macintosh (v2.0.2) Leash32
  v2Kerberos4, Kerberos5 Kerberos4, Kerberos5
• SAPgui v4.5B SAPgui v4.5B
• MacOS 8.6 SP3-hot fixes-bug fixes
• SP5-hot fixes-bug fixes
• Office 2000

8
What else we did

• Gathered input on desired team roles
• Tested new roles, such as product coordinator
• Learned to write installers
• Collected input on installer behavior
• Recruited testers
• Identified flaws in the current distribution
  process
• Developed a process for delivering new releases
  and updates of old products

9
What we did Developed a case for action

• The current situation in regard to Software
  Release is that there is no defined process.
• As a result, releases may or may not occur with
  subsequent costs to
• users
• the IS organization
• MIT as a whole.

10
Case for action, contd

• Costs to users
• Confusion about if and when the new version w/be
  released and supported
• Frustration with IS
• Loss of productivity
• May purchase wrong/unsupported/difficult to
  support software
• Costs to IS
• Loss of reputation with users. IS is viewed as
  not meeting customer requirements when releases
  take from 3 months to two years or longer, or
  never happen.
• Expensive inefficiency within the IS
  organization. There is a lack of continuity and
  organizational learning when each release must be
  invented from scratch.

11
Case for action, contd

• Costs to the Institute
• When MIT has a site license, but customerstired
  of waiting for upgradespurchase shrink wrapped
  copies.
• When the opportunity to benefit from a volume
  license is missed because most of the community
  has purchased individual copies.

12
What we are doingWe propose the following

• Process
• Staffing
• Organizational changes

13
Software Release Team
14
Process proposals

• Implement a defined process for software release
• Build the skills and competencies among staff
  that are required to deliver on this process
• Establish a release team for any given product
  that tracks a product through its life cycle.

15
Staffing proposals

• A full-time, dedicated software release
  coordinator (team leader) to oversee the SWR
  process.
• Two platform coordinators (Macintosh and Windows)
  to manage consistency within his/her platform of
  the supported software.
• An installer coordinator to maintain and train a
  pool of installer writers
• A test coordinator to maintain a pool of
  technical and usability testers for new/updated
  software and installers.

16
Staffing proposals, contd

• For a given product, name a team to oversee the
  SWR process through its life cycle with the
  following staff
• release coordinator
• installer writer
• tech writer/trainer
• test coordinator (to line up testers)

17
Organizational proposals

• Assign the SWR process to an IS Process Director
  who takes ownership for the effort.
• Assign the Practice Directors responsibility to
  advocate for the customers needs, factoring in
  the vendor's direction and the direction of I/T.

18
Outstanding issues

• In which single Process will the Software Release
  Process live?
• What support and actions are necessary to adopt a
  defined small-p process?
• What is the limit of the scope for products
  handled in the SW Release process? (E.g., IS
  supported products or IT recommended products
  such as Coeus and Nimbus)
• What is the relationship between the software
  release process and Integration?
• What is the role of the Desktop Products Team
  regarding the software release process?

19
Next steps?