UMBC Project Charter

7/27/2019 UMBC Project Charter

1/65

PPRROOJJEECCTTCCHHAARRTTEERR

UUNNIIVVEERRSSIITTYY OOFFMMAARRYYLLAANNDD,,BBAALLTTIIMMOORREECCOOUUNNTTYYSSTTUUDDEENNTTAADDMMIINNIISSTTRRAATTIIOONNPPRROOJJEECCTT

Michael Bsges (UMBC)Joey Harpst (Io Consulting)


2/65

Student Administration ImplementationProject Charter


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

Table of Con ten ts .. . . . . . .. . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . .. . . . . . . 2 Execu ti ve Sum mar y .. . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . .. . . . . . . . .. . 3 Purpose of the Project Charter ...............................................................................................................3Project Goals...........................................................................................................................................3Scope ......................................................................................................................................................3Timeline...................................................................................................................................................4

Approach.................................................................................................................................................4Fou nd ati on .. . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . 6 Purpose...................................................................................................................................................6 Goals and Objectives..............................................................................................................................6

Assumptions............................................................................................................................................8Pro jec t Str uc tu re .. . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . .. . . . . 10Organization and Staffing .....................................................................................................................10Project Roles and Responsibilities........................................................................................................11Proj ect Management and Contr o l . . . .. . . .. . . .. . . .. . . .. . . .. . .. . . .. . . .. . . .. . .. . . .. . 17Project Scope........................................................................................................................................17Specific Items Excluded from the Initial Project Scope.........................................................................19Governance Structure...........................................................................................................................20Escalation Procedures ..........................................................................................................................24Project Management Procedures .........................................................................................................25Pro jec t Str ategi es .. . . . . . .. . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . .. . . . 28Communication and Training Plan........................................................................................................28Interface Strategy..................................................................................................................................34Data Conversion Strategy.....................................................................................................................36Software Modification and Development Strategy................................................................................40Reporting Strategy ................................................................................................................................44Testing Strategy ....................................................................................................................................50Security Strategy...................................................................................................................................53End User Training Strategy...................................................................................................................56Proj ect Charter App rov al . . . .. . . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . .. . . .. . .. . . .. . .. . . .. . 57

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


3/65


- 3 -

E X E C U T I V E S U M M A R Y

Purpo se of the Proj ect Charter

The Project Charter articulates the major goals and objectives of the StudentAdministration Project in implementing PeopleSofts Campus Solutions software version9.0 at UMBC. The Charter proposes the scope of the implementation and describes thestrategies and standards that will be used in reaching those goals. This includes howthe project will be organized, staffed, and managed; the tools and templates that will beused; and the standards that will be applied.

The Project Charter is conceived as a dynamic document that will be amended tothroughout 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 progressand success, provide enhanced self-service access for students and faculty,and meet institutional enrollment objectives

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

Reduce duplicative data entry and data maintenance

Improve the quality and availability of data for strategic decision-making aswell 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 andeffectiveness

Utilize as much of the new systems delivered functionality as possible; focuson business process change whenever possible to avoid modifying thedelivered 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 managementthroughout 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 PeopleSoftCampus Solutions with the exception of Recruitment which is already in production. Acomplete list of the modules to be implemented is included in the Project Scope sectionof this charter. In addition, the SA Project will include interfaces to other softwareapplications that will share data with the student administration system, conversion of


4/65


- 4 -

selected student administration data from the legacy system, custom reports and limitedmodifications to the delivered application. The goal of the projects initial implementationis 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, throughgrading and graduation.

Timel ine

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

App roach

UMBCs approach will be to minimize as far as possible significant changes to thesoftware or customizations. Whenever possible, the institution will change businessprocesses, if the delivered software does not support current procedures. Transfer of


5/65


- 5 -

knowledge and the development of internal UMBC expertise will be emphasized. Across-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 thepartners implementation methodology and expertise in PeopleSoft with the knowledgeand expertise of key technical and functional staff in UMBCs current informationsystems and business processes. The SA Project team will work together to adapt thePeopleSoft Campus Solutions application to fit UMBCs business processes, while at thesame time adapting UMBCs business processes wherever feasible to optimize thedelivered capabilities of the software.


6/65


- 6 -

F O U N D A T I O N

Purpose

The University of Maryland, Baltimore County (UMBC) is implementing PeopleSoftsCampus Solutions (CS) version 9.0 enterprise software. The objective of thisimplementation is to replace existing administrative systems with technology thatsupports a growing and changing campus and provides extensive web-based, self-service functionality for faculty and students.

The purpose of this Project Charter is to provide direction and set forth guidelines andstandards for the implementation of the PeopleSoft Campus Solutions system at UMBC.The Project Charter provides the major goals and objectives, strategies, and standardsfor 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. TheProject Charter is a dynamic document that will be updated and amended throughout thecourse 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 implementationpartner, and the larger campus community; the Project Charter speaks to the roles andresponsibilities of each.

Goals and Object i ves

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

Goals and Objectives fo r th e Campus Solutions System1. Provide new or improved functionality to support students academic progress

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

The system will provide students online access to information regardingapplication and admission status; enrollment and grades; progress towarddegrees; financial aid status; billing and financial obligations; academicrequirements; class availability; and transcripts.

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

The system will provide faculty appropriate and ready access to key studentacademic information, course lists and enrollment data, and onlineprocessing of grades.

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

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


7/65


- 7 -

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

3. Reduce duplicative data entry and data maintenance

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

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

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

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

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

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

Reporting to support decision-making and potential data warehouse solutionswill 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 willbe kept to a minimum.

Necessary customizations or software modifications will undergo a rigorousreview and approval process. All software development will adhere todefined 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 t he SA Project

1. Complete the project on time and within budget

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

The implementation will be managed to an established budget and projectplan. Well-defined processes for issue resolution will be used to managescope.

2. Refine and streamline business processes to improve efficiency andeffectiveness

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

Wherever possible, processes will be redesigned to optimize the SA system.

3. Engage key stakeholders in meaningful and efficient manner

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


8/65


- 8 -

Wherever possible, existing structures and committees will be utilized forinput and communication. Ad hoc groups will be convened as necessaryaround specific issues.

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

Resources and responsibility for communication and facilitating change willbe clearly identified.

5. Provide effective, targeted training to support the implementation

A detailed training plan will identify resources and responsibilities fordeveloping 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 willbe readily accessible.

The training plan will address on-going support beyond go-live of thesystem.

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.

Assumpt i ons

At the outset, planning for the SA implementation is based on the following keyassumptions:

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

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

Appropriate hardware environments will be available at each stage of theproject.

Prototyping and development will take place in a copy of the Recruitment 9.0instance 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 beavailable in March of 08.

Appropriate space for project activities will be available.

All modules of Student Administration will be deployed in a combined HR/SAenvironment.


9/65


- 9 -

Successful implementation of Oracles PeopleSoft Student Administrationsystem is a top priority of the University. Full and timely participation from allinvolved, both directly and indirectly, is essential.


10/65


- 10 -

P R O J E C T S T R U C T U R E

Organizat ion and Staf f in g

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

Executive Sponsor

Dr. Arthur Johnson

Project Director

Michael Bsges

UG Admissions

Ralph Caretti

Student Records/

Advising

Pam McInnisDave Hollander

(PT)

Financial Aid

Molly Burdusi

Student Financials

Shubhashish

Dudda

Institutional

ResearchRobert Williams

Admissions/CCConsultant

Darin Gordan

Records/AS

ConsultantRobert Jordan

Financial Aid

Consultant

TBD

Student Financials

ConsultantMike Fabry

Advising Consultant

Vickie Phillips

Consultant Project

ManagerJoey Harpst

Admissions/

Records

Cheri PutroDina Caddeo

System Integration

Kevin Joseph

Financial AidPatrick Simon

ConsultantTechnical PM

Tracy Barnes

Technical LeadArnold Foelster

Student Financials

Betty Blanchette

Database

Administration

Conversion TechConsultant

Siri Flocke

Project CoordinatorMolly Burdusi

Training

Coordinator

Susan Dawson

Training AssistantTBD

UMBC

Student Administration

Project Structure

CPS

Doug Kendzierski

(PT)Steve Harris (PT)

Graduate SchoolRachel Rachlinski

Betty Douglass

(PT)

TechnicalConsultant

Technical

Consultant

Functional Team Technical Team

myUMBC PortalNetwork/

ArchitectureProject Website/

Communication

AcademicConcerns

Dr. Gust Mitchel

(PT)l

OIT Support

Project Assistant

Denise Van (PT)

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


11/65


- 11 -

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

Projec t Roles and Respons ib i l i t ies

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

Executive Project Sponsor

The Executive Project Sponsor ensures that project solutions are in line withUMBCs 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 communicationwhile staying within the parameters of the budget and timetable. The ProjectDirector is responsible for managing the University activities on the project.This individual is the primary point of contact for the Io Managers and isresponsible for resolving internal issues within the agreed upon timeframes.

Responsibilities

Monitors project progress and the quality of deliverables on an on-goingbasis.

Identifies and manages project risks.

Monitors project scope and expectations.

Provides project direction, organization, resource alignment, andallocation

Coordinates project work plan and activities.

Leads Project Team status meetings

Reviews and approves deliverables.

Ensures consistency of activities and deliverables across teams

Ensures timely and adequate communication to the: Project Team

Other Members of the University Community Manages project priorities

Monitors project schedule and milestones.

Identifies resource needs.

Collaborates regularly and consistently with Io Project Manager


12/65


- 12 -

Io Project Manager

The Io On-Site Project Manager is responsible for following the Ioimplementation methodology and for completing project deliverables inaccordance with the contract provisions and the Project Charter document. TheIo Project Manager works closely with the UMBC Project Director to

communicate project progress, identify and resolve key issues, and carefullymanage and control the scope of the project.

Responsibilities

Supervises Io consulting team

Develops and maintains the project plan in collaboration with UMBC andIo 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 deliverablesand 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 theProject Team

Manages the project in accordance with Io implementation methodology

Ensures that the client accepts all deliverables and that the appropriatesign-offs are obtained.

Monitors high-level project status

Io Accou nt Manager

The Io Account Manager provides leadership and quality assurance for theproject and functions as the primary Io contact for accounting and personnelissues. The Account Manager works closely with the Io Project Manager toensure that project deliverables are completed and accepted in accordance withcontract provisions and the Project Charter document.

Responsibilities

Evaluates the integrity of the project scope

Performs periodic quality assessments

Provides assistance with issue resolution

Assists Io Project Manger with managing the staffing and scheduling of Io

personnel Resolves billing and contract issues


13/65


- 13 -

Io Functional Consultants

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

Responsibilities

Works with UMBC Team Leads to best ensure knowledge transfer. Conduct Functionality Review Sessions.

Assists in resolving gaps, whenever possible, by recommending work-arounds, process improvements, customizations, or modifications

Provides leadership and support with setting up system tables Provides leadership and support with security setup for PeopleSoft system

Provides leadership and support with testing the PeopleSoft systemduring modeling and system acceptance to ensure that Universityrequirements 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 processimprovement opportunities.

Develops test scripts and supervises functional testing.

Io Technical Consultants

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

Responsibilities

Provides technical guidance to the Project Team

Transfers knowledge to appropriate University personnel

Assists in resolving gaps whenever possible by recommending work-arounds, process improvements or modifications

Provides options for issue resolution and identifies business processimprovement opportunities.

Assists with testing the PeopleSoft system during modeling and systemacceptance 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 thesystem, based on University requirements.


14/65


- 14 -

Functi onal Team Members

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

Responsibilities

Ensures work is being completed according to the agreed upon timelinesand 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 andprocedures 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 teamand coordinates all technical tasks and deliverables.

Responsibilities

Ensures all technical work is being completed according to the agreed upondeadlines.

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 andsoftware to support implementation is available.


15/65


- 15 -

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

Technical Team Member

UMBC Technical team members perform as project team members and as subjectmatter experts and are assigned tasks to include conversion and system set-upplanning, analysis of input from the functional staff for the development and execution oftechnical specifications and requirements (including report design and programming),conversion planning, data extractions/transfers necessary to complete conversion, anddata 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.

Appl icat ion Spec ial ists

Application specialists part icipate as project team members and as subjectmatter experts.

Responsibilities

Has knowledge of end user needs. Has knowledge of business processes & procedures.

Has knowledge of management expectations.

Communicates of business needs and gaps to team leads

Examines business processes for improvement opportunities.

Aids in and carries out testing.

Assists with data conversion/interfaces

Assists in training

Aids in report definition

Assists in building & reviewing prototypes

Database Administrator

Ensures database integrity and that data is available for retrieval.

Responsibilities include:

Sets up databases as needed by the Project Team

Develops and implements database backup and recovery procedures.

Monitors and tunes the performance of databases, as needed.

Reports status, progress, and issues to team leads in a timely manner.


16/65


- 16 -

Coordinates conversion activities

Maintains database security

Performs database capacity analysis

Responsible for monitoring version control between database instances


17/65


- 17 -

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

Projec t Scope

The following section defines the scope for the PeopleSoft Student Administrationproject.Scope management will be a major task during this implementation in order to ensure anon- time and on-budget implementation. Any changes in the defined scope of thisproject 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 scopeof the SA Project will be further refined during the Functionality Review and prototypingtasks. Any expansion of the scope will have to be approved by the ExecutiveCommittee.

Project Scope

Scope Category Preliminary Scope Specifics(Scope will be further refined during Functionality Review

and Prototyping)Version PeopleSoft Student Administration version 9.0,

including web-based self-service features

SA Modules Campus CommunityAdmissions Student Records Financial Aid Student FinancialsAcademic Advising Self Service

Interfaces Interface Number/Name Purpose

Residential Life

RLBM4319Upload of student room assignmentsfrom ORL PC based System

RLBR4334 DIEBOLD Meal Plan

Undergraduate - Recruiting And Admissions

Recruit Download

UABR1669 and OracleShadow Extracts Mailing Download

Applications

Test scores are scanned in

fsaAtlas* SEVIS Interface

Records And Registration

AXBR4548, AXBR4549,AXBR4550, AXBR4551,

AXBR4552, AXBR4553,AXBR4554, AXBR4555 NCAA and Board of Regents Reporting

RDBR2060, RDBR2061 Health Service Data

Degree Navigation

NCATE - Tracking Academic progress ofEducation Students

RDBR2034 College Park Electronic Transcripts


18/65


- 18 -

Project Scope

Scope Category Preliminary Scope Specifics(Scope will be further refined during Functionality Reviewand Prototyping)

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

AXBM4557Health Service Immunization Statusupdate to SIS

Student Financials

MVBR4008, MVBM4009Create MVA Tape for TAG Info andprocess returned Tape from MVA

ARBR4458, etc.Sallie Mae - Credit Card Paymentstowards this agency

RNBR2635 1098T

ARBM4442 Budget Payment Plan

Graduate - Recruiting And Admissions

Grad student application

Institutional Advancement

NABR2804, NABR2806 Alumni Information

Institutional Research

IRBR3001 thru IRBR3021 MHEC Reporting

IRBR3034 thru IRBR3050 SOARS Reporting

Conversions Module Data Category

SR Course Catalog

SR Schedule of Classes

AD Test Scores

CC Bio/Demo Data

CC Emergency Contact

CC Athletic Participation

CC Immunizations

SR Career/Program/Plan

FA Checklists

AA Transfer Rules

SR Enrollment

AA Test Rules

AA Transfer Credit

AA Test Credit

AA Other Credit

FA Awards

FA SAP

SR Instructor/Advisor

CC Residency

CC Service Indicators

SF Open Accounts

CC Honors and Awards

SR Comments

SR Degrees/Transcript Notes

AD Admission Applications

SR Academic Standing


19/65


- 19 -

Project Scope

Scope Category Preliminary Scope Specifics(Scope will be further refined during Functionality Reviewand Prototyping)

3rd

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

Reporting Solution, particularly with the StrategicReports. The full scope of iStrategy in reporting will notbe finalized until the Functionality Review sessions arecomplete.)

Document Imaging (DI is required for GraduateAdmissions however the specific application has notbeen selected. UMBC is exploring options to procurePerceptive Softwares ImageNow.

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

Spec i f i c I tems Exc luded f rom the In i t ia l Pro jec t Scope

Health & Immunization Tracking

Faculty Workload

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


20/65


- 20 -

Governance St ruc tur e

The following chart provides an overview of the decision process and governancestructure of the SA Project:

Consultative Committees

UMBC SA

Project Governance

Executive SA

Steering Group

Executive CommitteeEnrollment

Services

Project Team

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

Student Financial

Services

Project

Management Team

Academic Advisory

Communication &

Training

Technical Academic Advising

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

HR/SA Integration


21/65


- 21 -

The following delineates the committees involved with the decision and governance ofthe project, the personnel who compromise these committees, and their roles andresponsibilities.

Decision and Governance Committees

Roles and Personnel Responsibilities

Executive Committee:Art Johnson (Chair) John Jeffries Geoff Summers Warren DeVries Nancy Young Scott Bass Diane Lee Jack Suess Lynne Schaefer Sheldon Chaplis Nancy Young

Approves project structure, scope, timeline,and budget

Reviews implementation decisions Monitors implementation progress Resolves escalated issues involving

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

Executive SA Steering Committee:

Michael Busges (Chair) Jack SuessArnold Foelster Yvette Mozie-Ross Michael Dillon Jill Barr Gust Mitchell Tom Vogler (until 3/31/2008) Valerie Thomas Joey Harpst, ex officio

Reviews decisions made

Resolves or escalates referred issues fromProject Team or Project Management Team

Escalates unresolved issues or issuesinvolving scope, budget, or timeline toExecutive Committee; providesrecommendations where possible

Reviews business process changesrecommended by the SA Project Team toascertain if organizational changes arewarranted

Provides executive level support to the SAProject Team to remove obstacles to theprojects success

Continuously supports the high priority statusof Project

Coordinates the timely resolution of policy-related issues

Provides guidance for Projectcommunications

Monitors Project progress Balances competing interests and agendas

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

Reviews and resolves issues internal toproject

Resolves issues that do not cross functionalareas, have university-wide impact, require

staffing or reorganization, or affect budget,scope, or timeline Escalates other issues to Steering

Committee with recommendations, options,and impacts.

Communication & Training ConsultativeCommittee

Jack Suess, Chair Michael Busges

Develops and approves ChangeManagement activities for the entire campus

Consults with the Executive Steeringcommittee on change management


22/65


- 22 -



Eleanor Lewis Lee Hawthorne Calizo Yvette Mozie-Ross Susan Dawson Gust Mitchell 1 Faculty Member (from Academic Advisory

Committee) 1 Graduate Student Jennifer Kent (UG Student)

activities.Advocates appropriate resource allocation

for change management activities. Monitors success of change management

activities. Serves as link to consulting partnerexecutive management for communication.

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

Committee) 1 Undergraduate Student

Advises project team, project managementteam, and executive steering committee onissues related to student advising.

Ensures that implemented advisingfunctionality complies with campus advisingphilosophy.

Advises on development and deployment ofdegree audit.

Advocates changes in administrativepractices necessitated by Student

Administration.

Enrollment Services ConsultativeCommittee: Yvette Mozie-Ross, Chair Ralph Caretti Pam Hawley Jill Barr Beth Jones Steve Robinson Dave Hollander Dale Bittinger

Ryan Bos Stephanie Johnson

Advises project team, project managementteam, and Executive Steering Committee onissues related to the deployment of the

Admissions and StudentRecords/Registration modules

Advises on development and deployment ofSelf Service functionality for Admissions andStudent Records/Registration modules


Administration

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

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

Shuvo Dutta Gayle Chapman

Advises project team, project managementteam, and Executive Steering Committee onissues related to the deployment of theStudent Financials, and Financial Aidmodules.

Advises on development and deployment ofSelf Service functionality for StudentFinancials and Financial Aid modules


Administration

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

Advises project team, project managementteam, and Executive Steering Committee ontechnical issues such as application testing,security, network and applicationarchitecture, conversion, and modifications


23/65


- 23 -



Michael Glasser Tracy Barnes, ex officio

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

Ensure that business processes are aligned

in combined HR/SA database Facilitate decisions on shared businessprocesses and data sets

Academic Advisory ConsultativeCommittee:

Armstrong, Thomas

Berry, Melanie

Bielawski, Cathy Blessing, Lonny

(until 2/22/08)

Bulger, Michele

Burgee, Janet

Cuddy, Dennis Farrow, Scott Finkelstein,

Jonathan

Fitzpatrick, Carolyn

Gethman, Jane

Helms, Sally

Kreizenbeck, Alan

LaCourse, William

Lecompte, Susan

Lindahl, Lasse

McCann, Carole

Morgan, Leslie

O'Heir, Elaine

Redding, Tate

Rheingans, Penny

Ross, Julie

Sauter, Carrie Schwartz, Ana

Maria

Advises project team, project managementteam, Executive Steering Committee, andExecutive Committee on all implementationissues concerning Faculty, Deans Offices,and Academic Departments

Serves as liaison to campus sharedgovernance entities and other communitiesof interest

Advocates project goals to academicconstituencies


24/65


- 24 -



Stapleton, Laura

Sutphin, Kathy

Tice, Carolyn

Viancour, Teresa

Welsh, Mary

Wimpling, Kathleen

Worchesky, Terry

Escalat ion Procedures

In order to manage risks and resolve issues, both issues and decisions must be clearlydefined and documented. The following procedures will be used throughout theimplementation:

Issues logs will be used to capture and monitor all identified project issues

and risks. Each issue will be clearly named and concisely defined. Prioritywill be assessed as high, medium, or low. The issue will be assigned to aresponsible party for resolution with an estimated date of completion. Whenan issue is resolved or a risk mitigated, a description of the resolution, thedate of resolution, and where the resolution occurred will be documented inthe issues log.

Open and recently resolved issues will be captured in weekly SA Projectstatus reports. A review of these issues will be part of the responsibilities ofthe Project Team, Project Management Team, SA Executive SteeringCommittee, and Executive Committee. The Project Director will monitor thestatus 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 SAProject on track and within budget.

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


25/65


- 25 -

Project Management Procedu res

The purpose of this section is to provide a general overview of the processes and toolsto be used to ensure project performance is regularly measured so that variances areidentified and, where appropriate, actions are taken to resolve the variances. The

following practices will be deployed throughout the UMBC Campus Solutionsimplementation project lifecycle to ensure that the project plan is effectively executedand controlled.

Project Plan Management

Maintenance

The project plan will be maintained using the Microsoft Project application. This planencompasses sub-plans for each of the Campus Solutions modules: CampusCommunity, Admissions, Student Records, Financial Aid, Student Financials and

Academic Advisement. Each sub-plan contains a comprehensive list of the requiredphases, 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 projectevolves, the plan will be updated to reflect percentage complete references for eachtask, phase, or milestone. The following control processes will be used to ensure that theproject plan is regularly updated, monitored and communicated.

Project Plan Availability

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

Meeting Management

Project Meetings

Planning

Facilitators will use UMBCs Corporate Calendar to schedule meetings. For eachscheduled meeting, they will create a meeting agenda and post it in the Meeting Minutesand Agendas folder for the project on the shared network drive in advance of themeeting. The agenda will contain, at a minimum, the meeting title, date, time andlocation, meeting purpose and objectives, and the list of topics to be discussed. TheMeeting Agenda Template will be stored under the Approved Project Templates folderfor the project on the shared network drive. Agenda files will be posted and archived inthe Meeting Minutes and Agendas folder for the Project on the shared network driveusing 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 willensure the agenda is reviewed at the beginning of the meeting. The meeting facilitatoris also responsible for designating a note taker and ensuring that minutes areappropriately captured throughout the meeting.


26/65


- 26 -

Communicating Results

Meeting Minutes using the appropriate meeting Minutes Template will be created whenappropriate. The minutes will contain, at a minimum, the meeting title, date, time andlocation, meeting purpose and objectives, a list of attendees, topics discussed, and allidentified tasks and issues. The meeting minutes will be saved using the standardnaming conventions described in the Document Management sub-section of the Design

and Governance Structure section.

Types of Meetings

SA Project Meetings

Meeting Type Meeting Descript ion

Prototyping Sessions Prototyping sessions occur for each respective project modulefor the purpose of gathering detailed functional requirements anddesigning business processes to optimize the capabilities of thesystem. Io functional consultants are responsible for facilitatingthese meetings.

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

Project Management TeamMeetings

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

Issue Management/RiskMitigation Meetings

These meetings occur on an as needed basis to address issuesand risks. At a minimum, those project participants required forresolving or mitigating the respective issue or risk must attendthese meetings. The Project Director is responsible for facilitatingthese meetings.

User Review Sessions These meetings occur on an as needed basis so that theproposed system users may review system deliverables andprovide open, candid feedback about the performance of thedeliverables. Io Functional Leads are responsible for facilitatingthese meetings.

Code Design ReviewSessions

These meetings occur on an as needed basis when initialtechnical development specifications are ready for review. TheUMBC Technical Lead and the Io Technical Lead will schedule asessions to review the completed technical design specificationwith the developer assigned the task to determine if the generalapproach is correct. Other UMBC technical resources mayattend. The UMBC Technical Lead is responsible for facilitatingthese meetings.

Status Reporting

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


27/65


- 27 -

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

Weekly Status Reports

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

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

UMBC Technical staff will submit joint status reports to the UMBC TechnicalLead by the end of the week. The UMBC Technical Lead will submit aconsolidated Technical status report to the Project Director with a copy to theProject 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 allof the consultants into a single weekly status report that will be submitted tothe Project Director by Tuesday of the next week following the week in whichthe work is performed.

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

Monthly Status Reports

Using the standard Executive Dashboard Template, the Project Management Team willjointly submit a monthly status report to the Executive Sponsor. This report willsummarize the status of critical target dates and milestones, accomplishments andactivities of the past month, and any issues that still need to be resolved.


28/65


- 28 -

P R O J E C T S T R A T E G I E S

Communicat ion and Train ing P lan

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 thesame degree of understanding with the project. As a result, the project must reach out asbroadly 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 tobegin training early and let the campus gain confidence that the project will create atraining 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 thatthe processes that are being training are the processes that the campus embraces. It isimportant to understand how PeopleSoft SA will impact current business processes, anddevelop training that will encompass the changes in how people perform their workrelated to SA.

The purpose of the Communication and Training Plan is to be proactive and reach out to thecampus to keep everyone informed about the project, toensure the project team listens to theconcerns of the campus community, and to deliver training that teaches the campus not only howto 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 UMBCcommunity 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 thatlevel 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 theconfiguration and design of the software.

5) Regularly visit campus stakeholder groups to provide updates and answer questionsabout 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 inthe status of the project because they will be impacted by the implementation of the software. Thehighest level breakdown of constituent groups is by students, faculty, and staff. Within each ofthese there are multiple sub-groups to communicate with. Each high-level group has differentcharacteristics that must be addressed in the communication plan. As a consequence, severaldifferent communication mediums will be employed to effectively reach each audience.

Students

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


29/65


- 29 -

SA web site. The student newspaper will also be a medium that can be used tocommunicate what student expectations should be for SA. It is important that studentsknow 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 tostudents and maintain a public website that will be used to inform the students of projectstatus. In addition, there will be student representation on both the Communication andTraining and the Advising Consultative Committees.

In terms of sub-groups to be identified the project will work closely with the studentgovernment association (SGA) and graduate student association (GSA). In addition, theproject will seek out the campus newspaper, The Retriever Weekly, for advertisementsand updates.

One benefit of SA is that the SA implementation follows the student lifecycle. Studentsentering UMBC in Fall 2009 will begin to interact with SA during the admissions processthat occurs during AY 2008-2009. Existing students will begin to interact with SA inSpring 2009 as part of the financial aid process and advance registration. This will followwith self-service schedule adjustment and billing over the summer 2009. The newdegree audit will be introduced in Spring 2009 (for General Education) and Fall 2009 (forprogram specific requirements).

One early issue that the Communication and Training team must determine is whetherSummer Session 2009 will be handled completely by SA. If so, that requires workingclosely with CPS to train students and staff on the new processes associated withSummer 2009.

Faculty

Unlike student communication, which is focused on how to use SA self-service to handlecampus academic services, Faculty communication must occur on multiple levels and willhave different goals at different times within the project. During the first year the majorityof communication with faculty will be focused and bi-directional. In particular, we will beworking with the faculty advisory group on processes, procedures, and policies that willdefine how the system functions. The goal of the communication plan during this periodis to define the issues and opportunities and solicit feedback from the faculty. In manycases there are established constituent groups in place that we can work with. In a fewcases we will be asking the academic advisory group to help us create an ad-hoc groupof faculty to give feedback. A key responsibility of the project team is to create a sharedissue log that will document who has been involved in the decision making process, whatoptions were considered, and the reasoning for why the issue was resolved the way itwas. Our goal is to provide as high a level of transparency in the decisions made as wepossibly can.

Starting in the fall 2008 time-period we will roll out the first admissions application forgraduate and undergraduate applications. The graduate admission process is highlydecentralized on campus and each department has a graduate program director and

graduate program committee to review student applications and select those students toadmit. A risk in the project is that UMBC will be changing its document imaging systemthat is used to manage documents submitted by the applicants. One of the criticalcommunication and training activities will be working closely with the graduate programdirectors on a plan for training and communication related to the rollout of SA and thenew document imaging system.

Communication to faculty will involve a mix of electronic and face-to-face activities. Interms of electronic communication, we will establish and use email as much as possible


30/65


- 30 -

to solicit faculty involvement and to provide regular updates. In addition, we will keep aweb site with the issue log and the status of issues, who was involved in the decisionmaking, and how the decisions were finalized. We will develop a new mailing list namedSA-news that we enroll all faculty and staff into and use this for regular email updatesthat link to more detailed information on the SA web site. The SA web site will use a newcampus Wiki that will be designed to allow faculty to track issues and automaticallyreceive email when the issue document is updated.

In terms of face-to-face communication we will work with faculty leaders and ourexecutive sponsor, the Provost, to be given the opportunity to speak and differentcampus meetings where faculty are present. Groups we have identified as keyconstituent groups are the following GPDs, UPDs, Chairs, Faculty Senate, FacultySenate Executive Committee, and the deans meetings within each respective college. Ifnecessary, we will use the Academic Advisory Committee to facilitate these meetings. Inaddition, we will meet regularly with the Provost and deans so that they will be up-to-dateon 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 careto get right. Training for faculty working with the graduate admissions process will beginin 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 runthrough the end of March 2009. We will plan to offer a mix of face-to-face and self-pacedtraining facilitated by the SA User Productivity Kit (UPK) to support faculty.

Staff

Staff communication shares many similarities with faculty communication with twosignificant differences one being that it is much easier to schedule training for staffsince 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 otherhand, 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 responsibilitiesat different times within the project. During the first year the majority of communicationwith staff will be focused and bi-directional. In particular, we will be working with the staffon processes and procedures that will define how the system functions. Subject MatterExperts for various functional areas have been identified, and it is the responsibility of theproject team to insure that the right experts are involved with system configuration. Thegoal of the communication plan during this period is to define the issues andopportunities and solicit feedback from the staff in the design sessions. A key issue isgetting the right staff to participate in the design sessions. In many cases the staffinvolvement will be based on being part of a functional department or being responsiblefor that task in an academic department. One of the important responsibilities of the SAsteering committee is to make certain that at every opportunity they have to communicatewith 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 decisionmaking process, what options were considered, and the reasoning for why the issue wasresolved the way it was. Our goal is to provide as high a level of transparency in thedecisions made as we possibly can.

Starting in the fall 2008 time-period we will roll out the first admissions application forgraduate and undergraduate applications. The graduate admission process is highlydecentralized on campus and each department has a graduate program direction andgraduate program committee to review student applications and select those students to


31/65


- 31 -

admit. In many departments staff are heavily involved in the process. A risk in the projectis that UMBC will be changing our document imaging system that is used to managedocuments submitted by the applicants. One of the critical communication and trainingactivities will be working closely with the graduate program directors and their staff on aplan for training and communication related to the rollout of SA and the new documentimaging system.

Communication to staff will involve a mix of electronic and face-to-face activities. In termsof electronic communication, we will establish and use email as much as possible tosolicit staff involvement and to provide regular updates. In addition, we will keep a website 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-newsthat we enroll all faculty and staff into and use this for regular email updates that link tomore detailed information on the SA web site. The SA web site will use a new campusWiki and be designed to allow staff to track issues and automatically get email when theissue document is updated.

In terms of face-to-face communication we will work with each division head and theirrespective department heads to meet with them on a regular basis to give updates andanswer 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 anddeans so that they will be up-to-date on the project and can give updates when membersof the project are not present.

Training for staff is an important issue and one that the project must take special care toget right. Training for staff working with the graduate admissions process will begin in lateSeptember 2008 and run through Thanksgiving. Training for staff to support the courseadvisement and student registration process will begin in January 2009 and run throughthe end of March 2009. We will plan to offer a mix of face-to-face and self-paced trainingfacilitated by the SA User Productivity Kit (UPK) to support faculty.

The communication and training committee will work to establish a peer mentor networkon campus that staff can use to support each other.

Communication w ithin the Project Team

Project ParticipantsOver twenty-five individuals are working full-time on the project. The project team members spanat least a half-dozen different offices and five divisions. We want to make certain that everyoneon the project is fully informed about what other groups are doing within the project and that theproject team members are comfortable communicating project information back to their homedepartment and division.

The project management team led by Michael Bsges and including Arnold Foelster and IoConsulting Project Manager Joey Harpst will hold weekly meetings with the full project team tokeep 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 withtheir department head and give the department an update on the project. Team members areencouraged 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 wasinvolved in resolving the issue, and the reasoning behind the final decision. This level of detail willbe put on the web site and will provide the project a level of transparency requested by thecampus. In addition, this level of detail is essential in helping the training team work with the rightSubject matter experts to develop the training


32/65



The table below summarizes the communication plan:

ConstituentGroup

Information Medium Frequency Responsibi lity

UMBC Faculty andStaff

Generalinformation

Meetingminutes

Teamorganization

Referencedocuments

Timelines

Trainingschedule/Plans

FAQs

High level

status updates

SA-newsemail

Project website

Web site isupdatedweekly withstatusupdates.

SA-newsemail is sentout at leastmonthly withupdate (moreoften ifneeded).

Project DirectorTraining LeadCIOProvosts Office

Project leadership UMBC ExecutiveLeadership

Informationalbriefings on theproject progress,milestones, majorissues

Meetings withpresentationMeeting include:

PresidentsCouncil Quarterly.

VPs andDeans(Monthly)

Deans (bi-weekly)

Regularlyscheduledmeetings or asrequested

Project DirectorProvostCIO

Deans, departmentchairs, academicdirectors, faculty

Informationalbriefings on theproject progress,milestones, majorissues

Provost willupdate chairs bi-monthly atchairs meetingDeans will givemonthly updateto their chairs.Project Directorwill come inonce a semesterto answerquestion

Quarterly, onmilestones, oras requested


Staff departmentmanagers/administrativeofficers/directors

Informationalbriefings on theproject progress,milestones, majorissues, feedbacksessions,planning sessions

Departmentaland divisionalmeetings.Email andWebsite,ConsultativeCommitteeMeetings

Monthly, onmilestones, oras requested

Steering CommitteeProject DirectorCIO


33/65


Page 33 of 65

ConstituentGroup

Information Medium Frequency Responsibi lity

Faculty groups (UPDs,GPDs, Faculty Senate,Graduate and UGCouncils, InformalChairs meetings)

Informationalbriefings on theproject progress,milestones, majorissues, decisions.

Email and Website.Face to face atregularlyscheduledmeetings

As needed likely to be atleast once asemester.


Executive SteeringCommittee

Status reports foreach functionalarea prior weekaccomplishments,planned tasks notyet completed,concerns &issues, followingweek's task plan,upcoming

milestones anddeliverables.

Word documentvia email andsaved on projectshared directory

Weekly Project ManagementIo Consulting

Core Team members Details aboutproject issues,decisions, tasksto be completed,timeline, roles,responsibilities,two waycommunication,systemdevelopment,fit/gaps, testingNotification ofteam events,etc.

Issues Log

FunctionalityReviewSessions

Analysis,ModificationLog andSpecifications

Briefings by

function,technicaland projectmanagement

Weeklymeetings

Ongoing Project ManagementIo Consulting

Functional Departments

Subject Matter Expertsin design sessions

Notification ofteam events,fit/gap sessions,testing periods.Updates on

project status,timeline, rolesandresponsibilities

Email

Web Site

ConsultativeCommittees

As decisionsare made, onmilestones,quarterlyevents

Project TeamMembers


34/65


Page 34 of 65

Inter face Strategy

The new student administration application will have to receive and accept data from externalsources. These sources include vendors and other government agencies, as well as otherdepartments within the University. Although Student Administration delivers some standard

interfaces, some of the delivered interfaces will need to be rewritten to support UMBCs data inPeopleSoft. The strategy for accommodating UMBCs interfacing needs is addressed in thissection.

Approach

Key interfaces will be inventoried for each of the Student Administration modules and newspecifications created for each. The inventorys objectives include identifying interfaces thatwould become redundant in the new environment and those that need to be retained andmodified for the new system. Additionally, the inventory should categorize and prioritize theinterfaces that will be needed in the new environment. The required interfaces will vary incontent 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 externalapplications. 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/ormodules within PeopleSoft while maintaining the student administration system inproduction to support other required functionalities (e.g. the GL Interface linking PSStudent Financials with Financials).

Resources

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

Roles and Responsibilities

For each interface, the following roles need to be identified before development or configurationcan 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 interfacereplacement within PeopleSoft

Assist and advise in the development of new interface with PeopleSoft interfacedeveloper

Configure and test connectivity for development of new interface

Test and sign-off of new interface or PeopleSoft configuration


35/65


Page 35 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 Administrationspecific 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 Curr ent Interfaces

A listing of the currently known interfaces has been included in Appendix D.

Interface Tool s

There are a variety of interface tools available. Each interface will be evaluated and anappropriate tool will be utilized to develop it. Some of the possible interface tools that may beused include:

Application Messaging

Application Engine Component Interface

SQR

XML

The Io Technical Lead will work with UMBC Technical Team to determine the most appropriatedevelopment tool to use for each interface.


36/65


Page 36 of 65

Data Conv ers ion Strategy

Data conversion activities are often among the greatest challenges of an implementationproject. Irregularities in legacy data must be rectified, or the results can have a severe impact onbusiness functionality. At the initial writing of this Charter, UMBC has already undertaken anumber of initial data conversion activities. Io will come along side UMBC to complete thedetailed conversion plan. That plan should establish the objectives and criteria for theconversion effort and identifies specific data and database sources to be converted based onthese 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 thefollowing 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 appropriatetechnical staff. This data mapping activity results in information that assesses the integrity of thedata, identifies policy issues, clarifies and formulates data definitions, and provides a basis forproceeding with the conversion in a logical manner. Furthermore, it ensures that data qualitystandards will have been met.

Only data that is identified by project functional teams as critical to key business processes willbe converted into the Student Administration databases. The Project Director, in conjunctionwith 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 targetPeopleSoft database. UMBC and Io team members will have primary responsibility forextracting and converting legacy data into a PeopleSoft friendly format. UMBC staff will havethe responsibility of cleansing the data in the legacy systems.

Data Conversion Process Overvi ew

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

approval.


37/65


Page 37 of 65

Conversion Scope

It is typical to want to convert as much data into the new system as possible. However, it can becounter-productive to convert data just because it exists. Some data may be better served bynot being converted or by being transformed into another usable format. Therefore, only datathat 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 keybusiness processes or to meeting externally imposed regulations. These will be reviewed byfunctional team members in the context of the prototyping sessions for the various Student

Administration modules and the respective business processes that they support.

Selected transactional and setup data must be converted. Examples of setup data include: Course Catalog

Schedule of Classes

Examples of transactional data include:

Biographical/Demographic

Applications

Staging Area/ Oracle

Tables In

PeopleSoft

LegacySummary

Report

StagingReport

LegacySystem

PeopleSoftDelivered

Tables

Errors

Data Cleanup

UserValidation

FinalReport in

PS


38/65


Page 38 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 meetthe targeted go-live dates, which have been staggered to coincide with theadministrative 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 willinclude 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 structuredapproach to conversion efforts. A high level description of the approach the team expects tofollow 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


39/65


Page 39 of 65

Conversion Migration Path

The following diagram illustrates a migration path for moving conversion data from oneenvironment to another:

Other

Instances?

SACNV Development of

import scripts Create conversion

related objects Unit test conversion

data

Other

Instances?

SAPRD Conversion programs will

be re-executed in theproduction instance.

SACVT Data validation by end users No development occurs in this

instance


40/65


Page 40 of 65

Sof tware Modi f icat i on and Developm ent St rategy

The primary premise for UMBCs software modification and development strategy is toimplement the PeopleSoft student administration software by taking advantage of deliveredfunctionality and minimizing modifications to the delivered software.

It is highly recommended that no modifications be made to the delivered COBOL programsexcept those provided by PeopleSoft through fixes and updates. All modifications will begrouped together in a separate, custom menu structure to minimize system maintenance andupgrade efforts in the future.

There are a number of PeopleSoft customizations that are shared by several of the USMinstitutions. UMBC will leverage the experience of other USM schools that have implementedPeopleSoft student administration and share customizations used by UMBC.

Software Developm ent Standards

All software modifications and development during the implementation of the studentadministration product will be made according to a defined set of development standards,

especially regarding naming conventions. Standards are also required for coding anddocumentation. Adherence to these standards will significantly reduce the efforts required forproduction support and the efforts required to perform PeopleSoft upgrades in the future.

Existing development standards at UMBC will be reviewed and compared to developmentstandards of the consulting partner. The development standards for the project will be createdand documented based on the outcome of this review process.

Change Contro l

A method for managing change control will be required during the student administrationimplementation. 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 theHRMS and Financials implementations, UMBC wishes to integrate the STAT third party trackingproduct into the management process of all its PeopleSoft environments, including CampusSolutions. One of the great benefits of a third party product such as STAT is the ability to trackall potentially changing application items within one environment, including items commonlyreferred to as executables (COBOLs, , etc).

All errors, enhancements, design modifications, PeopleSoft delivered upgrades (includingpatches and fixes) or other system analysis requests during a PeopleSoft implementationshould be tracked. Each request is given a unique change request number to be used fordocumentation, migration, & upgrade purposes. All modifications made to the system mustreference the associated change request number. Approved development changes will have arelated Technical Specification.

At various points in the project there will be multiple developers working on the systemconcurrently. In order to prevent issues of developers trying to make changes to objects at thesame time, both locking and history for Change Control will be implemented. Each developerwill have his or her own UserID and password to work under. No changes will be made underthe generic PS UserID.


41/65


Page 41 of 65

Developm ent Terms

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

Software Developm ent Steps

The development process described in the table below will be employed whenever changes aremade to modify the PeopleSoft student administration application. This sequence helps toensure valid relationships between defined objects, such as fields, records, pages, componentsand menus.

Development Process

Development Step PeopleTool

Step 1: Design the Application None

Step 2: Create Field Definitions Application Designer

Step 3: Create Record Definitions Application Designer

Step 4:

Documents

UMBC Project Charter