Product-Release Checklist

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

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

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
    If sending outside of IS&T, send draft release announcement to IS&T communications team at least 2 business days prior to release
    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.)
    If actual dates do not match previously expected dates, update calendar

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