University of Michigan Information and Technology Services
System Development Life Cycle (SDLC)
S7000A – Release/Rollout Approach Document
SDLC Release/Rollout Approach
I. Introduction
This approach document was created for University of Michigan Information and Technology Services’
(ITS) System Development Life Cycle (SDLC) projects.
A. Purpose of Release/Rollout Analysis Phase
The purpose of the Release/Rollout phase is to provide for adequate planning, preparation, and
introduction of the new or modified system or enhancement.
B. Approach Description
The general methodology/approach for the SDLC Release/Rollout Phase at ITS will involve the
following steps:
1. Initial planning efforts for this phase will include the establishment of a:
a. Project Status reporting approach.
b. Error Tracking Approach.
c. Metric Collection Approach.
2. TIO will perform the TIO Infrastructure Project Methodology, providing those services
and deliverables, including configuring or installing new hardware, software or
networking, and configuration and setup of new environments.
3. Begin Planning Activities.
a. Initiate Pre-Release Planning.
i. Determine Release Type.
ii. Review & Update the Release/Rollout Approach Document.
iii. Develop Contingency Plans.
iv. Review the Release/Rollout Approach Document (including Contingency
Plans).
v. Ensure the Release Date is entered on the ITS Cross-Release Calendar.
b. Perform Production Readiness Test (PRT) Planning.
i. Develop a Detailed PRT plan. Include the following:
Document1
o
Pre-Release
o
Infrastructure Testing (if needed)
o
Gateway Authentication
o
Cross-Module Testing Setup (if needed)
2/9/2016
Page 1 of 5
University of Michigan Information and Technology Services
System Development Life Cycle (SDLC)
S7000A – Release/Rollout Approach Document
o
Cross-Module Testing (if needed)
o
Batch Jobs (if needed)
o
Module Testing
o
System Accessibility
o
Post-Release
c. Initiate Release Planning.
i. Review and update the Release Plan.
ii. Develop a Stabilization Plan.
iii. Review the Release, Stabilization, and Production Support (from TIO)
plans.
d. Perform Rollout Planning.
i. Review and update the Performance Support Plans (Performance
Support Team).
ii. Communicate and Execute the Performance Support Plans (Performance
Support Team).
4. Prepare for Release/Rollout
a. Release Preparation.
i. Confirm the Release Date.
ii. Define any CSR’s that are needed for Migration.
iii. Update the Release Plan (checklist).
iv. Ensure Permission Lists & Roles are Defined (Security & Access
Services).
v. Review and communicate the Release Plan.
b. Migration Preparation.
i. Update, then communicate the list of development CSR’s, tables, etc.
ii. Update, then communicate the list of Security CSR’s.
iii. Review and approve the list of development CSR’s, tables, etc.
iv. Review and approve the list of Security CSR’s.
5. Release/Rollout Activities
a. Perform Backups, Tables Exports, and Validation as needed (TIO, DBA).
b. Migrate Objects (Migrators).
Document1
2/9/2016
Page 2 of 5
University of Michigan Information and Technology Services
System Development Life Cycle (SDLC)
S7000A – Release/Rollout Approach Document
c. Perform Security Changes (Access Services & Security).
d. Coordinating with TIO, and referring to the ITS SDLC Practice Moves
Methodology, Perform the Install/Conversion and Dress Rehearsal activities.
e. Execute PRT and Regression Testing.
f.
Analyze the Results.
g. Make Go/No-Go decision.
h. If No-Go decision, execute the prepared Contingency Plans.
6. Stabilization & Cleanup Activities
a. Communicate the status of the Release/Rollout.
b. Execute Post-Release Tasks and the Stabilization Plan.
c. Debrief the Release/Rollout Team.
d. Close any CSR’s, and revise the Methodology template as needed.
III. Status and Reporting Metrics
A. Error Tracking Approach
During the Release/Rollout Phase, problems encountered will be tracked within a Tracking
Spreadsheet/Database.
B. Time Tracking & Reporting
The Project Manager will be responsible for ensuring that time is entered into PlanView and that
Monthly Status Reports are created.
C. Metrics To Utilize
Suggested Metrics to be tracked:
1. Number and Percentage of New, Obsolete, and Carried-over Modifications, by priority (A, B, C), that are
in progress, in error, in review, approved, deferred, or not begun.
2. Number and Percentage of Requirements documents, by priority (A, B, C), that are in progress, in error,
in review, approved, deferred, or not started.
3. Number of Eliminated or Obsolete Modifications.
4. Percentage of Effort Earned/Earned Value (Planned vs. Actuals).
5. Percentage of Effort Remaining.
D. Release/Rollout Phase Status/Issues Meeting
During Release/Rollout Analysis Phase, it is recommended that a weekly status meeting be held at the
same scheduled time on the same day each day. This meeting will support a communication process
Document1
2/9/2016
Page 3 of 5
University of Michigan Information and Technology Services
System Development Life Cycle (SDLC)
S7000A – Release/Rollout Approach Document
to inform the project team on Project Status, Issues, Risks, and Changes. The Agenda can include a
review of open high and medium issues, the overall Release/Rollout Analysis Phase schedule, and any
action items from the previous week.

Changes in Scope or Schedule should be managed as part of the Integrated Change Control
process. Refer to ITS Project Management Methodology for additional information.
E. Acknowledgement

Where deliverables require an “acknowledgement”, this means that the acknowledger has
reviewed the deliverables and feels that the documentation and/or Release/Rollout effort was
sufficient. New, Obsolete, Carried-over, and Deferred Modifications will require
acknowledgement, as will all Preliminary Functional Analysis and Software Modification
documents. Refer to ITS Project Management Methodology, “M110 – Log of Project
Deliverables” for additional information.
IV. Assumptions and Risks
A. Assumptions
The following assumptions are critical to the successful accomplishment of this Approach to the
Release/Rollout Analysis Phase:

Technical Environment is configured and available for use prior to beginning Release/Rollout Phase
activities.

Architectural Impacts are known and reviewed prior to beginning Functional & Technical
Release/Rollout Analysis Phase activities.

List of CSR’s will be kept up to date.

“Freeze” deadlines will be committed and adhered to.

Compare Reports will be produced in a timely manner for objects needed.

Methodology templates & processes exist, and Team Members, Reviewers, & Leads are trained in
their use prior to initiating Release/Rollout Analysis Phase.

Realistic levels of availability and commitment are obtained for all resources involved in
Release/Rollout Analysis Phase activities.

Reviewers have availability and commitment to review, respond, and approve deliverables in a
timely manner.

End-User and Business Owner buy-in to proposed changes and modifications.
B. Risks

Document1
Technical environment not ready.
2/9/2016
Page 4 of 5
University of Michigan Information and Technology Services
System Development Life Cycle (SDLC)
S7000A – Release/Rollout Approach Document

Architectural impacts not known and planned for.

Team members not trained in use of Methodology.

Inadequate commitment and/or allocation of team members’ effort.

Insufficient or not agreed-upon Scope definition.

Different levels of PeopleSoft versions implemented.

Changes to Vanilla underlying PeopleSoft structure (data, values), and their impact, will not be
discovered initially.

Impacts between teams and/or users due to Modifications or changes proposed will not be
communicated and tracked effectively.

Inventories of existing online objects, reports, batch jobs not current and up-to-date.

Compare reports unavailable when needed.

“Freeze” dates not committed to or adhered to.

CSR list not kept current.
V. Deliverables
Refer to ITS Project Management Methodology, specifically “M110 – Log of Project Deliverables” for
additional information.
Document1
2/9/2016
Page 5 of 5