UNIVERSITY OF MARYLAND BALTIMORE OUNTY STUDENT ...

PPRROOJJEECCTT CCHHAARRTTEERR

UUNNIIVVEERRSSIITTYY OOFF MMAARRYYLLAANNDD,, BBAALLTTIIMMOORREE CCOOUUNNTTYY SSTTUUDDEENNTT AADDMMIINNIISSTTRRAATTIIOONN PPRROOJJEECCTT

Michael Büsges (UMBC)

Joey Harpst (Io Consulting)

Student Administration Implementation Project Charter

Student Administration Implementation

Project Charter

T A B L E O F C O N T E N T S

Table of Contents .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Executive Summary .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Purpose of the Project Charter ...............................................................................................................3 Project Goals...........................................................................................................................................3 Scope ......................................................................................................................................................3 Timeline...................................................................................................................................................4 Approach.................................................................................................................................................4

Foundation .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Purpose...................................................................................................................................................6 Goals and Objectives ..............................................................................................................................6 Assumptions............................................................................................................................................8

Project Structure .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Organization and Staffing .....................................................................................................................10 Project Roles and Responsibilities........................................................................................................11

Project Management and Control ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Project Scope........................................................................................................................................17 Specific Items Excluded from the Initial Project Scope.........................................................................19 Governance Structure ...........................................................................................................................20 Escalation Procedures ..........................................................................................................................24 Project Management Procedures .........................................................................................................25

Project Strategies .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Communication and Training Plan........................................................................................................28 Interface Strategy..................................................................................................................................34 Data Conversion Strategy.....................................................................................................................36 Software Modification and Development Strategy................................................................................40 Reporting Strategy ................................................................................................................................44 Testing Strategy ....................................................................................................................................50 Security Strategy...................................................................................................................................53 End User Training Strategy...................................................................................................................56

Project Charter Approval ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Appendices .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Appendix A - SA Project Resources .....................................................................................................58 Appendix B – Project Templates...........................................................................................................61 Appendix C - Document Management..................................................................................................62 Appendix D – SA Interface Inventory....................................................................................................65


- 3 -

E X E C U T I V E S U M M A R Y Purpose of the Project Charter

The Project Charter articulates the major goals and objectives of the Student Administration Project in implementing PeopleSoft’s Campus Solutions software version 9.0 at UMBC. The Charter proposes the scope of the implementation and describes the strategies and standards that will be used in reaching those goals. This includes how the project will be organized, staffed, and managed; the tools and templates that will be used; and the standards that will be applied. The Project Charter is conceived as a dynamic document that will be amended to throughout the course of the implementation. It is intended to help focus understanding, document progress, and facilitate accountability.

Project Goals UMBC has identified the following goals for the new student administration system:

Provide new or improved functionality to support students’ academic progress and success, provide enhanced self-service access for students and faculty, and meet institutional enrollment objectives

Consistently apply academic rules and regulations while managing exceptions in a secure and verifiable manner

Reduce duplicative data entry and data maintenance Improve the quality and availability of data for strategic decision-making as

well as operational needs Provide a reliable, maintainable, and secure system

In addition, UMBC has identified the following success factors for the SA Project: Complete the project on time and within budget Refine and streamline business processes to improve efficiency and

effectiveness Utilize as much of the new system’s delivered functionality as possible; focus

on business process change whenever possible to avoid modifying the delivered system.

Utilize iStrategy as much as possible to deliver strategic reporting needs. Engage key stakeholders in meaningful and efficient manner Provide on-going communication and support for change management

throughout the implementation Provide effective, targeted training to support the implementation Provide for on-going support and development of the system

Scope The scope of the SA Project includes the implementation of all modules of PeopleSoft Campus Solutions with the exception of Recruitment which is already in production. A complete list of the modules to be implemented is included in the Project Scope section of this charter. In addition, the SA Project will include interfaces to other software applications that will share data with the student administration system, conversion of


- 4 -

selected student administration data from the legacy system, custom reports and limited modifications to the delivered application. The goal of the project’s initial implementation is to support a complete student life cycle in PeopleSoft’s Campus Solutions version 9.0, from recruitment to admission, enrollment, awarding of financial aid, and billing, through grading and graduation.

Timeline The Project will begin on September 17, 2007 and run through the end of 2009. The system will be deployed in phases, according to the timeline below:

Approach UMBC’s approach will be to minimize as far as possible significant changes to the software or “customizations.” Whenever possible, the institution will change business processes, if the delivered software does not support current procedures. Transfer of


- 5 -

knowledge and the development of internal UMBC expertise will be emphasized. A cross-functional approach will be employed in an effort to avoid functional “silos.” UMBC will partner with a Io Consulting in a collaborative approach that will combine the partner’s implementation methodology and expertise in PeopleSoft with the knowledge and expertise of key technical and functional staff in UMBC’s current information systems and business processes. The SA Project team will work together to adapt the PeopleSoft Campus Solutions application to fit UMBC’s business processes, while at the same time adapting UMBC’s business processes wherever feasible to optimize the delivered capabilities of the software.


- 6 -

F O U N D A T I O N Purpose

The University of Maryland, Baltimore County (UMBC) is implementing PeopleSoft’s Campus Solutions (CS) version 9.0 enterprise software. The objective of this implementation is to replace existing administrative systems with technology that supports a growing and changing campus and provides extensive web-based, self-service functionality for faculty and students. The purpose of this Project Charter is to provide direction and set forth guidelines and standards for the implementation of the PeopleSoft Campus Solutions system at UMBC. The Project Charter provides the major goals and objectives, strategies, and standards for this project. It documents how the project will be organized, staffed, and managed; the tools and templates that will be used; and the standards that will be applied. The Project Charter is a dynamic document that will be updated and amended throughout the course of the implementation. The Project Charter will be used both to guide and evaluate the implementation. Successful implementation depends on the project team, the consulting implementation partner, and the larger campus community; the Project Charter speaks to the roles and responsibilities of each.

Goals and Objectives UMBC has been using its current student administration software to run the many business functions of the University for approximately twenty years. The legacy system has limitations and does not lend itself well to expansions. In a changing academic and business environment, UMBC requires more flexibility in its student administration system.

Goals and Objectives for the Campus Solutions System 1. Provide new or improved functionality to support students’ academic progress

and success, provide enhanced self-service access for students and faculty, and meet institutional enrollment objectives

The system will provide students online access to information regarding application and admission status; enrollment and grades; progress toward degrees; financial aid status; billing and financial obligations; academic requirements; class availability; and transcripts.

The system will allow students to conduct business online, including application for admissions, enrollment, application for financial aid, bill payment, application for graduation, and transcript requests.

The system will provide faculty appropriate and ready access to key student academic information, course lists and enrollment data, and online processing of grades.

2. Consistently apply academic rules and regulations while providing for managing exceptions in a secure and verifiable manner

The system will support the enforcement of academic actions, repeat policies, pre-requisites, and other rules and regulations.


- 7 -

The system will support automated degree audits while providing the ability to grant and manage individual exceptions.

3. Reduce duplicative data entry and data maintenance

All modules of the SA system share a common database of biographical and demographical data.

Upon integration in version 9.0, HR and SA systems will share a common biographical and demographical database.

4. Provide an acceptable level of service with the initial implementation that will meet the overall needs of the University.

5. Improve the quality and availability of data for strategic decision-making as well as operational needs

A coherent reporting strategy will inform the deployment of reporting based on users’ roles and needs for information.

Delivered query and reporting functionality and tools will be maximized to meet go-live needs.

Reporting to support decision-making and potential data warehouse solutions will be developed using the iStrategy reporting solution, which is already deployed at UMBC.

6. Provide a reliable, maintainable, and secure system

Delivered functionality will be utilized wherever possible; customizations will be kept to a minimum.

Necessary customizations or software modifications will undergo a rigorous review and approval process. All software development will adhere to defined standards for documentation, testing, and acceptance.

A post-production plan will address security processes and resource needs, patches and fixes, on-going training needs, and other issues.

Measures of Success for the SA Project 1. Complete the project on time and within budget

Careful planning will develop a realistic, milestone-based project plan and project budget.

The implementation will be managed to an established budget and project plan. Well-defined processes for issue resolution will be used to manage scope.

2. Refine and streamline business processes to improve efficiency and effectiveness

During the implementation, business (and academic) processes and practices will be re-examined in light of the available functionalities of the Student Administration system.

Wherever possible, processes will be redesigned to optimize the SA system. 3. Engage key stakeholders in meaningful and efficient manner

Input from key stakeholders will be required throughout the implementation, from design to testing to training.


- 8 -

Wherever possible, existing structures and committees will be utilized for input and communication. Ad hoc groups will be convened as necessary around specific issues.

4. Provide on-going communication and support for change management throughout the implementation

Resources and responsibility for communication and facilitating change will be clearly identified.

5. Provide effective, targeted training to support the implementation

A detailed training plan will identify resources and responsibilities for developing and delivering training.

The PeopleSoft UPK tool will be used as a tool for delivering the training. Training will be targeted to specific audiences and specific needs; training will

be readily accessible. The training plan will address on-going support beyond “go-live” of the

system. 6. Provide for on-going support and development of the system

Post-production support needs will be identified and planned for. Maintenance of the system (patches and fixes, security, data management,

etc.) will be planned for.

Assumptions At the outset, planning for the SA implementation is based on the following key assumptions:

Adequate funding will be available in a timely manner to support the project. Scope and timeline are directly affected by budget. Initial implementation plans include a detailed multi-year budget.

Adequate staffing will be made available to the project. A project goal is to maximize institutional capability and minimize dependence on consultants. Identifying and designating appropriate staff for the project is crucial to its success. Project plans assume adequate UMBC staffing and comparatively minimal consultant staffing.

Appropriate hardware environments will be available at each stage of the project.

Prototyping and development will take place in a copy of the Recruitment 9.0 instance which went into production in August 2007.

The Contributor Relations module is not included in the project’s scope. Graduate Admissions will require the use of a Document Imaging solution as

part of the initial application deployment. A version 9.0 database environment combining HR and Recruitment will be

available in March of 08. Appropriate space for project activities will be available. All modules of Student Administration will be deployed in a combined HR/SA

environment.


- 9 -

Successful implementation of Oracle’s PeopleSoft Student Administration system is a top priority of the University. Full and timely participation from all involved, both directly and indirectly, is essential.


- 10 -

P R O J E C T S T R U C T U R E Organization and Staffing

The following chart provides an overview of the organization and reporting structure of the SA Project Team:

Executive SponsorDr. Arthur Johnson

Project DirectorMichael Büsges

UG AdmissionsRalph Caretti

Student Records/Advising

Pam McInnisDave Hollander

(PT)

Financial AidMolly Burdusi

Student FinancialsShubhashish

Dudda

Institutional Research

Robert Williams

Admissions/CC Consultant

Darin Gordan

Records/AS Consultant

Robert Jordan

Financial Aid Consultant

TBD

Student Financials ConsultantMike Fabry

Advising ConsultantVickie Phillips

Consultant Project Manager

Joey Harpst

Admissions/Records

Cheri PutroDina Caddeo

System IntegrationKevin Joseph

Financial AidPatrick Simon

Consultant Technical PMTracy Barnes

Technical Lead Arnold Foelster

Student FinancialsBetty Blanchette

Database Administration

Conversion Tech ConsultantSiri Flocke

Project CoordinatorMolly Burdusi

Training Coordinator

Susan Dawson

Training AssistantTBD

UMBCStudent Administration

Project Structure

CPSDoug Kendzierski

(PT)Steve Harris (PT)

Graduate SchoolRachel Rachlinski

Betty Douglass (PT)

Technical Consultant

Technical Consultant

Functional Team Technical Team

myUMBC Portal Network/Architecture Project Website/

Communication

Academic Concerns

Dr. Gust Mitchel (PT)l

OIT Support

Project AssistantDenise Van (PT)

One of the goals of the project team structure is to maximize the development of expertise with UMBC staff and minimize the reliance on consultants. A cross-functional team has been identified and brought together at the outset of the planning process and will remain as a team throughout the duration of the implementation. The goal is not just to insure the transfer of knowledge from consultants to UMBC staff, as well as among UMBC staff, but also to encourage a broader perspective throughout the implementation and to eliminate “silos.”


- 11 -

Effective communications are critical to effecting change. Similarly, training is critical to the success of the SA implementation. Dedicated resources for developing training strategies and deliverables are also included in the project staffing plan. These resources will also be instrumental during the early phases in documentation and process change.

Project Roles and Responsibilities

Following are descriptions of project roles. Some of these roles may be shared and the responsibilities assumed by more than one individual. In other cases, one person may assume more than one role. An important factor in the quality and effectiveness of the project is to ensure that all of the responsibilities are assigned to the appropriate individual(s).

Executive Project Sponsor

The Executive Project Sponsor ensures that project solutions are in line with UMBC’s overall strategies for Student Administration, and is responsible for project advocacy with senior constituents within the organization.

Project Director

The Project Director is responsible for project coordination and communication while staying within the parameters of the budget and timetable. The Project Director is responsible for managing the University activities on the project. This individual is the primary point of contact for the Io Managers and is responsible for resolving internal issues within the agreed upon timeframes.

Responsibilities • Monitors project progress and the quality of deliverables on an on-going

basis. • Identifies and manages project risks. • Monitors project scope and expectations. • Provides project direction, organization, resource alignment, and

allocation • Coordinates project work plan and activities. • Leads Project Team status meetings • Reviews and approves deliverables. • Ensures consistency of activities and deliverables across teams • Ensures timely and adequate communication to the:

Project Team Other Members of the University Community

• Manages project priorities • Monitors project schedule and milestones. • Identifies resource needs. • Collaborates regularly and consistently with Io Project Manager


- 12 -

Io Project Manager

The Io On-Site Project Manager is responsible for following the Io implementation methodology and for completing project deliverables in accordance with the contract provisions and the Project Charter document. The Io Project Manager works closely with the UMBC Project Director to communicate project progress, identify and resolve key issues, and carefully manage and control the scope of the project.

Responsibilities • Supervises Io consulting team • Develops and maintains the project plan in collaboration with UMBC and

Io experts assigned to the project • Monitors project progress. • Reports on project status to the University and Io management • Establishes project controls that ensure the quality of project deliverables

and minimize disruption to the project schedule including: Change Control Quality Assurance Risk Management Issue Management

• Provides PeopleSoft knowledge and expertise to the client and to the Project Team

• Manages the project in accordance with Io implementation methodology • Ensures that the client accepts all deliverables and that the appropriate

sign-offs are obtained. • Monitors high-level project status

Io Account Manager

The Io Account Manager provides leadership and quality assurance for the project and functions as the primary Io contact for accounting and personnel issues. The Account Manager works closely with the Io Project Manager to ensure that project deliverables are completed and accepted in accordance with contract provisions and the Project Charter document.

Responsibilities • Evaluates the integrity of the project scope • Performs periodic quality assessments • Provides assistance with issue resolution • Assists Io Project Manger with managing the staffing and scheduling of Io

personnel • Resolves billing and contract issues


- 13 -

Io Functional Consultants

The primary role of the Io functional consultants is to provide functional expertise in both PeopleSoft and industry-specific areas.

Responsibilities • Works with UMBC Team Leads to best ensure knowledge transfer. • Conduct Functionality Review Sessions. • Assists in resolving gaps, whenever possible, by recommending work-

arounds, process improvements, customizations, or modifications • Provides leadership and support with setting up system tables • Provides leadership and support with security setup for PeopleSoft system • Provides leadership and support with testing the PeopleSoft system

during modeling and system acceptance to ensure that University requirements are met

• Provides leadership for data identification for conversion activities • Reports on project status, progress, and issues to the appropriate team

lead and Io Project Manager in a timely manner • Provides functional guidance and leadership to the Project Team • Provides options for issue resolution and identifies business process

improvement opportunities. • Develops test scripts and supervises functional testing.

Io Technical Consultants

The primary role of the Io technical consultant is to provide technical expertise in both PeopleSoft and application areas.

Responsibilities • Provides technical guidance to the Project Team • Transfers knowledge to appropriate University personnel • Assists in resolving gaps whenever possible by recommending work-

arounds, process improvements or modifications • Provides options for issue resolution and identifies business process

improvement opportunities. • Assists with testing the PeopleSoft system during modeling and system

acceptance to ensure that University requirements are met • Designs conversion programs and assists with data mapping. • Designs and conducts initial tests of in-scope interface programs. • Develops and modifies in-scope PeopleSoft reports. • Designs and develops in-scope customizations and modifications to the

system, based on University requirements.


- 14 -

Functional Team Members

The UMBC functional team leads serve as the primary contact for a particular functional area. The team leads works closely with the functional Io experts to lead the implementation of the respective PeopleSoft module(s).

Responsibilities • Ensures work is being completed according to the agreed upon timelines

and deadlines. • Reports progress of team to project management. • Coordinates and facilitate meetings. • Monitors team progress. • Manages identification and resolution of team issues • Reviews and approves team deliverables. • Assures that deliverables meet the business and/or technical

requirements • Ensures that all deliverables are documented, reviewed, and completed

in a timely manner • Coordinates team resources. • Responsible for achieving team milestones • Involves subject matter experts in the project on an as-needed basis • Shares knowledge of the existing system and current policies and

procedures with appropriate University personnel

Technical Team Lead

The UMBC technical team lead serves as the primary contact for all technical related project matters. The team lead is part of the project management team and coordinates all technical tasks and deliverables.

Responsibilities • Ensures all technical work is being completed according to the agreed upon

deadlines. • Reports progress of technical team to the rest of the project management team. • Coordinates and facilitates team meetings. • Monitors team progress. • Manages identification and resolution of team issues. • Reviews and approves team deliverables. • Assures that deliverables meet the technical and business requirements. • Ensures all deliverables are documented, reviewed, and completed in a timely

manner. • Coordinates team resources. • Responsible for achieving team milestones. • Responsible for coordinating all Technical activities performed by the DBA,

Network, and Architecture Teams. • Works with the appropriate resources to assure necessary hardware and

software to support implementation is available.


- 15 -

• Works with UMBC training coordinator to develop training plan for technical staff.

Technical Team Member UMBC Technical team members perform as project team members and as subject matter experts and are assigned tasks to include conversion and system set-up planning, analysis of input from the functional staff for the development and execution of technical specifications and requirements (including report design and programming), conversion planning, data extractions/transfers necessary to complete conversion, and data administration.

Responsibilities • Knowledge of end user needs. • Knowledge of technical processes and procedures. • Communication of technical needs and gaps to Technical Team Lead. • Examine technical processes for improvement opportunities. • Aid in and carry out testing. • Assist with data conversion/interfaces. • Aid in report development. • Assist in building and reviewing prototypes.

Application Specialists

Application specialists participate as project team members and as subject matter experts.

Responsibilities • Has knowledge of end user needs. • Has knowledge of business processes & procedures. • Has knowledge of management expectations. • Communicates of business needs and gaps to team leads • Examines business processes for improvement opportunities. • Aids in and carries out testing. • Assists with data conversion/interfaces • Assists in training • Aids in report definition • Assists in building & reviewing prototypes

Database Administrator

Ensures database integrity and that data is available for retrieval.

Responsibilities include: • Sets up databases as needed by the Project Team • Develops and implements database backup and recovery procedures. • Monitors and tunes the performance of databases, as needed. • Reports status, progress, and issues to team leads in a timely manner.


- 16 -

• Coordinates conversion activities • Maintains database security • Performs database capacity analysis • Responsible for monitoring version control between database instances


- 17 -

P R O J E C T M A N A G E M E N T A N D C O N T R O L Project Scope

The following section defines the scope for the PeopleSoft Student Administration project. Scope management will be a major task during this implementation in order to ensure an on- time and on-budget implementation. Any changes in the defined scope of this project could potentially cause an increase in cost and extension of the project timeline. The scope of the SA Project has been defined as outlined in the table below. The scope of the SA Project will be further refined during the Functionality Review and prototyping tasks. Any expansion of the scope will have to be approved by the Executive Committee. Project Scope Scope Category Preliminary Scope Specifics

(Scope will be further refined during Functionality Review and Prototyping)

Version PeopleSoft Student Administration version 9.0, including web-based self-service features

SA Modules Campus Community Admissions Student Records Financial Aid Student Financials Academic Advising Self Service

Interfaces Interface Number/Name Purpose Residential Life

RLBM4319 Upload of student room assignments from ORL PC based System

RLBR4334 DIEBOLD Meal Plan Undergraduate - Recruiting And Admissions Recruit Download

UABR1669 and Oracle Shadow Extracts Mailing Download Applications Test scores are scanned in fsaAtlas* SEVIS Interface Records And Registration

AXBR4548, AXBR4549, AXBR4550, AXBR4551, AXBR4552, AXBR4553, AXBR4554, AXBR4555 NCAA and Board of Regents Reporting RDBR2060, RDBR2061 Health Service Data Degree Navigation

NCATE - Tracking Academic progress of Education Students

RDBR2034 College Park Electronic Transcripts


- 18 -

Project Scope Scope Category Preliminary Scope Specifics


TCBM2231 for upload to SIS R-25 (Scheduling Software)

AXBM4557 Health Service Immunization Status update to SIS

Student Financials

MVBR4008, MVBM4009 Create MVA Tape for TAG Info and process returned Tape from MVA

ARBR4458, etc. Sallie Mae - Credit Card Payments towards this agency

RNBR2635 1098T ARBM4442 Budget Payment Plan Graduate - Recruiting And Admissions Grad student application Institutional Advancement NABR2804, NABR2806 Alumni Information Institutional Research IRBR3001 thru IRBR3021 MHEC Reporting IRBR3034 thru IRBR3050 SOARS Reporting

Conversions Module Data Category SR Course Catalog SR Schedule of Classes AD Test Scores CC Bio/Demo Data CC Emergency Contact CC Athletic Participation CC Immunizations SR Career/Program/Plan FA Checklists AA Transfer Rules SR Enrollment AA Test Rules AA Transfer Credit AA Test Credit AA Other Credit FA Awards FA SAP SR Instructor/Advisor CC Residency CC Service Indicators SF Open Accounts CC Honors and Awards SR Comments SR Degrees/Transcript Notes AD Admission Applications SR Academic Standing


- 19 -

Project Scope Scope Category Preliminary Scope Specifics


3rd Party Applications iStrategy (iStrategy will be an major component of the

Reporting Solution, particularly with the Strategic Reports. The full scope of iStrategy in reporting will not be finalized until the Functionality Review sessions are complete.)

Document Imaging (DI is required for Graduate Admissions however the specific application has not been selected. UMBC is exploring options to procure Perceptive Software’s ImageNow.

* The Interface to FSA Atlas is unknown at this time. PeopleSoft SEVIS will be reviewed as a possible solution and if chosen would make the interface unnecessary.

Specific Items Excluded from the Initial Project Scope • Health & Immunization Tracking • Faculty Workload

However both to these items will be further reviewed and assessed in the Functionality Reviews.


- 20 -

Governance Structure The following chart provides an overview of the decision process and governance structure of the SA Project:

Consultative Committees

UMBC SAProject Governance

Executive SA Steering Group

Executive Committee Enrollment Services

Project Team Communities of Interest:

Chairs’ MeetingAcademic Affairs DirectorsRetention CommitteeIT Steering CommitteeR25 CommitteeScheduling Advisory BoardEnrollment Management DirectorsEnrollment Services Working Group

Student Financial Services

Project Management Team

Academic Advisory

Communication & Training

Technical Academic Advising

Governance Entities

President’s CouncilFaculty SenateStaff SenatesGraduate CouncilUndergraduate CouncilGraduate Program CoordinatorsUndergraduate Program CoordinatorsSA Advisory CommitteeData Management CouncilGSASGA

HR/SA Integration


- 21 -

The following delineates the committees involved with the decision and governance of the project, the personnel who compromise these committees, and their roles and responsibilities. Decision and Governance Committees Roles and Personnel Responsibilities Executive Committee: Art Johnson (Chair) John Jeffries Geoff Summers Warren DeVries Nancy Young Scott Bass Diane Lee Jack Suess Lynne Schaefer Sheldon Chaplis Nancy Young

Approves project structure, scope, timeline, and budget

Reviews implementation decisions Monitors implementation progress Resolves escalated issues involving

significant policy/process change, scope, budget, or timeline

Executive SA Steering Committee: Michael Busges (Chair) Jack Suess Arnold Foelster Yvette Mozie-Ross Michael Dillon Jill Barr Gust Mitchell Tom Vogler (until 3/31/2008) Valerie Thomas Joey Harpst, ex officio

Reviews decisions made Resolves or escalates referred issues from

Project Team or Project Management Team Escalates unresolved issues or issues

involving scope, budget, or timeline to Executive Committee; provides recommendations where possible

Reviews business process changes recommended by the SA Project Team to ascertain if organizational changes are warranted

Provides executive level support to the SA Project Team to remove obstacles to the project’s success

Continuously supports the high priority status of Project

Coordinates the timely resolution of policy-related issues

Provides guidance for Project communications

Monitors Project progress Balances competing interests and agendas

Project Management Committee: Michael Büsges (Chair) Arnold Foelster Joey Harpst, ex officio Tracy Barnes, ex officio Ben Santelman, ex officio

Reviews and resolves issues internal to project

Resolves issues that do not cross functional areas, have university-wide impact, require staffing or reorganization, or affect budget, scope, or timeline

Escalates other issues to Steering Committee with recommendations, options, and impacts.

Communication & Training Consultative Committee

Jack Suess, Chair Michael Busges

Develops and approves Change Management activities for the entire campus

Consults with the Executive Steering committee on change management


- 22 -

Decision and Governance Committees Roles and Personnel Responsibilities Eleanor Lewis Lee Hawthorne Calizo Yvette Mozie-Ross Susan Dawson Gust Mitchell 1 Faculty Member (from Academic Advisory

Committee) 1 Graduate Student Jennifer Kent (UG Student)

activities. Advocates appropriate resource allocation

for change management activities. Monitors success of change management

activities. Serves as link to consulting partner

executive management for communication.

Academic Advising Consultative Committee: Ken Baron, Chair Jill Randles Michael Busges Pam Hawley Lydia Jackson-Fryer Catherine Bielawski 1 Faculty Member (from Academic Advisory

Committee) 1 Undergraduate Student

Advises project team, project management team, and executive steering committee on issues related to student advising.

Ensures that implemented advising functionality complies with campus advising philosophy.

Advises on development and deployment of degree audit.

Advocates changes in administrative practices necessitated by Student Administration.

Enrollment Services Consultative Committee: Yvette Mozie-Ross, Chair Ralph Caretti Pam Hawley Jill Barr Beth Jones Steve Robinson Dave Hollander Dale Bittinger Ryan Bos Stephanie Johnson

Advises project team, project management team, and Executive Steering Committee on issues related to the deployment of the Admissions and Student Records/Registration modules

Advises on development and deployment of Self Service functionality for Admissions and Student Records/Registration modules

Advocates changes in administrative practices necessitated by Student Administration

Student Financial Services Consultative Committee: Jean Bunche, (Co-Chair, as of 1/4/2008) Stephanie Johnson (Co-Chair, as of

1/4/2008) Tom Vogler, Chair (until 3/31/2008) Michael Busges Doug Kendzierski Brian Thompson Molly Burdusi Shuvo Dutta Gayle Chapman

Advises project team, project management team, and Executive Steering Committee on issues related to the deployment of the Student Financials, and Financial Aid modules.

Advises on development and deployment of Self Service functionality for Student Financials and Financial Aid modules

Advocates changes in administrative practices necessitated by Student Administration

Technical Consultative Committee: Joe Kirby, Chair Mike Carlin Arnold Foelster John Fritz Rob Banz Collier Jones

Advises project team, project management team, and Executive Steering Committee on technical issues such as application testing, security, network and application architecture, conversion, and modifications


- 23 -

Decision and Governance Committees Roles and Personnel Responsibilities Michael Glasser Tracy Barnes, ex officio

HR/SA Integration Committee Rochelle Sanders, Chair Jean Bunche Molly Burdusi Michael Busges Lisa Drouillard Shuvo Dutta Arnold Foelster Mike Glasser Vicki Greisman Dave Hollander Beth Jones Stacy Long Pam Hawley Yamiley Saintvil Sonia McLaughlin, ex officio Darin Gordon, ex officio

Ensure that business processes are aligned in combined HR/SA database

Facilitate decisions on shared business processes and data sets

Academic Advisory Consultative Committee: Armstrong, Thomas Berry, Melanie Bielawski, Cathy Blessing, Lonny

(until 2/22/08) Bulger, Michele Burgee, Janet Cuddy, Dennis Farrow, Scott Finkelstein,

Jonathan Fitzpatrick, Carolyn Gethman, Jane Helms, Sally Kreizenbeck, Alan LaCourse, William Lecompte, Susan Lindahl, Lasse McCann, Carole Morgan, Leslie O'Heir, Elaine Redding, Tate Rheingans, Penny Ross, Julie Sauter, Carrie Schwartz, Ana

Maria

Advises project team, project management team, Executive Steering Committee, and Executive Committee on all implementation issues concerning Faculty, Dean’s Offices, and Academic Departments

Serves as liaison to campus shared governance entities and other communities of interest

Advocates project goals to academic constituencies


- 24 -

Decision and Governance Committees Roles and Personnel Responsibilities

Stapleton, Laura Sutphin, Kathy Tice, Carolyn Viancour, Teresa Welsh, Mary Wimpling, Kathleen Worchesky, Terry

Escalation Procedures In order to manage risks and resolve issues, both issues and decisions must be clearly defined and documented. The following procedures will be used throughout the implementation:

Issues logs will be used to capture and monitor all identified project issues and risks. Each issue will be clearly named and concisely defined. Priority will be assessed as high, medium, or low. The issue will be assigned to a responsible party for resolution with an estimated date of completion. When an issue is resolved or a risk mitigated, a description of the resolution, the date of resolution, and where the resolution occurred will be documented in the issues log.

Open and recently resolved issues will be captured in weekly SA Project status reports. A review of these issues will be part of the responsibilities of the Project Team, Project Management Team, SA Executive Steering Committee, and Executive Committee. The Project Director will monitor the status of critical path items.

Timeframes for the resolution of issues will be developed for each level of escalation. Timely resolution to issues will be critical to keeping the SA Project on track and within budget.

Project issues related specifically to the Implementation Partner will be referred to the Consultant Project Manager for resolution. Issues that cannot be resolved will be escalated to the Account Manager for action.


- 25 -

Project Management Procedures The purpose of this section is to provide a general overview of the processes and tools to be used to ensure project performance is regularly measured so that variances are identified and, where appropriate, actions are taken to resolve the variances. The following practices will be deployed throughout the UMBC Campus Solutions implementation project lifecycle to ensure that the project plan is effectively executed and controlled.

Project Plan Management

Maintenance The project plan will be maintained using the Microsoft Project application. This plan encompasses sub-plans for each of the Campus Solutions modules: Campus Community, Admissions, Student Records, Financial Aid, Student Financials and Academic Advisement. Each sub-plan contains a comprehensive list of the required phases, tasks, and milestones for successful execution of the project. The plan identifies estimated begin and end dates for each phase, task, and milestone. As the project evolves, the plan will be updated to reflect percentage complete references for each task, phase, or milestone. The following control processes will be used to ensure that the project plan is regularly updated, monitored and communicated.

Project Plan Availability The Project Management Team only will have the security access to update the project plan, and will do so on a weekly basis. The consultant Project Manager will ensure that a current version of the project plan is available to all members of the SA Project Team on the project shared drive.

Meeting Management

Project Meetings Planning Facilitators will use UMBC’s Corporate Calendar to schedule meetings. For each scheduled meeting, they will create a meeting agenda and post it in the Meeting Minutes and Agendas folder for the project on the shared network drive in advance of the meeting. The agenda will contain, at a minimum, the meeting title, date, time and location, meeting purpose and objectives, and the list of topics to be discussed. The Meeting Agenda Template will be stored under the Approved Project Templates folder for the project on the shared network drive. Agenda files will be posted and archived in the Meeting Minutes and Agendas folder for the Project on the shared network drive using the standard document management and naming conventions described in the Document Management sub-section of the Design and Governance Structure section. Controlling The meeting facilitator is responsible for controlling the meeting. The facilitator will ensure the agenda is reviewed at the beginning of the meeting. The meeting facilitator is also responsible for designating a note taker and ensuring that minutes are appropriately captured throughout the meeting.


- 26 -

Communicating Results Meeting Minutes using the appropriate meeting Minutes Template will be created when appropriate. The minutes will contain, at a minimum, the meeting title, date, time and location, meeting purpose and objectives, a list of attendees, topics discussed, and all identified tasks and issues. The meeting minutes will be saved using the standard naming conventions described in the Document Management sub-section of the Design and Governance Structure section.

Types of Meetings SA Project Meetings Meeting Type Meeting Description Prototyping Sessions Prototyping sessions occur for each respective project module

for the purpose of gathering detailed functional requirements and designing business processes to optimize the capabilities of the system. Io functional consultants are responsible for facilitating these meetings.

Project Status Meetings These meetings are held weekly and are attended by the UMBC and Consultant SA Project Team members. The purpose of these meetings is to discuss project status as it relates to schedule and performance for the project. UMBC Project Director is responsible for facilitating these meetings.

Project Management Team Meetings

These meetings are held weekly and are attended by the Project Director, Io Project Manager, UMBC Technical Lead and the Io Technical Lead. The purpose of the meetings is to review and monitor project progress, address and resolve issues, and prepare for future project events. The Project Director is responsible for facilitating these meetings.

Issue Management/Risk Mitigation Meetings

These meetings occur on an as needed basis to address issues and risks. At a minimum, those project participants required for resolving or mitigating the respective issue or risk must attend these meetings. The Project Director is responsible for facilitating these meetings.

User Review Sessions These meetings occur on an as needed basis so that the proposed system users may review system deliverables and provide open, candid feedback about the performance of the deliverables. Io Functional Leads are responsible for facilitating these meetings.

Code Design Review Sessions

These meetings occur on an as needed basis when initial technical development specifications are ready for review. The UMBC Technical Lead and the Io Technical Lead will schedule a sessions to review the completed technical design specification with the developer assigned the task to determine if the general approach is correct. Other UMBC technical resources may attend. The UMBC Technical Lead is responsible for facilitating these meetings.

Status Reporting The principle vehicles for project reporting will be standard weekly and monthly status reports. Reports for the consulting partner will be developed and submitted by the Project Manager as described below. Once a status report has been reviewed and approved by the UMBC Project Director, it will be posted in the Consultant Status Report


- 27 -

folder in the project directory on the shared network, where it will be available to all SA Project Team members.

Weekly Status Reports Using the standard Weekly Status Report Template, weekly status reports will be submitted jointly as follows:

UMBC Functional Team Members will submit joint status reports to the Project Director with a copy to the Project Manager by the end of each week. The UMBC Functional Team Members will be responsible for posting the status reports on the shared network using standard naming conventions described in the Document Management subsection of the Decision and Governance Structure section.

UMBC Technical staff will submit joint status reports to the UMBC Technical Lead by the end of the week. The UMBC Technical Lead will submit a consolidated Technical status report to the Project Director with a copy to the Project Manager.

Consultants will submit status reports to the Project Manager by the end of each week. The Project Manager will consolidate the status reports from all of the consultants into a single weekly status report that will be submitted to the Project Director by Tuesday of the next week following the week in which the work is performed.

In addition to reporting accomplishments, progress, and issues for their team, these reports will include a summary of the hours worked by each consultant.

Monthly Status Reports Using the standard Executive Dashboard Template, the Project Management Team will jointly submit a monthly status report to the Executive Sponsor. This report will summarize the status of critical target dates and milestones, accomplishments and activities of the past month, and any issues that still need to be resolved.


- 28 -

P R O J E C T S T R A T E G I E S Communication and Training Plan

During the PeopleSoft Finance/HR implementation we learned three important lessons: 1. Communication is critical on a project as complex and challenging as PS – As Dr.

Hrabowski is fond of saying, instead of PeopleSoft it ought to be called PeopleHard!; 2. It is impossible to over-communicate on something as big and complex as PeopleSoft.

When a project touches thousands of people it is impossible for everyone to have the same degree of understanding with the project. As a result, the project must reach out as broadly as possible and use every available tool at our disposal; and

3. Training is the most important component of a communication plan and it is essential to begin training early and let the campus gain confidence that the project will create a training environment that will support the change that comes with SA.

4. Training defines the processes that people use to perform their jobs. It is imperative that the processes that are being training are the processes that the campus embraces. It is important to understand how PeopleSoft SA will impact current business processes, and develop training that will encompass the changes in how people perform their work related to SA.

The purpose of the Communication and Training Plan is to be proactive and reach out to the campus to keep everyone informed about the project, toensure the project team listens to the concerns of the campus community, and to deliver training that teaches the campus not only how to use SA, but how to do their job as it relates to SA.

Communication and Training Goals 1) Provide transparency into the project by communicating effectively with the UMBC

community about the SA project, including its benefits and limitations, features, implementation progress, and impact upon academic programs and priorities.

2) Establish the correct level of end-user expectation and consistently communicate that level of expectation. .

3) Actively inform the UMBC community through multiple communication channels. 4) Provide a vehicle for input, participation and feedback by the campus community in the

configuration and design of the software. 5) Regularly visit campus stakeholder groups to provide updates and answer questions

about the project. 6) Regularly recognize the project and participant accomplishments.

Campus Constituent Groups Campus constituent groups are comprised of those individuals or groups who will be interested in the status of the project because they will be impacted by the implementation of the software. The highest level breakdown of constituent groups is by students, faculty, and staff. Within each of these there are multiple sub-groups to communicate with. Each high-level group has different characteristics that must be addressed in the communication plan. As a consequence, several different communication mediums will be employed to effectively reach each audience.

Students Student communication will be primarily related to self-service and UMBC campus services supported by SA. This will include application information, registration information, grade checking, retrieval of unofficial and advising transcripts, billing, financial aid status, etc. Due to the size of this group communication to students will be primarily electronic. The project will use email, myUMBC spotlights and alerts, and the


- 29 -

SA web site. The student newspaper will also be a medium that can be used to communicate what student expectations should be for SA. It is important that students know the project is coming and be aware of the changes that will occur as a result of SA. The project will work closely with the Office of Student Life to support communication to students and maintain a public website that will be used to inform the students of project status. In addition, there will be student representation on both the Communication and Training and the Advising Consultative Committees. In terms of sub-groups to be identified the project will work closely with the student government association (SGA) and graduate student association (GSA). In addition, the project will seek out the campus newspaper, The Retriever Weekly, for advertisements and updates. One benefit of SA is that the SA implementation follows the student lifecycle. Students entering UMBC in Fall 2009 will begin to interact with SA during the admissions process that occurs during AY 2008-2009. Existing students will begin to interact with SA in Spring 2009 as part of the financial aid process and advance registration. This will follow with self-service schedule adjustment and billing over the summer 2009. The new degree audit will be introduced in Spring 2009 (for General Education) and Fall 2009 (for program specific requirements). One early issue that the Communication and Training team must determine is whether Summer Session 2009 will be handled completely by SA. If so, that requires working closely with CPS to train students and staff on the new processes associated with Summer 2009.

Faculty Unlike student communication, which is focused on how to use SA self-service to handle campus academic services, Faculty communication must occur on multiple levels and will have different goals at different times within the project. During the first year the majority of communication with faculty will be focused and bi-directional. In particular, we will be working with the faculty advisory group on processes, procedures, and policies that will define how the system functions. The goal of the communication plan during this period is to define the issues and opportunities and solicit feedback from the faculty. In many cases there are established constituent groups in place that we can work with. In a few cases we will be asking the academic advisory group to help us create an ad-hoc group of faculty to give feedback. A key responsibility of the project team is to create a shared issue log that will document who has been involved in the decision making process, what options were considered, and the reasoning for why the issue was resolved the way it was. Our goal is to provide as high a level of transparency in the decisions made as we possibly can. Starting in the fall 2008 time-period we will roll out the first admissions application for graduate and undergraduate applications. The graduate admission process is highly decentralized on campus and each department has a graduate program director and graduate program committee to review student applications and select those students to admit. A risk in the project is that UMBC will be changing its document imaging system that is used to manage documents submitted by the applicants. One of the critical communication and training activities will be working closely with the graduate program directors on a plan for training and communication related to the rollout of SA and the new document imaging system. Communication to faculty will involve a mix of electronic and face-to-face activities. In terms of electronic communication, we will establish and use email as much as possible


- 30 -

to solicit faculty involvement and to provide regular updates. In addition, we will keep a web site with the issue log and the status of issues, who was involved in the decision making, and how the decisions were finalized. We will develop a new mailing list named SA-news that we enroll all faculty and staff into and use this for regular email updates that link to more detailed information on the SA web site. The SA web site will use a new campus Wiki that will be designed to allow faculty to track issues and automatically receive email when the issue document is updated. In terms of face-to-face communication we will work with faculty leaders and our executive sponsor, the Provost, to be given the opportunity to speak and different campus meetings where faculty are present. Groups we have identified as key constituent groups are the following – GPD’s, UPD’s, Chairs, Faculty Senate, Faculty Senate Executive Committee, and the dean’s meetings within each respective college. If necessary, we will use the Academic Advisory Committee to facilitate these meetings. In addition, we will meet regularly with the Provost and deans so that they will be up-to-date on the project and can give updates when members of the project are not present. Training for faculty is an important issue and one that the project must take special care to get right. Training for faculty working with the graduate admissions process will begin in late September 2008 and run through Thanksgiving. Training for faculty to support the course advisement and student registration process will begin in January 2009 and run through the end of March 2009. We will plan to offer a mix of face-to-face and self-paced training facilitated by the SA User Productivity Kit (UPK) to support faculty.

Staff Staff communication shares many similarities with faculty communication with two significant differences – one being that it is much easier to schedule training for staff since they tend to maintain regular hours and can more easily block out time for training. The second difference is that staff don’t set academic policies as faculty do. On the other hand, staff tend to have more input on processes and procedures within SA. Like faculty, staff communication must occur on multiple levels and will have different responsibilities at different times within the project. During the first year the majority of communication with staff will be focused and bi-directional. In particular, we will be working with the staff on processes and procedures that will define how the system functions. Subject Matter Experts for various functional areas have been identified, and it is the responsibility of the project team to insure that the right experts are involved with system configuration. The goal of the communication plan during this period is to define the issues and opportunities and solicit feedback from the staff in the design sessions. A key issue is getting the right staff to participate in the design sessions. In many cases the staff involvement will be based on being part of a functional department or being responsible for that task in an academic department. One of the important responsibilities of the SA steering committee is to make certain that at every opportunity they have to communicate with staff they explain what is happening with SA. A key responsibility of the project team is to create a shared issue log that will document who has been involved in the decision making process, what options were considered, and the reasoning for why the issue was resolved the way it was. Our goal is to provide as high a level of transparency in the decisions made as we possibly can. Starting in the fall 2008 time-period we will roll out the first admissions application for graduate and undergraduate applications. The graduate admission process is highly decentralized on campus and each department has a graduate program direction and graduate program committee to review student applications and select those students to


- 31 -

admit. In many departments staff are heavily involved in the process. A risk in the project is that UMBC will be changing our document imaging system that is used to manage documents submitted by the applicants. One of the critical communication and training activities will be working closely with the graduate program directors and their staff on a plan for training and communication related to the rollout of SA and the new document imaging system. Communication to staff will involve a mix of electronic and face-to-face activities. In terms of electronic communication, we will establish and use email as much as possible to solicit staff involvement and to provide regular updates. In addition, we will keep a web site with the issue log and the status of issues, who was involved in the decision making, and how the decisions were finalized. We will develop a new mailing list named SA-news that we enroll all faculty and staff into and use this for regular email updates that link to more detailed information on the SA web site. The SA web site will use a new campus Wiki and be designed to allow staff to track issues and automatically get email when the issue document is updated. In terms of face-to-face communication we will work with each division head and their respective department heads to meet with them on a regular basis to give updates and answer questions. In addition, we believe that it is important to regularly (at least once a semester) update the staff senates. In addition, we will meet regularly with the VP’s and deans so that they will be up-to-date on the project and can give updates when members of the project are not present. Training for staff is an important issue and one that the project must take special care to get right. Training for staff working with the graduate admissions process will begin in late September 2008 and run through Thanksgiving. Training for staff to support the course advisement and student registration process will begin in January 2009 and run through the end of March 2009. We will plan to offer a mix of face-to-face and self-paced training facilitated by the SA User Productivity Kit (UPK) to support faculty. The communication and training committee will work to establish a peer mentor network on campus that staff can use to support each other.

Communication within the Project Team Project Participants Over twenty-five individuals are working full-time on the project. The project team members span at least a half-dozen different offices and five divisions. We want to make certain that everyone on the project is fully informed about what other groups are doing within the project and that the project team members are comfortable communicating project information back to their home department and division. The project management team led by Michael Büsges and including Arnold Foelster and Io Consulting Project Manager Joey Harpst will hold weekly meetings with the full project team to keep them updated. In addition, all communication to faculty and staff will be shared with the complete project team. Members of the project team will be encouraged to meet bi-weekly with their department head and give the department an update on the project. Team members are encouraged to share their weekly status reports with their department head. Within the project it is essential that project team members keep written track of issues, who was involved in resolving the issue, and the reasoning behind the final decision. This level of detail will be put on the web site and will provide the project a level of transparency requested by the campus. In addition, this level of detail is essential in helping the training team work with the right Subject matter experts to develop the training


Student Administration Implementation

Project Charter

The table below summarizes the communication plan: Constituent Group

Information Medium Frequency Responsibility

UMBC Faculty and Staff

• General information

• Meeting minutes

• Team organization

• Reference documents

• Timelines • Training

schedule/Plans • FAQs • High level

status updates

• SA-news email

• Project web site

• Web site is updated weekly with status updates.

• SA-news email is sent out at least monthly with update (more often if needed).

Project Director Training Lead CIO Provost’s Office

Project leadership – UMBC Executive Leadership

Informational briefings on the project progress, milestones, major issues

Meetings with presentation Meeting include: • President’s

Council – Quarterly.

• VP’s and Deans (Monthly)

• Deans (bi-weekly)

Regularly scheduled meetings or as requested

Project Director Provost CIO

Deans, department chairs, academic directors, faculty

Informational briefings on the project progress, milestones, major issues

Provost will update chairs bi-monthly at chairs’ meeting Deans will give monthly update to their chairs. Project Director will come in once a semester to answer question

Quarterly, on milestones, or as requested


Staff department managers/administrative officers/directors

Informational briefings on the project progress, milestones, major issues, feedback sessions, planning sessions

Departmental and divisional meetings. Email and Website, Consultative Committee Meetings

Monthly, on milestones, or as requested

Steering Committee Project Director CIO


of 65

Constituent Group

Information Medium Frequency Responsibility

Faculty groups (UPD’s, GPD’s, Faculty Senate, Graduate and UG Councils, Informal Chairs’ meetings)

Informational briefings on the project progress, milestones, major issues, decisions.

Email and Web site. Face to face at regularly scheduled meetings

As needed – likely to be at least once a semester.


Executive Steering Committee

Status reports for each functional area – prior week accomplishments, planned tasks not yet completed, concerns & issues, following week's task plan, upcoming milestones and deliverables.

Word document via email and saved on project shared directory

Weekly Project Management Io Consulting

Core Team members Details about project issues, decisions, tasks to be completed, timeline, roles, responsibilities, two way communication, system development, fit/gaps, testing Notification of team events,etc.

• Issues Log

• Functionality Review Sessions Analysis, Modification Log and Specifications

• Briefings by function, technical and project management

• Weekly meetings

Ongoing Project Management Io Consulting

Functional Departments

Subject Matter Experts in design sessions

Notification of team events, fit/gap sessions, testing periods. Updates on project status, timeline, roles and responsibilities

• Email

• Web Site

• Consultative Committees

As decisions are made, on milestones, quarterly events

Project Team Members


of 65

Interface Strategy The new student administration application will have to receive and accept data from external sources. These sources include vendors and other government agencies, as well as other departments within the University. Although Student Administration delivers some standard interfaces, some of the delivered interfaces will need to be rewritten to support UMBC’s data in PeopleSoft. The strategy for accommodating UMBC’s interfacing needs is addressed in this section.

Approach Key interfaces will be inventoried for each of the Student Administration modules and new specifications created for each. The inventory’s objectives include identifying interfaces that would become redundant in the new environment and those that need to be retained and modified for the new system. Additionally, the inventory should categorize and prioritize the interfaces that will be needed in the new environment. The required interfaces will vary in content and format. Once the numbers and functions of the interfaces have been determined, decisions will be made as to the most appropriate method for creation. It is key to identify the two main types of interfaces:

External: These interfaces link the student administration system to external applications. These entities may include state, federal, or other 3rd party vendors (e.g. CollegeNet).

Internal: These interfaces link components of the student administration system. These interfaces exist to support the multi-phased roll-out of functionalities and/or modules within PeopleSoft while maintaining the student administration system in production to support other required functionalities (e.g. the GL Interface linking PS Student Financials with Financials).

Resources This section highlights areas OIT needs to prepare for the development of interfaces during the implementation.

Roles and Responsibilities For each interface, the following roles need to be identified before development or configuration can begin. Interface Developer for Legacy System The interface developer for the legacy system is responsible for the following tasks:

Maintain current interface Identify all required data sources, format and delivery mechanism of current interface Assist and advise in the configuration of Student Administration for interface

replacement within PeopleSoft Assist and advise in the development of new interface with PeopleSoft interface

developer Configure and test connectivity for development of new interface Test and sign-off of new interface or PeopleSoft configuration


of 65

SA Project Functional Leads The SA Project functional lead is responsible for the following tasks:

Understand and provide advice on interface relation to Student Administration specific module and functionalities

Assist in configuration of Student Administration Testing of new interface or Student Administration configuration

Interface Developer for the New Student Administration System The Student Administration interface developer is responsible for the following tasks:

Analysis of current interface Creating interface specifications with current interface developer Configure Student Administration for interface replacement Design and development of new interface Assist in testing of new interface or PeopleSoft configuration Documentation for interface maintenance and knowledge transfer

UMBC’s Current Interfaces A listing of the currently known interfaces has been included in Appendix D.

Interface Tools There are a variety of interface tools available. Each interface will be evaluated and an appropriate tool will be utilized to develop it. Some of the possible interface tools that may be used include:

• Application Messaging

• Application Engine

• Component Interface

• SQR

• XML The Io Technical Lead will work with UMBC Technical Team to determine the most appropriate development tool to use for each interface.


of 65

Data Conversion Strategy Data conversion activities are often among the greatest challenges of an implementation project. Irregularities in legacy data must be rectified, or the results can have a severe impact on business functionality. At the initial writing of this Charter, UMBC has already undertaken a number of initial data conversion activities. Io will come along side UMBC to complete the detailed conversion plan. That plan should establish the objectives and criteria for the conversion effort and identifies specific data and database sources to be converted based on these criteria. Data quality standards also should be included in the Data Conversion Plan. Going forward, UMBC will continue to use a formal data conversion strategy that includes the following major components:

Conversion planning Data analysis and mapping Conversion programming Data quality edits in conversion programs Conversion migration path Conversion execution and data quality assurance Post conversion clean up

Io will provide a data mapping facilitator to work with the functional users and appropriate technical staff. This data mapping activity results in information that assesses the integrity of the data, identifies policy issues, clarifies and formulates data definitions, and provides a basis for proceeding with the conversion in a logical manner. Furthermore, it ensures that data quality standards will have been met. Only data that is identified by project functional teams as critical to key business processes will be converted into the Student Administration databases. The Project Director, in conjunction with the Functional Directors, will give final approval for conversion scope. Wherever possible, the project team will use Io’s developed data migration scripts for migrating data to the target PeopleSoft database. UMBC and Io team members will have primary responsibility for extracting and converting legacy data into a PeopleSoft friendly format. UMBC staff will have the responsibility of cleansing the data in the legacy systems.

Data Conversion Process Overview The following diagram shows the iterative conversion process, which moves data from the legacy system to Database tables where data can easily be read by the data conversion programs. The Conversion programs will massage legacy data and load into PeopleSoft or the data will be moved to another staging area where potential data conversion errors can be identified and addressed. Once the data is cleansed, it is validated by the end users for final approval.


of 65

Conversion Scope It is typical to want to convert as much data into the new system as possible. However, it can be counter-productive to convert data just because it exists. Some data may be better served by not being converted or by being transformed into another usable format. Therefore, only data that is critical to key business functionality will be converted. The scope of the data conversion effort is determined by applying this key strategy to three basic questions:

What data will be converted? When will it be converted? What tools or resources will be needed?

What data will be converted? Specific criteria will be established early in the Analysis and Design Phase. As a general rule, data will only be converted if it has been identified by project functional teams as critical to key business processes or to meeting externally imposed regulations. These will be reviewed by functional team members in the context of the prototyping sessions for the various Student Administration modules and the respective business processes that they support. Selected transactional and setup data must be converted. Examples of setup data include:

Course Catalog Schedule of Classes

Examples of transactional data include:

Biographical/Demographic Applications

Staging Area / Oracle

Tables In PeopleSoft

Legacy Summary

Report

Staging Report

Legacy System

PeopleSoft Delivered

Tables

Errors

Data Cleanup

User Validation

Final Report in

PS


of 65

Program Plan Holds Degrees Enrollment History Transfer Credit Account Balances

When will the data be converted? The timing strategy for converting data is based on two key criteria:

When will the converted data be needed in the production database in order to meet the targeted go-live dates, which have been staggered to coincide with the administrative activities and information needs of the academic calendar?

What are the dependencies of each conversion category on other categories? Based on these criteria, a logical conversion scope and sequence will be determined, which will include the following milestones for each conversion category:

When the mapping of a specific conversion category should be complete When the extraction program for this category should be complete When testing of this conversion category should be complete When the data is needed in the production database When the converted data is required in production

Data Conversion Approach The project team will develop a data conversion strategy document that will provide a structured approach to conversion efforts. A high level description of the approach the team expects to follow includes:

Decide which PeopleSoft tables need to be populated Create mapping documents for all tables For each table, identify which data items are needed Identify where each data item will come from Write extract programs, keeping programs small and simple Perform some conditioning in the extract programs Determine a reconciliation process Determine load approach (i.e., component interface, ) Load the data into Student Administration


of 65

Conversion Migration Path The following diagram illustrates a migration path for moving conversion data from one environment to another:

Other Instances?

SACNV Development of

import scripts Create conversion

related objects Unit test conversion

data

Other Instances?

SAPRD Conversion programs will

be re-executed in the production instance.

SACVT Data validation by end users No development occurs in this

instance


of 65

Software Modification and Development Strategy The primary premise for UMBC’s software modification and development strategy is to implement the PeopleSoft student administration software by taking advantage of delivered functionality and minimizing modifications to the delivered software. It is highly recommended that no modifications be made to the delivered COBOL programs except those provided by PeopleSoft through fixes and updates. All modifications will be grouped together in a separate, custom menu structure to minimize system maintenance and upgrade efforts in the future. There are a number of PeopleSoft customizations that are shared by several of the USM institutions. UMBC will leverage the experience of other USM schools that have implemented PeopleSoft student administration and share customizations used by UMBC.

Software Development Standards All software modifications and development during the implementation of the student administration product will be made according to a defined set of development standards, especially regarding naming conventions. Standards are also required for coding and documentation. Adherence to these standards will significantly reduce the efforts required for production support and the efforts required to perform PeopleSoft upgrades in the future. Existing development standards at UMBC will be reviewed and compared to development standards of the consulting partner. The development standards for the project will be created and documented based on the outcome of this review process.

Change Control A method for managing change control will be required during the student administration implementation. Third party tracking products are available for this purpose, such as STAT, which is already licensed by UMBC. Based on auditor recommendations and the maturity of the HRMS and Financials implementations, UMBC wishes to integrate the STAT third party tracking product into the management process of all its PeopleSoft environments, including Campus Solutions. One of the great benefits of a third party product such as STAT is the ability to track all potentially changing application items within one environment, including items commonly referred to as “executables” (COBOLs, , etc). All errors, enhancements, design modifications, PeopleSoft delivered upgrades (including patches and fixes) or other system analysis requests during a PeopleSoft implementation should be tracked. Each request is given a unique change request number to be used for documentation, migration, & upgrade purposes. All modifications made to the system must reference the associated change request number. Approved development changes will have a related Technical Specification. At various points in the project there will be multiple developers working on the system concurrently. In order to prevent issues of developers trying to make changes to objects at the same time, both locking and history for Change Control will be implemented. Each developer will have his or her own UserID and password to work under. No changes will be made under the generic PS UserID.


of 65

Development Terms Development associated with a PeopleSoft system is somewhat unique. In order to have a common understanding, a glossary of development terms has been developed

Software Development Steps The development process described in the table below will be employed whenever changes are made to modify the PeopleSoft student administration application. This sequence helps to ensure valid relationships between defined objects, such as fields, records, pages, components and menus.

Development Process Development Step PeopleTool Step 1: Design the Application None Step 2: Create Field Definitions Application Designer Step 3: Create Record Definitions Application Designer Step 4: Build SQL Objects Application Designer Step 5: Create Page Definitions Application Designer Step 6: Create Component Definitions Application Designer Step 7: Create Menu Definitions Application Designer Step 8: (Optional) Define Business Processes Application Designer Step 9: Enable PeopleSoft Security Security Administrator Step 10: Test the Application Online System


of 65

Migration Path A migration path will be defined and used during the software development and customization process to move all programs from development into the production environment. Following is a sample migration path:

SADEV

Development Environment Developers have full security access required to perform all the development of

customizations, modifications and interfaces in SADEV. Development work is unit tested by developer. After unit testing by the developer, work is tested by functional users. Development is tagged to a PS project (i.e. any modification is attached to a PS

project). Mi ti f SADEV t SATST i h dl d b th d l

SAUAT

SAPRD

SATST

Test Environment Functional users perform all functional testing in SATST. Testing data will be available in SATST. Developers will not be able to make any changes to objects in SATST. If additional changes are required, the object must be migrated back to SADEV. After

changes are made in SADEV, work will be re-migrated to SATST.

User Acceptance Testing / Quality Assurance Environment System wide testing is performed in SAUAT to ensure the modification has not had any

adverse effect on any other module functionality. This is the final step of the testing process prior to being moved into production. Functional users will be involved in system testing. Any additional changes must be addressed in SADEV, then migrated through SATST

and finally back into SAUAT.

Production Environment No developer changes may be made in the production environment, SAPRD. Any additional changes would be considered as a scope change and would begin the

development process in the SADEV development environment.


page 43 of 65

Decision Criteria for Software Modification All software modifications will require approval. Following is a list of criteria against which approval decisions will be based:

Compliance: a state, federal or legal mandate UMBC business requirement: critical business objective Productivity enhancement: maintain or improve service level or administrative

productivity Significant functional void: reduction in manual effort or requirement of additional

staff

Software Modification Approval Process The following steps will be employed to process each request for software modification:

The Functional Module Lead, in conjunction with the appropriate technical team members, will prepare a Request for Modification form that details the requested change including the rationale, expected work effort, estimated cost and long-term maintenance consequences.

The Request is forwarded to the Project Management Committee to review, follow-up and clarify the need for the customization.

The Project Management Committee will review the request and decide whether it should be approved. (See Criteria for Software Modification above.)

If approved, the Project Director will sign the Request for Modification and notify the functional leads.

If the Project Management Committee cannot make a definitive decision, or if the request should be escalated, they will refer the request to SA Project Steering Committee. The Project Director is responsible for providing his recommendation as the issue is escalated.

If approved by the SA Project Steering Committee, the Project Director will advise the functional lead as stated above.

When the modification is approved, a Technical Design document is prepared by the Technical Lead that details the coding requirements as well as any adjustments to the original cost estimate.

The Technical Design document will be sent to the Functional Lead and Project Director for review and sign off.

The Project Director must sign off on Technical Design documents before further software modification work can begin.


of 65

Reporting Strategy UMBC is committed to developing a university-wide reporting solution concurrently with the SA implementation and HR upgrade. The solution will include both historical (official) legacy data and PeopleSoft SA/HR data; it will be able to create official SA reports for State, Federal and other external agencies; it will be able to track important trends in admissions, enrollments, and HR over different points in time, it will have edit checks designed to facilitate the cleaning of source data, and will be robust enough to provide administration with the analysis it needs to make informed policy decisions. UMBC has purchased and implemented the iStrategy data warehouse under its current legacy SIS. iStrategy is designed to work with PeopleSoft SA and UMBC intends to continue to use iStrategy as a key component in its reporting strategy.In addition to iStrategy, the university will also utilize the traditional tools such as SQR, Crystal, and PS-Query to meet specific reporting requirements. The key question to be determined is defining the appropriate tool to use for each required report. During the design sessions when reports are identified we will determine what user group that report is intended and whether that report is needed in real time to monitor transaction activity. UMBC’s goal is that at least half of the identified required reports will come out of iStrategy and UMBC hopes to minimize the use of Crystal and SQR for general end-user reports. This plan has both considerable benefits and risks and these will be discussed later in the document under risk mitigation. UMBC has established a Data Management Council (DMC) with key stakeholders representing the primary SA functional offices, a number of the DMC members are also on the SA Steering committee, which will provide a connection between the work of the DMC and SA project. It is recommended that the SA Project team and the UMBC Data Management Council work closely to coordinate efforts between the Student Administration project and the other reporting initiatives at UMBC.

Report Development Tools Reporting efforts will focus on utilizing the iStrategy product tools, Proclarity, and the delivered reporting tools within the Student Administration application.

iStrategy iStrategy (http://istrategysolutions.com/ ) is a commercial solution that provides a delivered data warehouse that comes with scripts to support integration to SA. iStrategy provides scripts to bring over data related to the following modules – Admissions, Registration, Student Term, Class Schedule, Student Plan, Faculty Term, Graduates, and Student Financials. In addition, there is a student financial aid module in development that UMBC intends to acquire once it becomes available. iStrategy uses a business intelligence (BI) tool named ProClarity (http://www.microsoft.com/bi/products/ProClarity/proclarity-overview.aspx ). In 2007, Microsoft acquired Proclarity and this is now an important component of Microsoft’s BI strategy. ProClarity provides a portal-like dashboard for the presentation of reports and provides users with the ability to save reports as spreadsheets and email reports to others. In addition to ProClarity, it is possible to utilize the Microsoft Reporting Services with the iStrategy tables and develop reports that are condusive to OLAP technology. A significant benefit of iStrategy is that important data elements have been extracted and defined in the process of performing the ETL


of 65

(extract/transform/load) into iStrategy. As a consequence, the complexity of developing new reports is reduced in iStrategy versus SA and this allows staff without deep knowledge of the SA table design to write reports. One significant advantage of iStrategy is that it runs outside of SA and is highly optimized for the reports it runs. This provides the user with consistent performance and lessens the load on the SA transactional system by eliminating a large number of reports from being run within the context of SA. One disadvantage of iStrategy which must be analyzed is that iStrategy does not utilize the PeopleSoft security system. As a result, to the extent UMBC wants to limit access to reports there will need to be separate security maintained within iStrategy. A key issue for the DMC will be determining policies and procedures regarding data access and security.

SQR SQR is the structured language delivered with PeopleSoft. SQR has been considered the “standard” tool for developing reporting and processing programs. It offers flexibility, if-then constructs, as well as proven reporting features. Delivered SQRs may be adapted to needs that are similar wherever possible. A benefit of SQR is that it runs within the SA security context and will enforce whatever security is defined for that user running the application. As a result, SQR is an excellent tool for providing access to transactional data or data that may need to be secured. A disadvantage of SQR is that runs within the process scheduler and is not real-time. SQR reports may have some impact on SA transactional performance or may be delayed a few hours from running if a large number of reports are queued waiting to be run.

PeopleSoft Query PeopleSoft Query is used to extract information from a PeopleSoft database without writing Structured Query Language (SQL) statements. The queries written can be as simply or with as much complexity as necessary. Queries can be one-time, ad-hoc queries or queries that will be used repeatedly. Queries can be saved as private queries, accessible only to the user that created the query, or as public queries that may be accessed and executed by other users. PeopleSoft Query should be considered as a reporting tool for simple reporting needs since development time can be significantly less than for other tools. In addition to satisfying simple reporting needs, PeopleSoft Query is a versatile tool that can be used in the following ways:

To display data in a grid To run queries as a separate process To schedule a query To download query results to an Excel spreadsheet To serve as a data source for Crystal Reports To serve as a data source for defining online analytical processing (OLAP) Cube

Manager dimensions and facts

While designed to be easy to use, one disadvantage of PS-Query is that it requires an understanding of the underlying SA table structure. In addition, poorly written PS-Query reports can place a significant load on the transactional system. Finally, PS-Query reports, generally


of 65

require the user to have a higher degree of understanding about the system that you would expect of a general user.

PeopleSoft Query/Crystal Reports Crystal Reports, provided by PeopleSoft, is a third-party reporting tool from Business Objects (that recently acquired Crystal Decisions) that helps generate clear and easy-to-read printed reports containing data from PeopleSoft applications. Both standard and custom reports can be created in Crystal. Reports can be generated in a variety of different formats, including Adobe Acrobat, Microsoft Word documents, and Excel spreadsheets. Generating formatted output in Crystal involves two steps:

Queries are created and saved in PeopleSoft Query Report definitions are created in Crystal to format the fields (columns) used in the

queries

Report Request

Reports On Demand As delivered, all reports and processes delivered with the PeopleSoft application are run “on-demand” using the Process Scheduler. Reports are defined as processes, and these processes are made available on menus. Process Scheduler can produce report output to a variety of destinations in a variety of output formats, depending on the development tool used.

Scheduled with Process Scheduler Reports can also be scheduled to run at a specified time or on a recurring basis using the Process Scheduler. Recurrence definitions are defined and used to determine the specifics of when and how often a report process will run. Reports can be scheduled to run in off-peak hours or at night in order that system performance is not impaired during the business day. It is recommended that UMBC develop procedures and train system users to take advantage of the Process Scheduler to schedule run times for reports.

Report Distribution and Output

Report Output Options Process Scheduler provides a wide variety of output options for reporting. A report process can be designated to be delivered via email, output to file, directly to a printer, or to PeopleSoft’s Report Manager (web). In addition, several different output formats can be selected. These include, but are not limited to; comma separated values (.csv), HP printer format, HTML, Adobe Acrobat (.pdf), Microsoft Word, and Microsoft Excel.

Online Report Delivery PeopleSoft Report Manager Reports that have a destination of web are available for online viewing via the web browser in PeopleSoft’s Report Manager facility. By default, reports that are sent to Report Manager are available only to the requestor, or to those who have administration capabilities and appropriate security. The user also has the option at run time to make the report available to other users either by specific UserID or by security role. In addition, the Process Definition that defines the report can be pre-defined with a distribution, if desired.

Hardcopy Report Delivery and Distribution


of 65

Hardcopy report distribution is strictly a manual process and typically involves the use of a third-party product that prefaces each report output with a banner for easy identification. PeopleSoft does not provide any tools or mechanisms that aid in this process.

Report Security Confidentiality of information must be considered with any report that is made available to an end user. Security in PeopleSoft must be defined specifically to a component, record, or program. The following should be considered for reporting security:

SQR reports have no facility for defining security to a report. Security views must be added to selects within the program to achieve security. Only a few reports delivered by PeopleSoft utilize security views.

Any reporting output based on PS Query will incorporate PeopleSoft security, provided that a query security record is defined on at least one of the records used in a join. It cannot be assumed that all record definitions in PeopleSoft contain a query security record. Security records must be verified in the Application Designer. In addition, it may be desired to restrict access to certain records within a user’s Query access.

Any SQR run by a third-party product, or run outside of the PeopleSoft Process Scheduler may not function correctly if it utilizes query security views in the main join. The Process Scheduler has the user’s security credentials available within its environment, which are not automatically available to a third-party tool.

iStrategy security must be maintained outside of SA. It is critical for the UMBC Steering Committee to make certain that either customized user security is not required within iStrategy or that a business process has been defined that will ensure an auditable process for adding security to iStrategy users and reports.

Reporting Requirements

Determining Factors for selecting a reporting tool

Real-time Access Real-time access to reports give the status of the system at the time the report was run. It is used to validate the results of transacational work performed. It is expected to be performed primarily by the functional offices using SA and is not intended to represent official campus reports. PS-Query should be the preferred tool for these types of reports. PS-Query runs as an interactive process under the context of the user and is the best method to provide real-time access to data for transactional verification. Running the same query at two different times on the same day will often result in different results based on transactions that have occurred between runs. As a result of the changing nature of the data the reports coming from PS-Query are generally non-reproducible. SQR reports go through the process scheduler and may be delayed based on the transactional queue. SQR reports may be desired for this type of reporting if the report is very complex and may tie up your computer for an extended period if run interactively. Unless written to use effective dating, SQR reports may not be reproducible. Anyone needing access to real-time transactional data should first look at PS-Query and if highly complex move to SQR. IStrategy is not an option for real-time reports since it uses data from the previous business data. Non-Real-time Access – Management Reporting


of 65

Management reporting should have the principle of reproducibility – meaning the report that was generated one day can be regenerated at a later date if that is desired. Management reports may be intra-departmental or inter-departmental. The goal of management reporting is to allow entities to manage their areas through the appropriate use of data from the system. Some management reports are considered official campus reports. Official campus reports are usually considered public information unless specifically identified as sensitive due to the listing of data elements that require protection. It is the intent that iStrategy should be used for management reporting to the degree that it can be done. When analyzing management reporting requirements we want the committee to focus on iStrategy as the preferred method for official reporting and all reports that do not contain sensitive data elements. Reports that contain sensitive data elements (eg. SSN), in this situation SQR reports are the preferred method for reporting sensitive information since SQR can use the SA security system. As a recommendation, anagement reporting should not be generated using PS-Query since this is usually not reproducible.

Delivered Reports PeopleSoft delivers a number of reports specifically for the student administration application. A careful review of these delivered reports should be performed. Delivered reports should be used whenever possible to satisfy reporting requirements in order to minimize future upgrade and system maintenance costs.

Customized/Modified Reports In the event that a delivered report meets most but not all of a particular reports requirements, it may be necessary to customize or modify the report. For upgrade efficiency, all report changes should be treated as customizations. A copy of the delivered report should be saved under a different name and changes made to the new copy. Any time a report is changed it is recommended that all affected SQRs and SQCs be captured in a separate directory structure.

New Reports There will be cases when the delivered reports do not satisfy specific internal or external reporting requirements, or there are specific existing reports that must be retained. New reports will be slotted to be developed using iStrategy or the delivered PeopleSoft report development tools. If appropriate, new reports will be built using an existing report definition as a base or model.

Ad-hoc Reporting

iStrategy

iStrategy provides a very intuitive what-if capability for doing ad-hoc reporting, especially for management analysis of trends. As part of implementing iStrategy OIR intends to load official data from past years. This will give the campus the ability to do better trend analysis. In terms of security, iStrategy security is separate from SA security and we can

PeopleSoft Query PeopleSoft Query can be used in ad-hoc fashion to provide end users the ability to retrieve application data according to their own specifications and convenience. It is most useful in its native form at providing raw, unformatted data since Query has limited formatting options, although Query delivers functionality to allow users to download query results into an Excel spreadsheet. Query trees, security, and access profiles will need to be reviewed. In some instances Query trees, security, and access profiles may need to be developed to tailor access to the specific tables and query options needed.


of 65

PeopleSoft Query/Crystal The combination of Crystal Reports with PeopleSoft Query provides the most powerful ad-hoc solution that is delivered with PeopleSoft. Using Crystal Reports will require the installation of Crystal Reports on each ad-hoc user’s workstation. Since Crystal Reports for PeopleSoft uses a 2-tier connection that connects directly to the database, database connectivity software and sufficient network bandwidth also will be required. The use of Query/Crystal may not be practical for wide distribution due to maintenance and bandwidth requirements.

System Performance Considerations System performance can be significantly impaired by report execution, thus negatively impacting the ability of all of the system users to use the application efficiently. UMBC should consider the following to help optimize system performance:

iStrategy IStrategy runs on a separate hardware environment that is optimized to support OLAP reporting. This allows us to isolate reporting from the SA transactional environment and make certain that reporting and transactional performance are isolated.

Separate Reporting Database Very few reports must be generated with ‘real time’ data. To minimize system performance issues, reporting off the production database should be restricted to very few system users. It is recommended that reporting activity not be permitted in the production database unless ‘real time’ data is required. A separate reporting database can be established that contains some or all of the tables in the main database. The reporting database would be refreshed on a periodic basis, either by copying the contents of the main database or using processes to keep them synchronized.

Reporting Tables/Views Reporting data may be made available to system users in tables or views separate from the primary application tables. The data in the reporting tables or views is static and may be refreshed by request or according to a defined schedule. If several programs are required to fill reporting tables, they can be scheduled to run at specific times to reduce impact to the online or batch processing of the application.

Ad-hoc Queries Users building queries must understand the student administration table structure in order to ensure that the query is designed correctly and generates the correct information. Users executing poorly designed ad-hoc queries can seriously impact performance of the application system or generate reports with inaccurate data. UMBC will need to determine the extent to which the PeopleSoft Query functionality will be available to the student administration system users. If Query is used, UMBC should consider allowing only a limited number of trained ‘super-users’ to write queries. These trained users can develop queries can be saved in the public domain to be accessed and executed by system users that have run-only Query authorization.


of 65

Testing Strategy The credibility and success of PeopleSoft implementation initiatives are based on the ability to provide a system that has been thoroughly tested. The development and use of a comprehensive testing strategy will ensure this goal is met. This strategy defines the testing tools and templates, approach, processes, and procedures for setting up and executing the test plan.

Testing Approach The approach for testing consists generally of the following steps:

Assign Testing Coordinator and develop testing infrastructure (schedules, forms...) List every program/function/business event that needs to be tested Develop guidelines and train staff for preparing test cases Prepare test cases Prepare test environment Execute the tests Review results Analyze expected results

o Execute test scripts with notes on actual results; sign off if acceptable o Complete Test Incident Report, if applicable o Update Test Case Log o If the expected results are unacceptable and result in a change from the original

design and technical specifications, complete a Change Request and submit it to the Project Functional Lead for review

Re-test and repeat the above steps as required

Testing Processes Described below are the types of testing that will be applied throughout the project. The functional areas will lead the testing effort by creating test scripts to test all business processes, modifications, and functionality. These test scripts will contain detailed information with expected results. If an expected result is not obtained in the first test cycle, the test script will be input again in the next cycle. Once an expected result is obtained, the test script document will be signed off as completed and accepted by the appropriate functional team member.

Unit Testing The goal of unit testing is to test setups, assumptions, business processes, code, and conversions for a specific component. The development team is responsible for developing and executing the test cases for the individual components. Required coding corrections are made and testing continues until all conditions are successfully tested. This testing is the final development activity for an individual component. The unit test plan and results are reviewed according to the quality assurance plans in place for the project before migrating the code from the Development database to the Test database.

System Integration Testing System integration testing begins once the individual components have been migrated to the Test database. The testing team is expanded beyond the initial developers to include


of 65

developers of interfaces and interfacing systems; users; system, network and database administrators; and documentation specialists. While this expanded team is used to define and conduct this testing, the responsibility for fixing errors discovered remains with the original development team. Simple conditions are tested first, followed by increasingly complex conditions until all inputs, processes, outputs and interfaces have been thoroughly tested. Functional requirements as well as data, security, performance, recovery, documentation and procedure requirements are tested.

Customization Testing UMBC will develop and execute unit test scenarios for each modification to any type of PeopleSoft object, such as a record definition, programming code, report, interface, page, menu, workflow process, or new application. These test scenarios are developed to ensure that the customization has been successfully completed and the underlying processes are performing correctly within the module. If the expected results are not achieved during testing, problems will be documented and reported on a test incident report. The customized objects will be reconsidered and reviewed by the developers to determine whether the customization was improperly performed or if there is a problem with the validity of the test case scenario and expected results. Corrections will be made as required and the module will be subject to re-test until the expected results are achieved.


of 65

Performance Testing As the implementation progresses, performance and stress testing methodologies will be incorporated into the project planning to validate the performance levels and resolve any issues prior to go-live. Post-production, these methodologies can be leveraged for on-going monitoring.

User Acceptance Testing During this activity, PeopleSoft outcomes will be verified in a simulated production environment based on user acceptance that the system performs in accordance with the stated objectives and meets UMBC’s requirements. The entire network will be tested to ensure that all users can access the PeopleSoft system with appropriate security. Users accept the system based on their validation of testing results utilizing live data. Users will be provided with test scripts to test supported processes. User testing efforts will be supported by functional members of the SA Project team. Each process to be supported is run through a scripted testing scenario that must yield anticipated results.


of 65

Security Strategy The need to create and maintain user accounts in PeopleSoft’s Campus Solutions is clearly significant in student administration where thousands of student user accounts must be created and maintained each year to allow students self-service access. The objective for security is to ensure that shared, distributed application data is protected at various access levels and that UMBC’s student administration system is protected from unauthorized access. There are three primary areas to be considered when defining security for any PeopleSoft application system:

Network Security. All systems that support the application, such as the network, network file systems and server platforms must be secured using security tools native to the particular operating system.

Database Security. The database itself must be secured using security tools native to the database platform being used.

Application Security. The PeopleSoft application must be secured using the tools and constructs provided by PeopleTools and those specific to the particular application being used.

Network Security The PeopleSoft Internet Architecture (PIA) utilizes a multiple-server configuration that may be physically separated or logically separated on one or more physical servers. The following table lists the primary server components of the PeopleSoft Internet Architecture along with recommended access. Server Component

Description Recommended Access

File Server The file server is the central repository for the entire application system. The entire system is initially installed from the file server, and the Application Designer executables are accessed from this location.

End Users – None Application Developers – Read only Technical Administrators – Full access

Application Server(s)

The Application Server is the central “engine” of the PeopleSoft system. Outside of the database, this is where most of the work takes place.

End Users – None Application Developers – None Technical Administrators – Full access

Web Server This server provides the web interface to the end user, and directs user requests for pages to the Application Server(s). End users are provided a URL to access the PeopleSoft system, similar to any other web page on the internet.

End Users – None Application Developers – None Technical Administrators – Full access

Database Server

This is where all PeopleTools and Application Data are stored.

End Users – None Application Developers – Limited access for support purposes in production, possibly full access in development databases for development support. Technical Administrators – Full access for support purposes


of 65

The PeopleSoft directory structures that are typically setup on the network will need to be secured so that they are write-able by the project team and readable by everyone who will be using PeopleSoft. At times, reports will need to be secured so that only certain offices have access to run them. These can be secured by the network administrator. Inbound and outbound interfaces as well as other types of application programs will require access to a network file system to read or write data. It is very important that these file systems or directories be secured and access given only to authorized personnel since the content of these files may contain sensitive data. Network accounts must be setup for users of the system. In most cases, these accounts have already been created because the users are accessing other computer systems on the network, such as email.

Database Security

PeopleSoft Database Connections Instead of defining a database ID for each and every end user, PeopleSoft Security utilizes a Connect ID and Access ID to connect directly to the database. These IDs will be defined during installation and creation of subsequent database environments and are the only database users that are required to be set up. End user and developer access to database objects and data is controlled by PeopleSoft Online Security.

Developers and Support Access Typically only a database administrator or other authorized person should have access to database objects and data at the database server level. However, there may be situations where certain persons, such as developers, would benefit from having access directly to the database. In a development database, developers should have access to update database tables in order to maintain the data (clean up) used during unit testing. In the test and production databases, measures should be taken to protect application data and database objects. Read only access to database data should be provided to application support personnel to aid in debugging application problems.

Application Security Application Security encompasses the setup of all of the user accounts and their roles within PeopleSoft. A security definition refers to a collection of related security attributes created using PeopleTools Security. The majority of PeopleSoft Security is defined with three major constructs:

Permission Lists are lists, or groups, of authorizations. Permission Lists store sign-on times, page access, PeopleTools access etc. A Permission List may contain one or more types of permissions. The fewer types of permissions in a Permission List, the more modular and scalable the implementation.

Roles link Permission Lists to User Profiles. Multiple Roles can be assigned to a User Profile, and multiple Permission Lists can be assigned to a Role.

A User Profile identifies the PeopleSoft application user, assigns him/her a password and Role or Roles, in addition to other information that grants the user specific access to the system. For most part, a user inherits permissions through a role.


of 65

Each user of the system has an individual User Profile, which in turn is linked to one or more Roles. To each Role, one or more Permission Lists are added, which control what a user can and cannot access. Users inherit permissions through the Role. There are a few permissions that are assigned directly to the User Profile, but these are the exception, as in Process Profile, Primary, and Row Level permission lists.

Security Maintenance The Io consultants will work with the SA Project team to identify and develop procedures for ongoing, day-to-day security administration tasks, such as dealing with signon problems, distributing security responsibilities, maintaining security profiles, and field and record audits. In addition, the technical consultants will work with the project technical team to modify or develop procedures for migrating security between PeopleSoft databases and fix/upgrade procedures for security tables and trees.


of 65

End User Training Strategy (This section will be expanded at a later date) The purpose of this section is to present a strategy to ensure that all end users of UMBC’s PeopleSoft Campus Solutions system have the documentation and ongoing end user training assistance they will need to use the system effectively in their respective roles. End users include personnel that will use the system extensively to perform the majority of their UMBC job responsibilities, such as the staff in Admissions, Academic Services, Financial Aid, Graduate School, DPET and Bursar’s offices. In addition, end users include individuals who use the system to perform some of their job responsibilities or learning activities, including faculty, department chairs, students, administrators and administrative assistants in the academic departments. For training purposes, end users will be assigned roles that typically coincide with respective security roles. Each role will be assigned a "Training Plan," which is comprised of a series of required and recommended components. Once end users have been identified and grouped based on their training needs and physical locations, end user training components will be designed to fit these needs. The UMBC Training Lead will be responsible for planning, developing and executing end user training. End user training will be structured around discrete business-process components, so that end users receive training in the processes that are relevant to their jobs or user roles. Course content will be structured around the roles of end users, such as Financial Aid Advisors, Admissions Advisors, students, faculty, department chairs, Bursar, etc. UMBC will use PeopleSoft’s User Productivity Kit (UPK) as the primary development tool to produce, deploy, and publish training materials. The UPK provides pre-packaged learning content and a developer tool to modify the learning content based on an institution’s training needs. The learning content includes comprehensive instructor-led training materials, web-based education, performance support and documentation. Additional development tools will be utilized, as required, to supplement the UPK; i.e., Visio, PowerPoint, etc…


of 65

P R O J E C T C H A R T E R A P P R O V A L Document Title: University of Maryland, Baltimore County Student Administration Project Charter Authors: UMBC SA Project Management Team:

• Michael Busges, Project Director

Io Consultant: • Joey Harpst, Project Manager

Approval History Date Approved Approved By Signature Dr. Arthur Johnson,Executive Sponsor Michael Büsges, Project Director Joey Harpst, Io Project Manager


of 65

A P P E N D I C E S Appendix A - SA Project Resources

UMBC SA Team Name Role Michael Büsges Project Director Arnold Foelster Technical Lead Molly Burdusi Project Coordinator/Financial Aid Ralph Caretti UG Admissions Pam Hawley Records Advising Dave Hollander Records/Advising Subhashish Dutta Student Financials Gust Mitchell Provost’s Office Technical Coordinator (TBD) Graduate School Betty Douglass Graduate School Doug Kendzierski CPS Steve Harris CPS Susan Dawson Training Coordinator TBD Training Assistant Kevin Joseph System Integration Cheri Putro Admissions/Records Tech Dina Caddeo Financial Aid Tech Betty Blanchette Student Financials Tech Patrick Simon Interfaces Robert Williams Institutional Research DBA Support DBA Pool Network/Architecture Support Network/Architecture Group myUMBC Portal Support Portal Group TBD Project Website/Communication Support

UMBC SA Subject Matter Experts Name Subject Area Dale Bittinger UG Admissions – All areas Yamiley Saintvil UG Admissions – Operations Rebekah Porter UG Admissions – Recruitment Monesha Phillips UG Admissions – Recruitment Leah Carroll UG Admissions – Applications Stephanie Johnson Financial Aid – All areas Cory Ziegenfuss Financial Aid – Technical Bobby Shahpazian Financial Aid – Scholarships Rob Galvin Financial Aid – Scholarships/Technical Jean Bunche Student Financials – All areas Dee Salley Student Financials – Cashiering Isabel Garrido Student Financials – E Billing & Perkins Loans Vanchon Brooks Student Financials – Sallie Mae Interfaces Jasmine Zacharias Student Financials – Monthly Payment Plan Steve Rebinson Registrar’s Office – All areas Alicia Arkell-Kleis Registrar’s Office – Records and Registration Lydia Jackson Fryer Registrar’s Office – Transfer Credit, Graduation Cathy Powell Registrar’s Office – Graduation Stephanie Anderson Registrar’s Office – Transfer Credit - Degree Audit


of 65

Al Frankel Registrar’s Office – Schedule of Classes, Catalog Diane Butler Registrar’s Office – Grade Processing Ramal Jenkins Registrar’s Office – Records, Grades, Residency Angie Blair Registrar’s Office – Transcripts Ken Baron Academic & Pre-Professional Adv. – Degree Audit, Advising Nancy Miller Academic & Pre-Professional Adv. – Degree Audit, Advising Beth Jones CPS – Registration & Operations Bev Bickel CPS – English Learning Center Scott Randles CPS – Billing Greg Williams CPS – Graduate Programs Jill Barr Graduate School – All areas Janet Rutledge Graduate Student Financial Aid Issues Katie Lemich Graduate School – Recruitment Katie Nee Graduate School – Admissions Vickie Greisman Graduate School – Legacy Systems & Reporting Lisa Morgan Graduate School – Course Catalog & Progression Database Linda Thomas Graduate School – Degree Completion Data Brian Thompson Graduate School – Graduate Assistantships Kathy Ruth Graduate School – Internal Admissions Nick Yeates Graduate School – Technical Michael Dillon OIR – Student Financials Mike Glasser OIR – Campus Community & Technical Issues Shannon Tinney OIR – Financial Aid & Advising Conny Pierson OIR – Enrollment, Registration & Advising Tracey Musick OIR - Enrollment, Registration & Training Yung Byun OIR – Enrollment & Registration

Additonal Project Contacts Name Department Kathy Zerrlaut Athletics Bob Sumers Campus Book Store Drema Wentz Campus Scheduling TBD Career Services Center TBD Facilities Management TBD General Counsel Anna Shields Honors College Greg Simmons Institutional Advancement Arlene Wergin International Education Services Andrea Spratt Learning Resource Center LaTanya West Library LaMont Tolliver Meyerhoff Scholarships TBD Parking Services Corey Williams-Green President’s Office Ryan Bos Residential Life Christine Routzahn Shriver Center Sijo Jose Student Support Services Jennifer Lepus University Health Services TBD Women’s Center


of 65

Consulting Resources Name Role Joey Harpst Consultant Project Manager Darin Gordon Campus Community/Recruitment/Admissions Consultant Robert Jordan Student Records/Academic Structure Consultant Mike Fabry Student Financials & Financial Aid Consultant Vickie Thomas Academic Advising Consultant Tracy Barnes Lead Technical Consultant TBD Technical Consultant #1 TBD Technical Consultant #2 Siri Flocke Conversion Specialist


of 65

Appendix B – Project Templates Project Templates can be found in the following directory in the following shared network directory: P:\SA\Project Management\Templates.


of 65

Appendix C - Document Management All Project documents will be stored on the shared network server in the SA Project Directory. The Project Manager will maintain the folders on this drive. All team members and consultants will have read/write access to this shared network drive. To ensure that strategies, plans, issues, decisions, solutions, status and results can be accurately recalled and communicated, Project documentation development and management standards will be followed. The table below describes the types of information to be documented, the tools to be used, and the party responsible for the documentation. Templates for all tools are contained in Appendix B. SA Documents & Templates Tool Type of Information Responsibility Archive Location UMBC SA Project Charter.doc

Project objectives, organization, scope, and ground rules

Project Management and Control

Project Facilities Project Processes Issue Resolution Process

Communication Plan Conversion Strategy Testing Strategy End User Assistance Strategy

UMBC Project Directors Steering Committee SA Project Core Team Consultant Management

P:\SA\Project Management\ Administrative

Project Plans SA 9 [module] Plan

Project tasks, milestones, and percent completed, etc.

Project Manager

P:\SA\Project Management\Project Plans

SA Project Team Training.xls

Required and optional courses by role and team member, courses scheduled, and courses completed

Training Coordinators P:\SA\Change Management\Training

Communication Matrix.doc

Who, What, When, How Often, and How to communicate Project information to SA Project Team and University community

Project Director P:\SA\Project Management\Change Management


of 65

UMBC Consultant Status Template.doc UMBC Status Template.doc UMBC Status [first name last name] - [week ending (YYYYMMDD)] .doc Ex: UMBC Status John Smith - 20071001.doc

Weekly team status reports

Consultants, Project Manager Team Leads

P:\SA\Project Management\Status Reports\Io P:\SA\Project Management\Status Reports\UMBC

UMBC Meeting Agenda Template.doc YYMMDD [module] [Meeting title] Agenda.doc

Agendas for Project, team, or committee meetings

Meeting facilitator P:\SA\Administration\Meeting Minutes

UMBC Change Control Template.doc SCC [##] [request id] SA9.doc

Functional request for scope change control

Io and UMBC Functional Leads

P:\SA\Project Management\Change Management \Change Control

UMBC Design Specification Template.doc DDS [###] SCC [##] SA9 [module].doc

Detailed design specification for software modification, report, interface, or data conversion programming

Io and UMBC Functional and Technical staff

P:\SA\Technical\Design Specifications

[Module] [Conversion Table] Mapping.xls

Template for mapping legacy data to PeopleSoft tables

SME’s and technical staff P:\SA\Technical\Conversions\ [module]

UMBC SA Interface List.xls

List of all Legacy Interfaces that support the current Student system(s)

Technical Lead P:\SA\Technical \Interfaces

[Module] Security Roles .xls

Template for defining access and restrictions by user role

Functional Leads, SME’s and Security Technical Team

P:\SA\Functional \[module]\ Security

[Module] Test Script Log.doc

Log of test scripts ready for use

Functional Leads P:\SA\Functional \[module]\Testing

[Module] [###]Test Script.doc

Template for developing test scripts

Functional leads P:\SA\Functional \[module]\Testing

* All Templates will reside at P:\Student Administration\Project Management\Templates

Naming Conventions The template titles listed in the table above will serve as standard naming conventions for Project file names. Documentation titles should follow the same conventions minus the program extension


of 65

When creating a document or saving a file, enter the specific information by replacing the generic names in brackets with specific names

In file names, leave spaces between words Do not use an underscore character between words Capitalize all words, except articles and prepositions, in document titles and file names For titles or file names that include dates, use the dating format: YYYYMMDD

Naming and numbering schemes for reports, interfaces, and modifications should use the same naming guidelines and abbreviations. Guidelines for these items are as follows: Modules: AA = Advising AD = Admissions AS = Academic Structure CC = Campus Community FA = Financial Aid SF = Student Financials SR = Student Records PM = Project Management TE = Technical CM = Change Management OT = Other

System Designations: HR = Human Resources PY = Payroll FN = Financial SA = Student Administration

Document Flow for “Modifications”: RISK ID ISSUE ID CHANGE REQUEST ID DETAILED DESIGN SPECIFICATION GAP ID


of 65

Appendix D – SA Interface Inventory The SA Interface Inventory list can be found in the following shared network directory: “P:\SA\Project Management\Project Charter\Appendix D – SA Interface Inventory.xls.”

UNIVERSITY OF MARYLAND BALTIMORE OUNTY STUDENT ...

Documents

Transcript of UNIVERSITY OF MARYLAND BALTIMORE OUNTY STUDENT ...