UMBC Project Charter

PROJECT CHARTER UNIVERSITY OF MARYLAND, BALTIMORE COUNTY STUDENT ADMINISTRATION PROJECT
Michael Bsges (UMBC) Joey Harpst (Io Consulting)
Student Administration Implementation Project Charter
TABLE OF CONTENTS
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
EXECUTIVE SUMMARY
Purpose of the Project Charter
The Project Charter articulates the major goals and objectives of the Student Administration Project in implementing PeopleSofts 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 systems 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
-3-
selected student administration data from the legacy system, custom reports and limited modifications to the delivered application. The goal of the projects initial implementation is to support a complete student life cycle in PeopleSofts 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
UMBCs 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
-4-
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 partners implementation methodology and expertise in PeopleSoft with the knowledge and expertise of key technical and functional staff in UMBCs current information systems and business processes. The SA Project team will work together to adapt the PeopleSoft Campus Solutions application to fit UMBCs business processes, while at the same time adapting UMBCs business processes wherever feasible to optimize the delivered capabilities of the software.
-5-
F O U N D AT I O N
Purpose
The University of Maryland, Baltimore County (UMBC) is implementing PeopleSofts 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, selfservice 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.
-6-
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.
-7-
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 projects 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.
-8-
Successful implementation of Oracles PeopleSoft Student Administration system is a top priority of the University. Full and timely participation from all involved, both directly and indirectly, is essential.
-9-
PROJECT STRUCTURE
Organization and Staffing
The following chart provides an overview of the organization and reporting structure of the SA Project Team:
UMBC Student Administration Project Structure
Executive Sponsor Dr. Arthur Johnson
Project Director Michael Bsges
Functional Team
Consultant Project Manager Joey Harpst Project Coordinator Molly Burdusi Academic Concerns Dr. Gust Mitchel (PT)l Admissions/CC Consultant Darin Gordan Records/AS Consultant Robert Jordan Financial Aid Consultant TBD Student Financials Consultant Mike Fabry System Integration Kevin Joseph Admissions/ Records Cheri Putro Dina Caddeo Student Financials Betty Blanchette Consultant Technical PM Tracy Barnes Conversion Tech Consultant Siri Flocke Technical Lead Arnold Foelster
Technical Team
Project Assistant Denise Van (PT)
UG Admissions Ralph Caretti Student Records/ Advising Pam McInnis Dave Hollander (PT) Financial Aid Molly Burdusi
Training Coordinator Susan Dawson
Technical Consultant
Training Assistant TBD
Student Financials Shubhashish Dudda Graduate School Rachel Rachlinski Betty Douglass (PT) CPS Doug Kendzierski (PT) Steve Harris (PT) Institutional Research Robert Williams
Financial Aid Patrick Simon
Technical Consultant
Advising Consultant Vickie Phillips
OIT Support
myUMBC Portal
Database Administration
Network/ Architecture
Project Website/ Communication
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.
- 10 -
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 UMBCs 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
- 11 -
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
- 12 -
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 workarounds, 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 workarounds, 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.
- 13 -
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.
- 14 -
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.
- 15 -
Coordinates conversion activities Maintains database security Performs database capacity analysis Responsible for monitoring version control between database instances
- 16 -
PROJECT MANAGEMENT AND CONTROL

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) PeopleSoft Student Administration version 9.0, including web-based self-service features Campus Community Admissions Student Records Financial Aid Student Financials Academic Advising Self Service
Interface Number/Name Purpose Upload of student room assignments from ORL PC based System DIEBOLD Meal Plan Recruit Download UABR1669 and Shadow Extracts Oracle Mailing Download Applications Test scores are scanned in fsaAtlas* SEVIS Interface
Version SA Modules
Interfaces
Residential Life
RLBM4319 RLBR4334
Undergraduate - Recruiting And Admissions
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
- 17 -
Student Administration Implementation Project Charter Project Scope Scope Category
Preliminary Scope Specifics (Scope will be further refined during Functionality Review and Prototyping)
TCBM2231 for upload to SIS R-25 (Scheduling Software) AXBM4557 Health Service update to SIS Immunization Status
Student Financials
MVBR4008, MVBM4009 ARBR4458, etc. RNBR2635 ARBM4442 Create MVA Tape for TAG Info and process returned Tape from MVA Sallie Mae - Credit Card Payments towards this agency 1098T Budget Payment Plan Grad student application
Graduate - Recruiting And Admissions Institutional Advancement

NABR2804, NABR2806 Alumni Information MHEC Reporting
Institutional Research
IRBR3001 thru IRBR3021 IRBR3034 thru IRBR3050 SOARS Reporting Data Category Module Course Catalog SR Schedule of Classes SR Test Scores AD Bio/Demo Data CC Emergency Contact CC Athletic Participation CC Immunizations CC Career/Program/Plan SR Checklists FA Transfer Rules AA Enrollment SR Test Rules AA Transfer Credit AA Test Credit AA Other Credit AA Awards FA SAP FA Instructor/Advisor SR Residency CC Service Indicators CC Open Accounts SF Honors and Awards CC Comments SR Degrees/Transcript Notes SR Admission Applications AD Academic Standing SR
Conversions
- 18 -
Student Administration Implementation Project Charter Project Scope Scope Category 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 Softwares 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.
Preliminary Scope Specifics (Scope will be further refined during Functionality Review and Prototyping)
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.
- 19 -
Governance Structure
The following chart provides an overview of the decision process and governance structure of the SA Project:
UMBC SA Project Governance
Executive Committee Academic Advisory
Enrollment Services
Student Financial Services
HR/SA Integration
Consultative Committees
Executive SA Steering Group Communication & Training Technical Academic Advising
Project Management Team
Project Team
Governance Entities
Presidents Council Faculty Senate Staff Senates Graduate Council Undergraduate Council Graduate Program Coordinators Undergraduate Program Coordinators SA Advisory Committee Data Management Council GSA SGA
Communities of Interest:
Chairs Meeting Academic Affairs Directors Retention Committee IT Steering Committee R25 Committee Scheduling Advisory Board Enrollment Management Directors Enrollment Services Working Group
- 20 -
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 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 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
Responsibilities 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
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 projects success Continuously supports the high priority status of Project Coordinates the timely resolution of policyrelated issues Provides guidance for Project communications Monitors Project progress Balances competing interests and agendas 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. Develops and approves Change Management activities for the entire campus Consults with the Executive Steering committee on change management
Project Management Committee: Michael Bsges (Chair) Arnold Foelster Joey Harpst, ex officio Tracy Barnes, ex officio Ben Santelman, ex officio
Communication & Training Consultative Committee Jack Suess, Chair Michael Busges
- 21 -
Student Administration Implementation Project Charter Decision and Governance Committees Roles and Personnel 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) 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 Enrollment Services Committee: Yvette Mozie-Ross, Chair Ralph Caretti Pam Hawley Jill Barr Beth Jones Steve Robinson Dave Hollander Dale Bittinger Ryan Bos Stephanie Johnson Consultative
Responsibilities 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. 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. 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 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 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
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 Technical Consultative Committee: Joe Kirby, Chair Mike Carlin Arnold Foelster John Fritz Rob Banz Collier Jones
- 22 -
Student Administration Implementation Project Charter Decision and Governance Committees Roles and Personnel 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 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
Responsibilities
Ensure that business processes are aligned in combined HR/SA database Facilitate decisions on shared business processes and data sets
Advises project team, project management team, Executive Steering Committee, and Executive Committee on all implementation issues concerning Faculty, Deans Offices, and Academic Departments Serves as liaison to campus shared governance entities and other communities of interest Advocates project goals to academic constituencies
- 23 -
Student Administration Implementation Project Charter Decision and Governance Committees Roles and Personnel Stapleton, Laura Sutphin, Kathy Tice, Carolyn Viancour, Teresa Welsh, Mary Wimpling, Kathleen Worchesky, Terry
Responsibilities
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.
- 24 -
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 UMBCs 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.
- 25 -
Student Administration Implementation Project Charter 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 Prototyping Sessions Meeting Description 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. 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. 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. 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. 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. 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.
Project Status Meetings
Project Management Team Meetings
Issue Management/Risk Mitigation Meetings
User Review Sessions
Code Design Review Sessions
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
- 26 -
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.
- 27 -
P R O J E C T S T R AT 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
- 28 -
Student Administration Implementation Project Charter 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
- 29 -
Student Administration Implementation Project Charter 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 GPDs, UPDs, Chairs, Faculty Senate, Faculty Senate Executive Committee, and the deans 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 dont 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
- 30 -
Student Administration Implementation Project Charter 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 VPs 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 Bsges 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
- 31 -
The table below summarizes the communication plan:
Constituent Group
UMBC Staff Faculty and
Information Medium
General information Meeting minutes Team organization Reference documents Timelines Training schedule/Plans FAQs High level status updates Informational briefings on the project progress, milestones, major issues SA-news email Project web site
Frequency Responsibility
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 Provosts Office
Project leadership UMBC Executive Leadership
Meetings with presentation Meeting include: Presidents Council Quarterly. VPs and Deans (Monthly) Deans (biweekly) Provost will update chairs bimonthly at chairs meeting Deans will give monthly update to their chairs. Project Director will come in once a semester to answer question Departmental and divisional meetings. Email and Website, Consultative Committee Meetings
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
Quarterly, on milestones, or as requested
Project Director Provost CIO
Staff department managers/administrative officers/directors
Informational briefings on the project progress, milestones, major issues, feedback sessions, planning sessions
Monthly, on milestones, or as requested
Steering Committee Project Director CIO
Constituent Group
Faculty groups (UPDs, GPDs, Faculty Senate, Graduate and UG Councils, Informal Chairs meetings) Executive Committee Steering
Information Medium
Informational briefings on the project progress, milestones, major issues, decisions. 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. 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. Email and Web site. Face to face at regularly scheduled meetings Word document via email and saved on project shared directory
Frequency Responsibility
As needed likely to be at least once a semester. Project Director Provost CIO
Weekly
Project Management Io Consulting
Core Team members
Issues Log Functionality Review Sessions Analysis, Modification Log and Specificatio ns Briefings by function, technical and project managemen t Weekly meetings Email Web Site Consultative Committees
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
As decisions are made, on milestones, quarterly events
Project Members
Team
Page 33 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 UMBCs data in PeopleSoft. The strategy for accommodating UMBCs 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 inventorys 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
Page 34 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
UMBCs 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.
Page 35 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 Ios 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.
Page 36 of 65
Legacy System
Staging Area / Oracle Tables In PeopleSoft
PeopleSoft Delivered Tables
User Validation
Errors Legacy Summary Report Staging Report Final Report in PS
Data Cleanup
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

Page 37 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
Page 38 of 65
Conversion Migration Path

The following diagram illustrates a migration path for moving conversion data from one environment to another:
SACNV Development of import scripts Create conversion related objects Unit test conversion data
SACVT Data validation by end users No development occurs in this instance
SAPRD Conversion programs will be re-executed in the production instance.
Other Instances?
Other Instances?
Page 39 of 65
Software Modification and Development Strategy

The primary premise for UMBCs 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.
Page 40 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 Step 1: Design the Application Step 2: Create Field Definitions Step 3: Create Record Definitions Step 4: Build SQL Objects Step 5: Create Page Definitions Step 6: Create Component Definitions Step 7: Create Menu Definitions Step 8: (Optional) Define Business Processes Step 9: Enable PeopleSoft Security Step 10: Test the Application
PeopleTool None Application Designer Application Designer Application Designer Application Designer Application Designer Application Designer Application Designer Security Administrator Online System
Page 41 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:
Development Environment SADEV 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 Test Environment SATST 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 SAUAT 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 SAPRD 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 42 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, followup 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.
page 43 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. UMBCs 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 Microsofts BI strategy. ProClarity provides a portallike 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 Page 44 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
Page 45 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 ondemand 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 PeopleSofts 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 PeopleSofts 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 Page 46 of 65
Hardcopy report distribution is strictly a manual process and typically involves the use of a thirdparty 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 users 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 users 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 PSQuery 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
Page 47 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.
Page 48 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 users 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 superusers 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.
Page 49 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
Page 50 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.
Page 51 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 UMBCs 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.
Page 52 of 65
Security Strategy
The need to create and maintain user accounts in PeopleSofts 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 UMBCs 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 File Server Description 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. The Application Server is the central engine of the PeopleSoft system. Outside of the database, this is where most of the work takes place. 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. This is where all PeopleTools and Application Data are stored. Recommended Access End Users None Application Developers Read only Technical Administrators Full access
Application Server(s)
Web Server
End Users None Application Developers None Technical Administrators Full access End Users None Application Developers None Technical Administrators Full access
Database Server
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
Page 53 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 signon 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.
Page 54 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.
Page 55 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 UMBCs 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 Bursars 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 PeopleSofts 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 institutions training needs. The learning content includes comprehensive instructor-led training materials, webbased education, performance support and documentation. Additional development tools will be utilized, as required, to supplement the UPK; i.e., Visio, PowerPoint, etc
Page 56 of 65
P R O J E C T C H A R T E R A P P R O VA L
Document Title: University of Maryland, Baltimore County Student Administration Project Charter UMBC SA Project Management Team: Michael Busges, Project Director Io Consultant: Joey Harpst, Project Manager
Authors:
Approval History Date Approved
Approved By Dr. Arthur Johnson,Executive Sponsor Michael Bsges, Project Director Joey Harpst, Io Project Manager
Signature
Page 57 of 65
APPENDICES
Appendix A - SA Project Resources
UMBC SA Team Name Michael Bsges Arnold Foelster Molly Burdusi Ralph Caretti Pam Hawley Dave Hollander Subhashish Dutta Gust Mitchell Technical Coordinator (TBD) Betty Douglass Doug Kendzierski Steve Harris Susan Dawson TBD Kevin Joseph Cheri Putro Dina Caddeo Betty Blanchette Patrick Simon Robert Williams DBA Support Network/Architecture Support myUMBC Portal Support TBD UMBC SA Subject Matter Experts Name Dale Bittinger Yamiley Saintvil Rebekah Porter Monesha Phillips Leah Carroll Stephanie Johnson Cory Ziegenfuss Bobby Shahpazian Rob Galvin Jean Bunche Dee Salley Isabel Garrido Vanchon Brooks Jasmine Zacharias Steve Rebinson Alicia Arkell-Kleis Lydia Jackson Fryer Cathy Powell Stephanie Anderson Role Project Director Technical Lead Project Coordinator/Financial Aid UG Admissions Records Advising Records/Advising Student Financials Provosts Office Graduate School Graduate School CPS CPS Training Coordinator Training Assistant System Integration Admissions/Records Tech Financial Aid Tech Student Financials Tech Interfaces Institutional Research DBA Pool Network/Architecture Group Portal Group Project Website/Communication Support
Subject Area UG Admissions All areas UG Admissions Operations UG Admissions Recruitment UG Admissions Recruitment UG Admissions Applications Financial Aid All areas Financial Aid Technical Financial Aid Scholarships Financial Aid Scholarships/Technical Student Financials All areas Student Financials Cashiering Student Financials E Billing & Perkins Loans Student Financials Sallie Mae Interfaces Student Financials Monthly Payment Plan Registrars Office All areas Registrars Office Records and Registration Registrars Office Transfer Credit, Graduation Registrars Office Graduation Registrars Office Transfer Credit - Degree Audit Page 58 of 65
Al Frankel Diane Butler Ramal Jenkins Angie Blair Ken Baron Nancy Miller Beth Jones Bev Bickel Scott Randles Greg Williams Jill Barr Janet Rutledge Katie Lemich Katie Nee Vickie Greisman Lisa Morgan Linda Thomas Brian Thompson Kathy Ruth Nick Yeates Michael Dillon Mike Glasser Shannon Tinney Conny Pierson Tracey Musick Yung Byun
Registrars Office Schedule of Classes, Catalog Registrars Office Grade Processing Registrars Office Records, Grades, Residency Registrars Office Transcripts Academic & Pre-Professional Adv. Degree Audit, Advising Academic & Pre-Professional Adv. Degree Audit, Advising CPS Registration & Operations CPS English Learning Center CPS Billing CPS Graduate Programs Graduate School All areas Graduate Student Financial Aid Issues Graduate School Recruitment Graduate School Admissions Graduate School Legacy Systems & Reporting Graduate School Course Catalog & Progression Database Graduate School Degree Completion Data Graduate School Graduate Assistantships Graduate School Internal Admissions Graduate School Technical OIR Student Financials OIR Campus Community & Technical Issues OIR Financial Aid & Advising OIR Enrollment, Registration & Advising OIR - Enrollment, Registration & Training OIR Enrollment & Registration
Additonal Project Contacts Name Kathy Zerrlaut Bob Sumers Drema Wentz TBD TBD TBD Anna Shields Greg Simmons Arlene Wergin Andrea Spratt LaTanya West LaMont Tolliver TBD Corey Williams-Green Ryan Bos Christine Routzahn Sijo Jose Jennifer Lepus TBD
Department Athletics Campus Book Store Campus Scheduling Career Services Center Facilities Management General Counsel Honors College Institutional Advancement International Education Services Learning Resource Center Library Meyerhoff Scholarships Parking Services Presidents Office Residential Life Shriver Center Student Support Services University Health Services Womens Center
Page 59 of 65
Consulting Resources Name Joey Harpst Darin Gordon Robert Jordan Mike Fabry Vickie Thomas Tracy Barnes TBD TBD Siri Flocke
Role Consultant Project Manager Campus Community/Recruitment/Admissions Consultant Student Records/Academic Structure Consultant Student Financials & Financial Aid Consultant Academic Advising Consultant Lead Technical Consultant Technical Consultant #1 Technical Consultant #2 Conversion Specialist
Page 60 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.
Page 61 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 UMBC SA Project Project objectives, Charter.doc 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
Project Plans SA 9 [module] Plan SA Project Team Training.xls Project tasks, milestones, and percent completed, etc. Required and optional courses by role and team member, courses scheduled, and courses completed Who, What, When, How Often, and How to communicate Project information to SA Project Team and University community
Responsibility
UMBC Project Directors Steering Committee SA Project Core Team Consultant Management
Archive Location
P:\SA\Project Management\ Administrative
Project Manager
P:\SA\Project Management\Project Plans P:\SA\Change Management\Training
Training Coordinators
Communication Matrix.doc
Project Director
P:\SA\Project Management\Change Management
Page 62 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 UMBC Meeting Agenda Template.doc YYMMDD [module] [Meeting title] Agenda.doc UMBC Change Control Template.doc SCC [##] [request id] SA9.doc UMBC Design Specification Template.doc DDS [###] SCC [##] SA9 [module].doc [Module] [Conversion Table] Mapping.xls UMBC SA Interface List.xls
Weekly team status reports
Consultants, Project Manager Team Leads
P:\SA\Project Management\Status Reports\Io P:\SA\Project Management\Status Reports\UMBC
Agendas for Project, team, or committee meetings
Meeting facilitator
P:\SA\Administration\Meeting Minutes
Functional request for scope change control
Io and UMBC Functional Leads
P:\SA\Project Management\Change Management \Change Control
Detailed design specification for software modification, report, interface, or data conversion programming Template for mapping legacy data to PeopleSoft tables List of all Legacy Interfaces that support the current Student system(s) Template for defining access and restrictions by user role Log of test scripts ready for use Template for developing test scripts
Io and UMBC Functional and Technical staff
P:\SA\Technical\Design Specifications
SMEs and technical staff
P:\SA\Technical\Conversions\ [module] P:\SA\Technical \Interfaces
Technical Lead
[Module] Security Roles .xls [Module] Test Script Log.doc [Module] [###]Test Script.doc
Functional Leads, SMEs and Security Technical Team Functional Leads Functional leads
P:\SA\Functional \[module]\ Security P:\SA\Functional \[module]\Testing 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
Page 63 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 GAP ID CHANGE REQUEST ID DETAILED DESIGN SPECIFICATION
Page 64 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.
Page 65 of 65

UMBC Project Charter

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UMBC Project Charter

Uploaded by

Copyright:

Available Formats

PROJECT CHARTER UNIVERSITY OF MARYLAND, BALTIMORE COUNTY STUDENT ADMINISTRATION PROJECT

Michael Bsges (UMBC) Joey Harpst (Io Consulting)

Student Administration Implementation Project Charter

Project Structure ........................................................................ 10

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

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

Project Charter Approval ............................................................ 57 Appendices ................................................................................ 58

Student Administration Implementation Project Charter

Student Administration Implementation Project Charter

Student Administration Implementation Project Charter

Student Administration Implementation Project Charter

Student Administration Implementation Project Charter

Goals and Objectives

Goals and Objectives for the Campus Solutions System

Student Administration Implementation Project Charter

Measures of Success for the SA Project

Student Administration Implementation Project Charter

Student Administration Implementation Project Charter

Student Administration Implementation Project Charter

UMBC Student Administration Project Structure

Executive Sponsor Dr. Arthur Johnson

Project Director Michael Bsges

Project Assistant Denise Van (PT)

Training Coordinator Susan Dawson

Training Assistant TBD

Financial Aid Patrick Simon

Advising Consultant Vickie Phillips

Project Website/ Communication

Student Administration Implementation Project Charter

Project Roles and Responsibilities

Executive Project Sponsor

Student Administration Implementation Project Charter

Student Administration Implementation Project Charter

Student Administration Implementation Project Charter

Functional Team Members

Technical Team Lead

Student Administration Implementation Project Charter

Technical Team Member

Student Administration Implementation Project Charter

Student Administration Implementation Project Charter

PROJECT MANAGEMENT AND CONTROL

Undergraduate - Recruiting And Admissions

Records And Registration

Student Administration Implementation Project Charter Project Scope Scope Category

Graduate - Recruiting And Admissions Institutional Advancement

Specific Items Excluded from the Initial Project Scope

Student Administration Implementation Project Charter

UMBC SA Project Governance

Executive Committee Academic Advisory

Student Financial Services

Project Management Team

Student Administration Implementation Project Charter

Student Administration Implementation Project Charter

Project Management Procedures

Project Plan Management

Student Administration Implementation Project Charter Communicating Results

Project Status Meetings

Project Management Team Meetings

Issue Management/Risk Mitigation Meetings

User Review Sessions

Code Design Review Sessions

Student Administration Implementation Project Charter

Student Administration Implementation Project Charter