To construct your personalized release checklist, cut and paste all 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. |
Low | Moderate
| High
|
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
...
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 | Moderate | High
| LOW impact confined to behind the scenes, internal areas of IS&T, and business support groups; little to no customer-facing impact. Create - Create/update portfolio listing
Place - (TBD).
- Place release date on
calendar Send - 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 - 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. low impact Contact - Contact help desk at inception to determine proper level engagement.
Contact - Contact training at inception to determine proper level engagement.
Contact - Contact documentation at inception to determine proper level engagement.
Contact - Contact key stakeholders at inception to determine proper level engagement.
Review - Review need to de-support of previous version(s).
Discuss - 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 - (ditr@mit.edu)
- Contact production@mit.edu to schedule publication of software grid to coincide with sending of release announcement
Inform release-core@mit- .
- Inform pipeline@mit.edu of release at least 1 business day prior to release.
Send - Send software grid revision to production@mit.edu for review at least 1 business day prior to release.
Execute - 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. low & medium impact lists- Low and Moderate Impact lists.)
Contact - Contact DLCs at inception to determine proper level engagement
Contact - Contact Testing & QA at inception to determine proper level engagement
Contact - Contact User Experience teams (se-uxd@mit.edu, accessibility@mit.edu, usability@mit.edu) at inception to determine proper level engagement
Consider - Consider how to support early adopters
Create - 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.
| 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.
|