umbc project charter
TRANSCRIPT
-
7/27/2019 UMBC Project Charter
1/65
PPRROOJJEECCTTCCHHAARRTTEERR
UUNNIIVVEERRSSIITTYY OOFFMMAARRYYLLAANNDD,,BBAALLTTIIMMOORREECCOOUUNNTTYYSSTTUUDDEENNTTAADDMMIINNIISSTTRRAATTIIOONNPPRROOJJEECCTT
Michael Bsges (UMBC)Joey Harpst (Io Consulting)
-
7/27/2019 UMBC Project Charter
2/65
Student Administration ImplementationProject Charter
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
-
7/27/2019 UMBC Project Charter
3/65
Student Administration ImplementationProject Charter
- 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
-
7/27/2019 UMBC Project Charter
4/65
Student Administration ImplementationProject Charter
- 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
-
7/27/2019 UMBC Project Charter
5/65
Student Administration ImplementationProject Charter
- 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.
-
7/27/2019 UMBC Project Charter
6/65
Student Administration ImplementationProject Charter
- 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/27/2019 UMBC Project Charter
7/65
Student Administration ImplementationProject Charter
- 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.
-
7/27/2019 UMBC Project Charter
8/65
Student Administration ImplementationProject Charter
- 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.
-
7/27/2019 UMBC Project Charter
9/65
Student Administration ImplementationProject Charter
- 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.
-
7/27/2019 UMBC Project Charter
10/65
Student Administration ImplementationProject Charter
- 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.
-
7/27/2019 UMBC Project Charter
11/65
Student Administration ImplementationProject Charter
- 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
-
7/27/2019 UMBC Project Charter
12/65
Student Administration ImplementationProject Charter
- 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
-
7/27/2019 UMBC Project Charter
13/65
Student Administration ImplementationProject Charter
- 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.
-
7/27/2019 UMBC Project Charter
14/65
Student Administration ImplementationProject Charter
- 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.
-
7/27/2019 UMBC Project Charter
15/65
Student Administration ImplementationProject Charter
- 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.
-
7/27/2019 UMBC Project Charter
16/65
Student Administration ImplementationProject Charter
- 16 -
Coordinates conversion activities
Maintains database security
Performs database capacity analysis
Responsible for monitoring version control between database instances
-
7/27/2019 UMBC Project Charter
17/65
Student Administration ImplementationProject Charter
- 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
-
7/27/2019 UMBC Project Charter
18/65
Student Administration ImplementationProject Charter
- 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
-
7/27/2019 UMBC Project Charter
19/65
Student Administration ImplementationProject Charter
- 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.
-
7/27/2019 UMBC Project Charter
20/65
Student Administration ImplementationProject Charter
- 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
-
7/27/2019 UMBC Project Charter
21/65
Student Administration ImplementationProject Charter
- 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
-
7/27/2019 UMBC Project Charter
22/65
Student Administration ImplementationProject Charter
- 22 -
Decision and Governance Committees
Roles and Personnel Responsibilities
Eleanor Lewis Lee Hawthorne Calizo Yvette Mozie-Ross Susan Dawson Gust Mitchell 1 Faculty Member (from Academic Advisory
Committee) 1 Graduate Student Jennifer Kent (UG Student)
activities.Advocates appropriate resource allocation
for change management activities. Monitors success of change management
activities. Serves as link to consulting 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
Advocates changes in administrativepractices necessitated by Student
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
Advocates changes in administrativepractices necessitated by Student
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
-
7/27/2019 UMBC Project Charter
23/65
Student Administration ImplementationProject Charter
- 23 -
Decision and Governance Committees
Roles and Personnel Responsibilities
Michael Glasser Tracy Barnes, ex officio
HR/SA Integration Committee Rochelle Sanders, Chair Jean Bunche Molly Burdusi Michael Busges Lisa Drouillard Shuvo 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
-
7/27/2019 UMBC Project Charter
24/65
Student Administration ImplementationProject Charter
- 24 -
Decision and Governance Committees
Roles and Personnel Responsibilities
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.
-
7/27/2019 UMBC Project Charter
25/65
Student Administration ImplementationProject Charter
- 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.
-
7/27/2019 UMBC Project Charter
26/65
Student Administration ImplementationProject Charter
- 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
-
7/27/2019 UMBC Project Charter
27/65
Student Administration ImplementationProject Charter
- 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.
-
7/27/2019 UMBC Project Charter
28/65
Student Administration ImplementationProject Charter
- 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
-
7/27/2019 UMBC Project Charter
29/65
Student Administration ImplementationProject Charter
- 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
-
7/27/2019 UMBC Project Charter
30/65
Student Administration ImplementationProject Charter
- 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
-
7/27/2019 UMBC Project Charter
31/65
Student Administration ImplementationProject Charter
- 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
-
7/27/2019 UMBC Project Charter
32/65
Student Administration ImplementationProject Charter
Student Administration ImplementationProject Charter
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
Project DirectorProvostCIO
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
-
7/27/2019 UMBC Project Charter
33/65
Student Administration ImplementationProject Charter
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.
Project DirectorProvostCIO
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
-
7/27/2019 UMBC Project Charter
34/65
Student Administration ImplementationProject Charter
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
-
7/27/2019 UMBC Project Charter
35/65
Student Administration ImplementationProject Charter
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.
-
7/27/2019 UMBC Project Charter
36/65
Student Administration ImplementationProject Charter
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.
-
7/27/2019 UMBC Project Charter
37/65
Student Administration ImplementationProject Charter
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
-
7/27/2019 UMBC Project Charter
38/65
Student Administration ImplementationProject Charter
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
-
7/27/2019 UMBC Project Charter
39/65
Student Administration ImplementationProject Charter
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
-
7/27/2019 UMBC Project Charter
40/65
Student Administration ImplementationProject Charter
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.
-
7/27/2019 UMBC Project Charter
41/65
Student Administration ImplementationProject Charter
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: