This documentation is for planning the release of RAFT PhII to the support areas of IS&T. Other parts of the project plan and implementation details that are not relevant to support teams should go elsewhere.

Checklist

Working on order of priority and chronology.

Initiation

• Define points of contact from IS&T Teams to Engage, right.
  • Contact help desk at inception to determine proper level engagement.
  • Contact training & docs 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
  • Contact documentation SE Web Services at inception to determine proper level engagement.
  • Contact key stakeholders, DLCs at inception to determine proper level engagement.
• Form release team, reserve resources.

Planning

• Enter release date, and other significant dates, on Change Communications Calendar.
• Consider how to support early adopters or pilot users, phase out current version?
• Define release-decision, acceptance criteria.
• Code management/versioning and continuous integration plan with release engineer (SE Web Services)
• Review need to de-support of previous version(s), communications to current users.
• Create communication plan, based on stakeholders identified in prior steps.
• Create testing plan, with QA resource if available.

Executing

• Provision systems, VMs, based on initial architecture plan.
• Update datacenter SLAs with technical, financial, business contact information.
• Training curriculum, work with Training to ramp-up Help Desk (business-help).
• Form ad-hoc architecture review team. Review initial architecture.

Monitor and Control

• If actual dates do not match previously expected dates, update calendar.
• Twice-weekly roundup of Jira issues, open bugs related to next sprint.
• Continue to ad-hoc test software on all supported operating systems, whether or not there are formal QA resources (runtime, browser).
• If sending outside of IS&T, send draft release announcement to IS&T communications team at least 2 business days prior to release.
• Inform release-core@mit.edu, pipeline of release at least 1 business day prior to release.
• Execute (Send announcement, post software for download, etc.)
• Second architecture review, same reviewers.

Closing

• Send announcement and change log to release-core@mit.edu, stakeholder list once release is complete.
• Update any known open issues (Jira, Request Tracker) affected by release and close.
• 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.

Open Questions

• SLAs for help desk, operational support, etc. What is acceptance?
• Escalation paths for help desk and ops, where to documenent?
• Documentation consolidation: bring more in line with de facto IS&T practices? Maybe not this phase.
• Expectations for new communications plan: better stakeholder engagement.

Notes

We are a pilot for IS&T's product-release checklist. We used it as a base for this plan though it was developed for distributed/desktop release. Notes for Release-Core.

Product-Release Checklist. You might not have authorizations to view the release-core wiki.

Based on this system's criteria, RAFT is Resources: Moderate, Community Impact: Moderate, and Risk to IS&T: High.