The FINAL Product Release Checklists can be found in Hermes at: http://kb.mit.edu/confluence/x/bgK9

To construct your personalized release checklist, cut and paste each of the nine possible lists that match your criteria into a master checklist for your project. Each checklist category is divided into Low, Moderate, and High levels. If you are undecided on the right level, you should round up (That is, if you are torn between a Low or Moderate level, go for Moderate.).

Resources Required for the Release

Low Resources

Moderate Resources

High Resources

Based on the number of personnel required to perform the release; not the whole project team; low, moderate, or high.

Release is performed by an INDIVIDUAL staff member or equivalent within the context of existing assignments and responsibilities. No separate budgeting and resource allocation is usually done for this level. Time is usually measured in DAYS.

  • Enter release date on Change Communications Calendar and email dates to pipeline@mit.edu.
  • If you require a custom installer, complete SWRT's Installer Support Request Form at least two week prior to release.

Release usually performed by a SINGLE TEAM with contacts into other parts of the organization and into business stakeholder groups. Often involves formal resource allocation and an ad-hoc release team. Projects in this category may involve software licenses and other materials and services budget items. Time is usually measured in WEEKS.

  • (Include Low Resources task list.)
  • Complete Release-Decision Template.
  • Form release team.

May involve an entire ORGANIZATION of project teams, release teams, and transition teams, staff in many parts of the organizations, consultants, formal budgets usually accounted for as part of IS&T’s central budgeting process, significant licensing, materials and services, and capital budgets; time is usually measured in MONTHS or YEARS.

  • (Include Low and Moderate Resource task lists.)
  • Obtain senior staff approval.
  • Create Daptiv project.

Impact to the MIT Community

Low Impact

Moderate Impact

High Impact

How much of the MIT Community will your project affect and how much will they be affected?

LOW impact confined to behind the scenes, internal areas of IS&T, and business support groups; little to no customer-facing impact.

  • Create/update portfolio listing (TBD).
  • Place release date on Change Communications Calendar and email dates to pipeline@mit.edu.
  • Send announcement and change log to release-core@mit.edu once release is complete.
  • Update any known open issues affected by release and close. 
  • If sending outside of IS&T, send draft release announcement to IS&T communications team (ist-comm@mit.edu) at least 2 business days prior to release. 
  • If actual dates do not match previously expected dates, update calendar.

LOCAL or bounded to small group, roles, or department; group of customers of service or product, while it may be significant in size, is usually within a specific domain with well-established communications channels; we know who uses product or service and how they will react to changes.

  • (Include steps from Low Impact list.)
  • Contact help desk at inception to determine proper level engagement.
  • Contact training at inception to determine proper level engagement.
  • Contact documentation at inception to determine proper level engagement.
  • Contact key stakeholders at inception to determine proper level engagement.
  • Review need to de-support of previous version(s).
  • Discuss release with DITR (ditr@mit.edu)
  • Contact production@mit.edu to schedule publication of software grid to coincide with sending of release announcement. 
  • Inform pipeline@mit.edu of release at least 1 business day prior to release.
  • Send software grid revision to production@mit.edu for review at least 1 business day prior to release.
  • Execute (Send announcement, post software for download, etc.)

WIDE impact to large segments of the MIT community, often with incomplete understanding of precise impact and user base, and without complete communication channels into community segments; customers often rely on affected products and services for their day-to-day work.

  • (Include steps from Low and Moderate Impact lists.)
  • Contact DLCs at inception to determine proper level engagement
  • Contact Testing & QA at inception to determine proper level engagement
  • Contact User Experience teams (se-uxd@mit.edu, accessibility@mit.edu, usability@mit.edu) at inception to determine proper level engagement
  • Consider how to support early adopters
  • Create communication plan

Risk to IS&T

Low Risk

Moderate Risk

High Risk

How much will a failure to perform a smooth or seemless release affect IS&T's relationships with our customers?

Negligible to LOW; service alternatives are readily available, service continuity is not at risk, and changes can be backed out quickly and quietly.

  • Search http://ist.mit.eduand http://kb.mit.edufor any articles that would be invalidated by release and update as needed. Contact istweb@mit.edu if you are not sure how to update this documentation.
  • If posting new software, contact the Software Release Team to ensure that previous and new versions are archived in their definitive software library.

MEDIUM, with failures of potentially significant impact but affecting a limited audience; contingency and roll-back checklists are needed, but can be executed and communicated quickly in the event of a problem; limited, well-understood downtime is generally acceptable to stakeholders and customers.

  • (Include Low Risk task list.)
  • Test software on all supported operating systems.

HIGH risk is involved at this level; failures will have significant negative impact on IS&T’s reputation and customer’s ability to get work done; formal mitigation plans, fully tested and approved contingency plans, and communications plans in the event of failures are called for.

  • (Include Low and Moderate Risk task lists.)
  • Create testing plan.
  • No labels