You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

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.

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.

  • Place release date on calendar.
  • 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.

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 medium 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. 
  • Place release date on calendar.
  • 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 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.
  • Contact production@mit.edu to schedule publication of software grid to coincide with sending of release announcement. 
  • Inform release-core@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 & medium impact lists)
  • Contact DLCs at inception to determine proper level engagement
  • Contact Testing & QA at inception to determine proper level engagement
  • Contact User Experience at inception to determine proper level engagement
  • Consider how to support early adopters
  • Create communication plan

Risk to IS&T

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

Low Risk

Moderate Risk

High Risk

Work can be done generally be done 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

    Place release date on calendar

Usually confined to a single TEAM with contacts into other parts of the organization and into business stakeholder groups; formal resource allocation is often involved, and an ad-hoc release team may be formed; 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
    Create release team
    If a custom installer is required, complete SWRT's Installer Support Request Form at least two week prior to release

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 medium resource task lists)
    Obtain senior staff approval
    Create Daptiv project

  • No labels