Information and Technology Services
PeopleSoft Upgrade Project
M3000A - Design Phase Approach Document
PS Upgrade Design Phase Approach
I. Introduction
This Design Phase Approach Document was created for University of Information and Technology
Services’ (ITS) upgrades to the PeopleSoft application. The document contains an overview of the
Design Phase activities to be performed when an Upgrade or Enhancement is made, or when a
Modification is added to or removed from a Business Process. The emphasis is on providing a
roadmap for predefined Design activities while mitigating risks, minimizing scope creep, and
maximizing customer expectations. Decisions made in the Design Phase will also affect timing and
content of downstream phases such as Development/Unit Test, System Testing, and Rollout.
Cross-team communication and review of designs are key to making this phase a successful
endeavor. Cross-team groups providing input and/or producing deliverables or services in the
Design phase include IS/AIG, System Support, Access Services, Security, Data Administration, Data
Delivery, User Services, and Performance Support.
A. Purpose of Design Phase
The intent of the Design Phase is to provide a comprehensive set of artifacts (Detailed Designs) that
describe the functional and technical aspects of a “Michigan Modification” which is to be applied to
1) existing non-PeopleSoft code, and/or 2) non-delivered PeopleSoft Business Process functionality
that is needed, and/or 3) delivered PeopleSoft functionality which is not needed by The University.
The goal is to ultimately reduce the number of Michigan Modifications needed for an Upgrade or
Enhancement. The result would be reduced delivery times and effort needed for maintenance
activities during this and any subsequent PeopleSoft Upgrades or Enhancements.
The Design Phase is preceded by the Fit/Gap Analysis Phase, that which determines: 1) which prior
implemented Michigan Modifications can be retired due to newly added PeopleSoft functionality or
Obsoleted University Business Processes, 2) New Michigan Modifications which may be needed due
to reduced PeopleSoft functionality or need for additional University functionality that is not
delivered with PeopleSoft, and 3) those Michigan Modifications which will be carried forward from
the previous PeopleSoft upgrade.
For each newly identified or carried-over Michigan Modification, both a “Preliminary Functional
Analysis” and a “Software Modification Business Document” was produced in the preceding Fit/Gap
Analysis phase that generally describes the functional and technical highlights needed. Design
Phase activities will use these documents to further refine the functional and technical requirements
in order to produce a final Detailed Design, which will then be passed along to Developers in the
subsequent Develop/Unit Test Phase.
Detailed Designs are used as input to cross-team groups as well, and the content, quality, and
timing may possibly have an impact on the following groups and their associated deliverables: Data
Administration, Data Delivery, Security, User Services and Performance Support groups.
Document1
Page 1
of 5
2/6/16
Information and Technology Services
PeopleSoft Upgrade Project
M3000A - Design Phase Approach Document
II. Design Phase Approach
A. Design Phase Approach Description
The general methodology/approach for the PeopleSoft Upgrade Design Phase at ITS is described in
the following steps:
1. Work with IS/AIG to validate the Environment & Infrastructure that will be used.
a. Confirm the Application Architecture to be used for Design Phase.
i. Review Impact on Application Architecture.
o Review IS/AIG Application Architecture Impact Statement.
ii. Review Application Architecture Changes.
o Review IS/AIG Application Architecture Acknowledgement document.
b. Validate the Design Phase Environment (MICH, DEMO, DEV environments)
i. Work with Security group to prepare Design Phase Environment Security.
ii. Validate Design Environment.
o Review Design Environment Checklist.
iii. Validate Design Phase Project Support Tools.
o Review Design Phase Project Support Tools Checklist.
2. Begin Functional Design activities.
a. Review As-Is and Proposed Functionality.
b. Begin Functional portion of Detailed Designs.
c. Perform Functional Design Confirmation.
i. Review Proposed Functionality w/Customer
ii. Prepare Prototype (Layout Mockup) Sessions (if needed)
o Prepare User Scripts
o Prepare User Data
iii. Perform Prototype (Layout Mockup) Sessions (if needed)
iv. Document Functionality Changes (if needed)
o Update Preliminary Functional Analysis Document
o Update Modifications Documents
o Update Detailed Design Documents
o Update the “Upgrade Changes DB”.
3. Begin Technical Design activities.
a. Review Technical Information.
i. Review Compare Reports
ii. Review/Update Existing Inventories
o
Interfaces
o
Reports
o
Batch Jobs
o Data Warehouse Tables, Records, Fields
b. Begin Technical portion of Detailed Designs.
i. Refine Detailed Design Documents
ii. Description of Modifications
o Online Objects (Views, Pages, Components, Records, etc.)
o Batch Objects (SQR, Cobol)
o Interface Objects (SQR, Cobol, App Engine)
o Report Objects (SQR, Cobol, Crystal, Query)
Document1
Page 2
of 5
2/6/16
Information and Technology Services
PeopleSoft Upgrade Project
M3000A - Design Phase Approach Document
o Data Warehouse Objects (Tables, Records, Fields)
o Security
o Systems
iii. Define Suggested Test Approach
c. Perform Technical Design Confirmation.
i. Design Team Review.
ii. Cross-Team Review (Security, Performance Support, User Svcs, Access Svcs, IS/AIG,
etc.)
iii. Customer Review/Acknowledgement
o Update the “Upgrade Changes DB”.
4. Conduct Formal Reviews.
a. Prepare Design Phase Review.
b. Receive Design Owner Approvals.
c. Conduct Approval Session w/Upgrade Director.
d. Cross-Project Walkthrough (if needed).
e. Review New Designs with Affected Groups.
f. Update Project Management Deliverables (if needed).
III. Status and Reporting Metrics
A. Error/Defect Tracking Approach
During the Design Phase, errors/defects in Fit/Gap Analysis deliverables and/or Detailed Designs will
be logged into the Lotus Notes Issues database. The database will provide the necessary
information for the designers and others as well as provide management with reports. The
designers need the name of the reviewer, date discovered, the requirements, and any other
relevant information.
B. Design Phase Tracking Approach – Metrics To Utilize
The Design activities will be tracked by Business Process and within each Business Process the
Modification by Objects. Leads will be responsible for ensuring that time is entered into Planview
and all stats are reported to the Design Phase lead in a timely manner. There may be additional
reporting requirements, and the CPU’s may have additional detailed reports needed.
Metrics that will be tracked include but are not limited to:
1. Number of Detailed Designs, by priority (A,B,C), that are in progress, in error, in review, approved,
deferred, or not started.
2. Percentage of Detailed Designs, by priority (A,B,C), that are in progress, in error, in review, approved,
deferred, or not started.
3. Percentage of Effort Completed.
4. Percentage of Effort Earned (Earned Value).
5. Percentage of Effort Remaining.
Document1
Page 3
of 5
2/6/16
Information and Technology Services
PeopleSoft Upgrade Project
M3000A - Design Phase Approach Document
C. Design Phase Status/Issues Meeting
During Design Phase, it is recommended that a weekly status meeting be held at the same
scheduled time on the same day each week. This meeting will support a communication process to
inform the project team on Project Status, Issues, Risks, and Changes. The Agenda will include a
review of open high and medium issues, the overall Design Phase schedule, and any action items
from the previous week.
Meeting minutes should be taken that include a list of attendees, discussion points, and action
items. Designers, Tech. Leads, Reviewers, and cross-team members should be represented in the
meeting. Lessons Learned should be identified and reviewed. Changes in Scope or Schedule should
be managed as part of the Integrated Change Control process.
D. Acknowledgement of Deliverables
Where deliverables require an “acknowledgement”, this means that the acknowledger has reviewed
the artifact(s) and feels that the documentation and or design effort was sufficient. Detailed
Designs will require acknowledgement.
IV. Assumptions and Risks for The Design Phase Approach
A. Assumptions for Design Phase Approach
The following assumptions are critical to the successful accomplishment of this Approach to the
Design Phase for PS Upgrade:
1. Technical Environment is configured and available for use prior to beginning Functional &
Technical Design Phase activities.
2. Architectural Impacts are known and reviewed prior to beginning Functional & Technical Design
Phase activities.
3. New, Obsolete, or Carried-Forward Modifications are identified prior to Design Phase.
4. New, Obsolete, or Carried-Forward Business Modification and Preliminary Functional Analysis
documents exist for each Modification proposed.
5. Compare Reports exist for objects needed in Modifications.
6. Methodology templates & processes exist and Designer, Reviewers, & Leads are trained in their
use prior to initiating Design Phase.
7. Realistic levels of availability and commitment are obtained for all resources involved in Design
Phase activities.
8. Reviewers have availability and commitment to review, respond, and approve deliverables in a
timely manner.
Document1
Page 4
of 5
2/6/16
Information and Technology Services
PeopleSoft Upgrade Project
M3000A - Design Phase Approach Document
B. Risks for Design Phase Approach

Technical environment not ready.

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.

Inadequate Preliminary Functional Analysis or Business Mods documents.

Different levels of PeopleSoft versions implemented.

Late Soft Freeze for Production Systems.
V. Deliverables
A. Deliverables From Design Phase Lead and Methodology Team
The following deliverables are required:

Updated Design Phase Process Flows - if needed

Updated Design Phase Approach Document

Updated Design Phase Templates - if needed

Updated Key Contacts List

Updated Metrics/Tracking Reports

Updated Status Reports & Meeting Minutes

Work Breakdown Structure (WBS) - updated business processes and adjusted hours. This is required
at the beginning of the Design Phase, in order to put the WBS into Planview as a Schedule for tracking
and reporting.
B. Deliverables From Design Phase

The following deliverables are required from each phase for it to be considered completed:

Detailed Design Modifications – Based on Detailed Design Modification Templates. For each newly
identified or carried-over Michigan Modification, a “Detailed Design Modification” is produced which
describes the functional and technical highlights needed. This document will also describe a Unit Test
Plan and Unit Test Plan Data. The document will be passed along to Developers in the Develop/Unit
Test Phase.

Application Architecture Impact Statement & Approval (IS/AIG).

Environment Evaluation & Support Tools Validation Checklists (IS/AIG).

Design Phase Status and Tracking changes to the Upgrade Changes Database.

Updated existing inventories of Reports, Batch Jobs, etc

Acknowledgement of deliverables.
Document1
Page 5
of 5
2/6/16