University of Virginia Student System Project Charter May 2007
University of Virginia
Student System Project Charter
May 2007
University of Virginia Student System Project
D:\726927898.doc
Page 1 of 68
4/14/2020
Table of Contents
University of Virginia Student System Project
D:\726927898.doc
Page 2 of 68
4/14/2020
University of Virginia Student System Project
D:\726927898.doc
Page 3 of 68
4/14/2020
Introduction
The University of Virginia (U.Va., “the University”) initiated the Student System Project (SSP, “the
Project”) as part of an effort to transform the student-related administrative processes that support the teaching, research, service, and health care missions of the University. The Project includes the implementation of a new student information system and dependent technologies that are mission critical, as well as activities pertaining to the reengineering of institutional policies and processes.
SSP is the third phase of the University’s Integrated System Project; Finance and Human Resource implementations were concluded in 2001 and 2002 respectively.
Although the implementation of a central vendor software application(s) is integral to its success, the
Project encompasses other important work. The purpose of the Project Charter is to provide clarity on the Project itself and to ensure consistency, quality, and integrity across both business and technical project work by providing stakeholders and the team with commonly held structure and standards. Team members and stakeholders are expected to understand and support the Project
Charter.
Internal stakeholders for this project include: students, faculty, academic administrators, departmental support staff, and central office staff; external stakeholders include: prospective students and parents, applicants, U.Va. parents, guardians, and other authorized third-party users, high school guidance counselors, and alumni.
Information and detail regarding how the University envisions serving students in the future may be found in the project’s Strategic Direction Statement: www.virginia.edu/isp/5archives/partners.html
Additional information regarding the case for the implementation of a new student information system is found in the project’s Business Case and in the proposed project budget.
The Student System Project strategic vision and mission that follow have been developed to inform executive leadership, key stakeholders, and Team members of the project’s objective.
Project Vision
To implement a system that enables all student-related administrative processes (from recruitment and application to graduation and beyond) to be carried out electronically, with only “value-added” manual effort required by students, faculty, and/or staff.
Project Mission
To provide the University community with an efficient and effective student information system that supports the University's mission, integrates with existing systems, and adapts to growth and change.
University of Virginia Student System Project
D:\726927898.doc
Page 4 of 68
4/14/2020
Project Guiding Principles
The success of the Project depends significantly upon adherence to the following guiding principles:
1.
The Student System Project supports the primary missions of the University—research, teaching, and service—as well as its strategic goals.
2.
Because the SSP is a business project and not an information-technology project, it has support at the executive level through the Integrated System (IS) Executive Committee, and serves the University with an opportunity to enable strategic business transformation.
3.
The goal of successfully implementing a new student system for the University of Virginia includes the contributions and participation of all schools, units, and programs across the
University.
4.
The new student system replaces ISIS and creates the University’s new system of record for admission, student finance, and registration and records. Systems that currently provide data to or extract data from ISIS may also be involved with the implementation of a new student information system. It is expected that the new system provides greater functionality, accuracy, depth of information, consistency, and security centrally than is possible in current shadow or supporting student systems across the University and, therefore, provides significant benefit to all participants.
5.
The Project communicates early, often, and in various modes to the audiences and groups affected by the implementation of a new student system through a defined, strategic approach to change management.
6.
The University adopts “best business practices” that have been built into the functionality of the student system software and related products, and modification of the base code is held to an absolute minimum. Modifications occur only after requests undergo a defined review process and, when deemed to be necessary, are approved by the IS Executive Committee in the context of their academic mission criticality, pertinent legal and regulatory requirements, and cost effectiveness.
7.
The governance structures of the Project insure that its strategic issues arising from the preimplementation strategic issues that are ranked “critical” must be resolved quickly and decisively prior to implementation.
8.
In order to insure resolution of key issues, the SSP recommends a prescribed timeline and default recommendation for each issue. The Team consults with appropriate stakeholders to determine the best solution for the greatest number of stakeholders; however, in the absence of a decision within the prescribed timeline, SSP’s default recommendation is adopted. The
IS Executive Committee retains authority to review and revise the SSP’s drafted default positions.
9.
Rankings of strategic issues are continually evaluated and resolved accordingly and in light of project dependencies.
University of Virginia Student System Project
D:\726927898.doc
Page 5 of 68
4/14/2020
10.
Decisions are made in a timely manner and in accordance with defined protocols.
11.
The Project may recommend organizational changes, including reallocation of financial and human resources in support of re-engineered and efficient processes, to the IS Executive
Committee for review and approval.
12.
Systems initiatives, improvements, new projects, existing systems or enhancements that represent significant investments by the University and that compete for the same set of resources related to the student system, including “bolt-ons” to the SSP software and database and/or independent initiatives in departments, schools, or programs across the
University, are not developed during the SSP development and implementation timeline without approval of the IS Executive Committee through a defined process and format.
13.
An established methodology is used for completing and documenting implementation tasks.
14.
The software is tested thoroughly to ensure operational sufficiency and security, as well as regulatory and legal compliance.
15.
Sufficient resources are committed to technical infrastructure, user-training, reporting, and data conversion, as appropriate, prior to, during, and after implementation.
16.
The technology is implemented to:
Improve student service delivery
Provide a secure and scalable environment for self-service
Reduce paper-based processes
Reduce the need for shadow systems, where appropriate
Increase on-line access to information in a secure environment
Support one level of approval as the standard for transactions, where appropriate
Standardize administrative processes, where appropriate, so that they can be effectively supported in a central system
Standardize data definitions, where appropriate, to improve reporting
Support compliance with laws and regulations
17.
Where feasible options exist, the implementation alternative that enables the greatest flexibility for future enhancement is selected in order to position the University to respond to change.
University of Virginia Student System Project
D:\726927898.doc
Page 6 of 68
4/14/2020
Project Timeline
Admissions/
Campus
Community
2007 2008 2009
Preview
Analyze & Design
Configure & Develop
Test & Train
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct
Student
Records/
Academic
Advising
Financial
Aid
Student
Financials/
University
Services
Color Key
Deploy & Optimize
Preview
Analyze & Design
Configure & Develop
Test & Train
Deploy & Optimize
Preview
Analyze & Design
Configure & Develop
Test & Train
Deploy & Optimize
Preview
Analyze & Design
Configure & Develop
Test & Train
Deploy & Optimize
Project Phase: Goals and Major Activities Associated with Phase*
NOTES:
*Phase transition:
Preview and Plan: Develop understanding of functionality; broad representation of functional stakeholders participate in preview sessions
Analyze and Design: Identify gaps and determine approach to gaps; small groups of no more than 10 subject matter experts/decision makers, as appropriate, and the functional SSP team members participate in "Interactive Design and Prototype" (IDP) sessions
Configure and Develop: Configure software to meet University's needs; SSP functional teams are responsible for setup while working in consultation with small groups of subject matter experts/decision makers, as appropriate
Test and Train: Test software, develop training materials, and train users; SSP team and stakeholders, as appropriate, are involved in multi-level system tests and user training
Deploy and Stabilize: System functionality available to users; troubleshoot issues as they arise; SSP team is responsible for creating rollout plans and for coordination with distributed functional/technical support in schools/departments/affected units
Toward the end of each project phase, a set of deliverables for each module will be developed by the SSP team and the small group of subject matter experts/decision makers affiliated with that module. These deliverables will be made available for review and comment through a "Tollgating Process" to a broader stakeholder population (CASS members, LPG members, etc.), as appropriate.
*ISIS rolloff: It is anticipated that ISIS and the mainframe will be maintained for no more than one year after project completion.
University of Virginia Student System Project
D:\726927898.doc
Page 7 of 68
4/14/2020
Project Goals and Performance Measures
The following table presents project goals and metrics to measure success in achieving those goals.
Category
Overall System
Goals
Overall System
Goals
Overall System
Goals
Overall System
Goals
Item
1.1.1
1.1.2
1.2
Responsibility
1.1 Project Leadership
Team
Business Analyst
Associate Director
Goal
The overarching goal of the
Student System Project is to provide a student information system of record that is integrated, flexible, scaleable, accessible, and secure. This system will be able to change and grow to support the University’s priorities and needs over time.
N/A
A detailed project plan will establish the system parameters. The goal will be accomplished by successfully executing the project plan.
Before project end, an approach will be developed to address future system changes, enhancements, maintenance, and growth.
Metric
Complete the Student System Project on time and within budget and meet the scope set out by the project plan.
(Project tracking tool, reach 100% completion.)
Establish a standing process and committee that will evaluate ongoing system needs, make recommendations, and set priorities for future development. (Document process plan and committee membership.)
Ensure that the portal has appropriate access points for all user groups.
(Checklist of user groups, 100% coverage.)
University Services
Lead
The student system will be used by a wide array of constituents, within and outside the University
(prospects, students, faculty, staff, and administrators).
These constituents will have online access to a comprehensive range of student-related services through one-stop selfservice. The system will accommodate all intended users.
University of Virginia Student System Project
D:\726927898.doc
Page 8 of 68
4/14/2020
Category
Overall System
Goals (cont.)
Process
Improvements
Process
Improvements
Communication
Item
1.3
2.1
3.1
Responsibility
Business Analyst
Functional Analyst
2.2 University Services
Lead/Functional
Analyst
Communications
Manager
Goal
The student system will be implemented to incorporate as much delivered missioncritical functionality as possible. All requests for mission-critical and other functionality will be considered and evaluated in the context of the guiding principles and project scope.
Business and administrative processes will be improved to increase effectiveness and reduce redundancy.
Processes will be standardized; the number of multiple and overlapping processes will be minimized.
The system will support interactive, real-time transactions and whole processes that will save time and effort.
Metric
Ensure that all requests are addressed, track dispensation, and communicate outcomes to requestors and relevant stakeholders.
(Document the process, requests, decisions, and communications.)
Reduce the number of redundant processes by 10 percent. (Baseline:
As-Is processes by school/department for an identified set of processes for each functional area. Result:
Comparison to the implemented processes for the set.).
More functionality will be available online through student system self service. Online functionality will increase by 25 percent. (Baseline:
The number of pre-implementation processes available through the website functional area. Result:
Comparison to the number of postimplementation processes in self service.)
The Student System Project will effectively communicate to key stakeholders the guiding principles, project progress, implementation decisions, system configuration, context for required process changes, and training opportunities.
This communication will be a critical success factor.
Ensure stakeholder satisfaction with communication throughout the
Project. Achieve a 3.5 satisfaction rate on a 5.0 scale (5 being very satisfied). (Conduct periodic audits of key stakeholder groups.)
University of Virginia Student System Project
D:\726927898.doc
Page 9 of 68
4/14/2020
Category
Communication
Communication
Reporting
Transition/
Training
Item
3.2 Strategic Planning
3.3
Responsibility
Manager
Business Analyst
Goal
Electronic communication
(e-mail or online notifications) will be established as the primary communication method.
This will improve communication, accelerate delivery, and increase reliability.
.
Student self service will provide for proactive electronic communications that will push information and/or initiate transactions.
This functionality will keep processes moving forward.
Metric
Reduce the number of key communications sent by standard mail by 20 percent. Increase the number of e-mail or online notices by
20 percent. (Baseline: Preimplementation counts for an identified set of communications.
Result: Post-implementation comparable counts.)
Achieve a response rate to an actionable set of online communications of at least 30 percent. (Ratio of the number of responses to the number of actionable communications over a fixed time period.)
4.1 Technical Integration
Lead
The system reporting structure will provide multiple levels of reporting
(mission-critical, predefined, ad hoc, custom).
Reporting processes will be improved by identifying users, assessing needs, and developing solutions that work with the system. These processes will provide flexibility, automation, and relevant data.
Establish a framework to identify, review, and categorize reporting needs and determine the best method of fulfillment. (Document the identification and review process.
Then identify priorities/needs and record solutions.)
5.1 Strategic Planning
Manager
Users will be thoroughly trained to use the student system. They will know what the system offers and will understand the information stored in the system.
Require all users to participate in training in multiple formats
(classroom-based seminar, online tutorial).
(Training completed and confirmed in order to receive access to the system.)
University of Virginia Student System Project
D:\726927898.doc
Page 10 of 68
4/14/2020
Category
Transition/
Training
Transition/
Training
Item Responsibility
5.2 Strategic Planning
Manager
5.3 Communications
Manager
Goal Metric
Users will be provided the tools and training to become self-sufficient and proficient.
Users will actively use the system.
Reduce help desk calls by 30 percent by one year after project completion.
(Baseline: Daily help desk call volume six weeks after project completion. Comparable: Daily help desk call volume one year after project completion.)
Users will have a positive view of the new student system and affirm project success
Conduct an evaluative survey one year after module and project completion to gauge user impressions and experiences. (Qualitative measure of project success.)
Conduct a quantitative survey one year after module and project completion to measure project success as defined by the vision, mission and goals. (Quantitative measure of project success.)
Decision Principles
System functionality is implemented in accordance with Project Guiding Principles (see #6 on page 5).
Specifically, decisions are informed by:
Academic Mission Criticality o Serves as the primary guideline in determining how the application is implemented. o Refers to functionality that currently exists in or is connected to a central system to support the academic mission of the University.
At a minimum, the new student system will address this functionality in the context of the o delivered software capabilities.
Legal and regulatory requirements o When applicable, the source of the legal or regulatory requirements will be cited to justify a software change that impacts the University’s ability to apply future vendor software releases. o Legal counsel, records management, and internal audit are consulted regularly.
Cost effectiveness o Is assessed based upon an approach adopted by the Project and applied consistently across all evaluations. The cost effectiveness assessment will consider, for each alternative: (1) impact on o operational costs, (2) the incremental costs of its design, development, implementation, and ongoing maintenance, and (3) the benefit it produces system-wide.
Alternatives that produce benefit in proportion to the required investment will be given priority. o o
Software changes that affect the University’s ability to apply future enhancements and upgrades will be justified primarily on cost-effectiveness.
Interface enhancement, to the extent that it is included in the scope of the Project, will be justified primarily on cost-effectiveness.
University of Virginia Student System Project
D:\726927898.doc
Page 11 of 68
4/14/2020
The implementation will strive to provide functionality equal to or greater than what currently exists, where consistent with redesigned processes and within approved project scope, timeline, and budget—current practices, in and of themselves, do not serve as justification for future processes. The implementation also will consider upgrade plans published by the software vendor when analyzing the appropriateness of proposed software changes.
Software change decisions that cannot be made by the team but that are deemed critical or high priority will be brought to the attention of the IS Executive Committee for consideration.
Student System Project Governance
The successful completion of the Student System Project requires the involvement and participation of a wide variety of dedicated personnel throughout the University. The Organizational Structure diagram and this
University of Virginia Student System Project
D:\726927898.doc
Page 12 of 68
4/14/2020
section of the Charter outline the roles and responsibilities of each governance structure and major partner in the implementation plan, and their participation in decision-making processes.
University of Virginia Student System Project
D:\726927898.doc
Page 13 of 68
4/14/2020
Organizational Structure
School Deans
STUDENT SYSTEM PROJECT
GOVERNANCE & ORGANIZATION
Vice President & Provost
Senior Associate Provost
Student System Project Leadership
Team
Integrated System Executive Committee
Sponsorship & Change Management
Scope
Policy
IT Relationships
Institutional Communications
Institutional Decisions
Policy Review Group
Deans’ Designees
Review and recommend on policies and academic issues
Student Advisors to the Student System
Student Self Service,
On-line Help, End
User Functionality
Faculty Advisors to the
Student System
Academic Support/
Advising Issues, Training
Approach for Faculty
Core Advisors to the
Student System
System Issues
Process Redesign
Security & Access
Warehouse & Reporting
Technical Advisors to the Student
System
Technical Issues,
Supporting Projects,
Technical Impacts
Student System
Advisory Committee
Communications
Testing & Training
Policy Review Group
VPs’ & Provost Designees
Review and recommend on policies, critical & high priority issues
University of Virginia Student System Project
D:\726927898.doc
Page 14 of 68
4/14/2020
Roles and Responsibilities
Integrated System Executive Committee
The Integrated System (IS) Executive Committee provides oversight, guidance, and approval for all major elements of the Student System Project. The IS Executive Committee works closely with the Project Director and Associate Director in reviewing project plans, scope, and budget and facilitates the resolution of issues to ensure successful completion of the initiative.
In this capacity the IS Executive Committee is responsible for:
Approving the project scope, strategies and plan, allocating resources, and monitoring budgets to ensure the successful completion of the Project
Engaging in executive activities related to change management
Resolving certain issues and policies pertinent to the Project
Ensuring that an appropriate project priority is established and that resources are allocated to the
Project
Ensuring the timely and effective cooperation of all schools, departments and other operating units of the University in providing information and other required assistance to the project teams
Helping to remove obstacles and solve problems that are beyond the control of the Project Director and Team
Membership:
Executive Vice President and Chief Operating Officer
Vice President and Provost (Chair)
Senior Vice President for Development and Public Affairs
Vice President and Chief Financial Officer
Vice President for Management and Budget
Vice President and Chief Information Officer
Vice President and Chief Student Affairs Officer
Vice President for Research and Graduate Studies
Student System Policy Review Group (PRG)
The Policy Review Group, which includes a group of Vice Presidents’ designees and a group of Deans’ designees, works both individually and jointly with the Project Director, Associate Director, Strategic
Planning Manager and the SSP Team, as well as with working groups of stakeholders, to assist in decisionmaking processes that support the SSP. PRG members are experienced decision makers who understand transformational approaches to problem-solving and the history and culture of the University; they appreciate and respect the nexus of policy and operations.
In this capacity the Student System Policy Review Group is responsible for:
Serving as effective messengers both to the vice presidents and deans they serve and to the departments that report within their vice presidential or school structure
Working with other designees and SSP representatives to review recommendations brought forward by the SSP Project Leadership Team, as appropriate to the issue under consideration, before decisions are made by the IS Executive Committee
University of Virginia Student System Project
D:\726927898.doc
Page 15 of 68
4/14/2020
Core Advisors to the Student System (CASS)
CASS is comprised of one representative from each of the ten schools of the University and from selected administrative offices involved in student processes. Please refer to Appendix One for the CASS Guiding
Principles. The goals of CASS are:
Providing leadership, assistance, and advice to the Project Director, Associate Director, and the SSP
Team in change management activities associated with the Student System Project
Providing input and feedback to the SSP Team
Reviewing and reacting to recommendations from the SSP Team related to changes in policies, procedures, or strategic issues relate to the Student System Project
Providing guidance related to institutional issues related to the Student System Project.
Faculty Advisors to the Student System (FASS)
FASS is comprised of faculty representatives from each of the ten schools. The goals of FASS are:
Providing advice on current and anticipated issues related to academic support functions such as academic advising
Serving as an information conduit, to inform colleagues and co-workers within units and schools about the progress and status of the Student System Project.
Contributing to the development of training approaches for faculty
Technical Advisors to the Student System (TASS)
TASS is comprised of representatives from the Student System Project, Information Technology and
Communications, and Integrated System Deployment and Support. The goals of TASS are:
Monitoring the status and progress of technical elements of the Student System Project in the context of the Guiding Principles and project plan
Assisting in evaluating options and working resolution of current and anticipated technical issues that meet the objectives of the Student System Project
Planning technical initiatives and scheduling resources for technical activities in accordance with
Student System Project timelines and objectives
Providing information on other technical efforts which are external to the Student System Project, but which might have an impact on the Project in some way
Local Project Groups (LPGs)
Local Project Groups within each school/unit are comprised of subject matter experts who will be asked to contribute functional and technical knowledge of current systems and expertise in their respective fields to the
Student System Project. Members of each Project Group may be expected to focus on project assignments for sustained periods of time, depending upon the project schedule. Their commitment and dedication to the
Project are essential to its success.
University of Virginia Student System Project
D:\726927898.doc
Page 16 of 68
4/14/2020
Local Project Group members may be asked to:
Identify current business processes
Map new processes based on delivered functionality in PeopleSoft
Identify and participate in development of web front-ends to PeopleSoft
Identify and facilitate the implementation of mission critical and other interfaces, as appropriate
Identify reporting requirements and priorities, participate in the development of reports
Participate in data mapping and conversion to new structures
Participate in planning and activities associated with integrated data processing, where required
Insure accessibility of data by participating in development of schema related to security, access, and
roles and responsibilities
Participate in the development of training materials and participate in “train the trainer” activities
Student Advisors to the Student System (SASS)
The membership of SASS will be determined at a later date. The goals of SASS are:
Providing feedback on requirements and proposed functionality of the new student system
Assisting in evaluation of student self-service and on-line help options
Providing input on student expectations, student views, and student use of emerging technologies
Governance Meetings Framework
IS Executive Committee
The Project Director reports project status to the IS Executive Committee. An electronic copy of the report is stored in the University Readiness database. The Project Status Report includes:
Accomplishments since the last report
Plans for the next reporting period
Significant issues and risks and actions taken
Additional comments
Attendees
IS Executive Committee
Project Director
Associate Director
Communication Manager
Standard Agenda
Discussion items
Significant issues and risks, costs, implications, alternatives considered, actions taken
Accomplishments
Plans
IV&V reporting
Timing and Delivery
Meetings monthly
Core Advisors to the Student System
Attendees
CASS members
Project Director
Associate Director
Standard Agenda
Discussion items
Change management activities
Timing and Delivery
Meetings monthly or as required
University of Virginia Student System Project
D:\726927898.doc
Page 17 of 68
4/14/2020
Communication Manager
System issues
Procedural Issues
Policy Review Group
Attendees
VPs’ and/or Deans’
Designees
Project Director
Associate Director
Strategic Planning Manager
Standard Agenda
Discussion items
Scope issues
Policy issues
Faculty Advisors to the Student System
Attendees
FASS members
Project Director
Associate Director
Communication Manager
Registration & Records Lead
Standard Agenda
Discussion items
Change management activities
Policy/procedure changes
System issues
Technical Advisors to the Student System
Attendees
Technical Integration Lead
TASS members
Project Director
Associate Director
Strategic Planning Manager
Standard Agenda
Discussion items
Significant issues and risks, implications, alternatives considered, actions taken
Accomplishments
Plans
Issue review
Project planning and coordination
Change management
Timing and Delivery
Meetings as required
Timing and Delivery
Meetings as required
Timing and Delivery
Meetings as required
University of Virginia Student System Project
D:\726927898.doc
Page 18 of 68
4/14/2020
Student Advisors to the Student System
Attendees
University Services Lead
SASS members
Project Director
Associate Director
Strategic Planning Manager
Standard Agenda
Key issues
Planning
Focus/user group activities
Local Project Groups
Attendees
Team leads or other SSP leaders, as appropriate to the topic
Local project group(s), as appropriate to the topic
Standard Agenda
Key issues
Validations and cautions
Next steps
Timing and Delivery
Meetings as required
Timing and Delivery
On an as-needed basis, dependent upon the topic
University of Virginia Student System Project
D:\726927898.doc
Page 19 of 68
4/14/2020
Student System Project Team(s)
The Organizational Structure diagram below and this section of the Charter outline the roles and responsibilities of each team member and the composition and responsibilities of each team within the SSP.
University of Virginia Student System Project
D:\726927898.doc
Page 20 of 68
4/14/2020
Organizational Structure
SSP Project Team
Assistant Director
IS Customer
Support
May 2007
Communications
Manager
Vacant Assistant to the Director
Assistant to the
Assoc. Director
Strategic Planning
Manager
Instructional
Designer
Instructional
Designer
Business Analyst
Staff Assistant
Vice President and
Provost
Senior Associate Provost
Project Director
Associate Director
Special Projects
Manager
LEGEND
Vacant
Position
University
Readiness Team
Members
Collaboration
Direct Report
Occupied Position
Local Support
Partner (LSP)
LSP
Technical
Integration Lead
ITC
Manager
Mainframe
Systems and ISP
Infrastructure
ITC
Manager
Application &
Data Services
Functional
Analyst
Admission
Team Lead
Functional
Functional
Analyst
Registration & Records
Functional
Analyst
Functional
Analyst
Student Accounts
Team Lead
Student Accounts
Functional
Analyst
Student Finance
Financial Aid
Functional Analyst
University Services
Team Lead
Comm. Systems
Programmer
Dependent
Technologies Lead
Functional
Analyst
Developer
Technical
Coordinator
Developer
Developer Developer
Functional
Analyst
Functional Analyst
Technical
Analyst
Developer
Functional Analyst
Technical
Analyst
Technical
Analyst
Senior
Technical
Analyst
Senior
Technical
Analyst
Information/
Reporting Lead
Senior
Technical
Analyst
Application
DBA
Senior
Technical
Analyst
Application
DBA
Portal
Administrator
System DBA
System
DBA
Security
Administrator
University of Virginia Student System Project
D:\726927898.doc
Page 21 of 68
4/14/2020
Roles and Responsibilities: Project Leadership
Project Director
The Project Director is responsible for the success of the Project and for fulfilling the charge of the IS
Executive Committee—to conduct a successful system implementation, on time and within budget. The
Project Director refers to the IS Executive Committee for approval for issues concerning:
Major changes to project scope
Strategic decisions related to University policy
Decisions regarding alterations to the initial elements of the vendor-supplied software package(s) as delivered
In this capacity the Project Director is responsible for:
Acquiring all resources needed for the successful completion of the Project. These include: o Financial resources o Human resources, both from within the University and from consulting firms and other external sources o Training and other professional development activities related to the Project for involved personnel o Software, hardware, etc. o Implementation consulting and other consulting services o Other goods and services
Leading, with the Department of Procurement Services and others, as appropriate, all contract negotiations for consulting services, hardware, software, etc.
Serving as the official University contract administrator for all executed SSP contracts
Coordinating responses from SSP with the Virginia Information Technology Agency (VITA), the
State project review committee, etc.; and coordinating these efforts with others at the University who have primary responsibility for State relations
Communicating both within the University community and outside the University community about the goals, objectives, status, and plans of the SSP (shares this role with the Associate Director and SSP
University Readiness Team)
Approving all resource allocation decisions that affect the project budget, including both personnel
(the number and type of) as well as all goods and services decisions (shares responsibility with the
Associate Director (U.Va.))
Approving all elements of management of the Project, including creating and maintaining the project schedule, assuring the timeliness and quality of all deliverables; has the primary responsibility for this function (shares responsibility with Associate Director and Consulting Project Manager)
Conducting all activities consistent with the approved project plan and project budget
The Project Director reports to the Senior Associate Provost who, in turn, reports to the Vice President and
Provost.
Associate Project Director
The Associate Project Director (Associate Director) shares responsibility with the Project Director for the success of the Project. The Associate Director collaborates with the Project Director with project management
University of Virginia Student System Project
D:\726927898.doc
Page 22 of 68
4/14/2020
and in the definition of core processes for both the pre-implementation and implementation phases of a new
University-wide student system at the University of Virginia.
In this capacity, the Associate Director is responsible for:
Developing and executing the University’s strategic plan regarding the pre-implementation and implementation of a student systems replacement. Key milestones include issuing an RFP and selecting the appropriate vendor
Developing and overseeing the change management strategy
Overseeing project management, including pre-implementation plans and documentation, the development and maintenance of the project schedule and assuring the timeliness and quality of all team and other assigned deliverables
Managing the pre-implementation/implementation teams
Ensuring that the Project is well-managed and completed on schedule and within budget
Identifying and hiring the core members of the pre-implementation/implementation team in consultation with the Project Director and the oversight committee
Collaborating with the Project Director and the other members of the pre-implementation team, as well as with the oversight committee, the systems process owners, users, and other key stakeholders inside and outside the University, including, but not limited to, U.Va. faculty, staff and students, administrative staff, and state oversight committee(s)
Contributing to contract negotiations for software, consulting, technical and other resources for the
Project.
Developing critical communications to the oversight committee and other core stakeholders at the
University, including the Provost and vice presidents
Advising the Project Director with regard to the development, management, and approval of highlevel budget(s) supporting the pre-implementation/implementation effort
Building consensus among system stewards/process owners, other key stakeholders, and customers regarding project scope
Managing the pre-implementation/implementation team’s change control process to ensure that the costs and benefits of any proposed changes in the scope of the Project, tasks, or specifications, are weighed carefully in light of the overall goals and objectives of the preimplementation/implementation effort
Leading the pre-implementation/implementation team in examining administrative processes within the areas affected by the overall core system replacement effort at the University
The Associate Director also directs the efforts of the University Readiness Team.
The Associate Director reports to the Project Director.
Technical Integration Lead
The Technical Integration Lead is responsible for the success of the Technical Teams and all technical aspects of the SSP for the duration of the Project. The Technical Integration Lead ensures that the work of all technical teams is conducted within scope and executed according to prescribed steps in the established methodology, and that other tasks are completed throughout all phases of the implementation as needed (i.e.,
Plan and Preview, Analyze and Design, Configure and Develop, Test and Train, Deploy and Optimize).
University of Virginia Student System Project
D:\726927898.doc
Page 23 of 68
4/14/2020
In this capacity the Technical Integration Lead is responsible for:
Coordinating and facilitating the provision of all technical resources, including technical staff, hardware, and software
Working with team leads to recruit and screen applicants; evaluating technical staff
Directing all technical activities for the SSP, based on the project plan, including software configurations and modifications, report development, data conversion, interface development, workflow development, Web enablement, security implementation, data warehousing, version control, quality assurance, disaster recovery, etc.
Acting as a liaison to ITC, software and third party vendors, the implementation consulting partner, and others to meet all technical goals and deadlines of the SSP
Ensuring that the project's technical work environment is maintained (project servers, staff workstations, security, etc.)
Chairing the Technical Advisors to the Student System (TASS) group
Identifying and resolving technical issues as they arise
Collaborating with the Associate Director to ensure issues are resolved in a well informed manner
Serving as a reviewer in accordance with the Quality Plan
Executing the project methodology for technical aspects of the Project
Directing the day-to-day assignments of the Technical Team Coordinator, Communication Systems
Programmer, Data Warehouse Lead, and the Dependent Technologies Lead
Serving as a coordination point between these technical resources and the Associate Director
Ensuring that all technical issues are identified and resolved or escalated in a timely manner
Communicating project issues/information to project leadership and ITC staff, as appropriate
Conducting all activities consistent with the approved project plan and project budget
Becoming familiar with the technical capabilities and features of all software and third party products that relate to applicationconfiguration and development
Reviewing programming and testing activities of technical staff (including program analysts/modifiers, interface programmers/analysts, conversion programmers/analysts, unit testers, system integration testers, report designers, and data warehouse builders)
Balancing the workload (making and monitoring assignments) of the staff in the technical pool
Participating in other core activities
Supervising the following members of the SSP Team: o Technical Team Coordinator o Communication Systems Programmer o Data Warehouse Lead o Dependent Technologies Lead o Local Support Partner o Technical Lead Consultant
The Technical Integration Lead reports to the Associate Project Director.
University of Virginia Student System Project
D:\726927898.doc
Page 24 of 68
4/14/2020
Roles and Responsibilities: Project Leadership Support
Project leadership support includes those positions within the Project that provide key contributions, information and advice to project leadership.
Communications Manager
The Communications Manager is responsible for designing, implementing, and maintaining a comprehensive communications effort for the Student System Project. The Communications Manager works directly with the Project Director and the Associate Director on training and communication issues.
In this capacity, the Communications Manager is responsible for:
Serving as a key communication link to faculty, staff, and others about various project issues and concerns
Devising and executing a communication plan for the project
Constructing clear and consistent messages about the project and ensuring that the messages are disseminated to the appropriate audiences through appropriate vehicles
Managing the project website
Producing and distributing regular updates on project progress
Producing and distributing reports and other documents as required
Working with University Relations staff to help communicate the message to internal and external audiences
Assisting with meetings, including agenda review and discussion, scheduling, and communication
Assisting in the development of training materials
Identifying opportunities to present information about the project and to gather feedback
Assessing the effectiveness of communication strategies on a regular basis
Conducting all activities consistent with the approved project plan and project budget
Participating in other Project Leadership Team activities
Serve as resource to internal teams, providing assessment of and changes associated with business process redesign
Serving as a resource to SSP stakeholders within the University community
Serving as liaison with the Office of Learning and Development to insure all training requirements are met
Assessing program needs in various areas (e.g., change readiness, risk, learning requirements, etc.)
In support of Project Director and Associate Director, manage the following activities in cooperation with the Strategic Planning Manager: o Implementation of change management projects, including approaches to the various cultures throughout the University o Relationships with stakeholders and decision makers o Assessment and approaches to organization impacts o Knowledge transfer
The Communications Manager also serves as a leading member of the University Readiness Team. In this capacity, the Communications Manager serves the SSP in support of all SSP team members.
The Communications Manager reports to the Associate Project Director.
University of Virginia Student System Project
D:\726927898.doc
Page 25 of 68
4/14/2020
Strategic Planning Manager
Participate in the development of a comprehensive approach to organizational change resulting from the SSP with project leaders and members of the University Readiness Team
Serve as a resource to project leadership, the University Readiness Team, the project team, key stakeholders, and key decision makers to support and assess the effectiveness of organizational change
Prepare appropriate plans, position papers, and recommendations in support of the project and in response to social, economic, and political trends within and outside the institution
Advise the Project Director and Associate Director of trends, strengths, weaknesses, opportunities, and threats that pertain to the project
Assess change readiness, risk, and learning requirements related to SSP in various areas
Coordinate with the Communications Manager to develop strategic approaches to the identification of appropriate venues and effective media that engage target audiences during the change process
Redesign existing positions, design new jobs, and outline specific steps to promote the successful transition of employees to the new system in cooperation with Human Resources
Assess the effectiveness of activities related to University readiness
Work with instructional designers
Participate in other project activities as necessary
Hold meetings as necessary to report on findings as they relate to University readiness
Execute other duties as assigned
The Strategic Planning Manager reports to the Associate Project Director.
Business Analyst
The Business Analyst works with the Associate Director and the Project Management Consultant on all aspects of project management.
In this capacity the Business Analyst is responsible for:
Providing support to the Project Director and Associate Director in developing budgetary requirements for resources for the Project. Resource allocations include the number of and type of personnel, as well as all goods and services decisions
Sharing responsibility with both the Project Director and the Associate Director for all project management duties, such as coordinating, maintaining, and making changes in the project schedule, ensuring the timeliness of deliverables and adherence to the Quality Plan and the Testing Plan, maintaining, updating, and analyzing the project schedule, , analyzing progress on tasks and deliverables to ensure that the Project stays on schedule, and notifying appropriate individuals of issues or problems with the project schedule
Managing issue tracking, to include maintaining a database of project issues, monitoring all issues to ensure that they are resolved in a timely manner, and recording all solutions
Managing financial matters, to include preparing the annual operating budget, performing on-going analysis of the project budget and expenditures, and assisting with preparation of financial reports required by the Board of Visitors, the SSP Steering Committee, the IS Executive Committee, the
Project Director, and/or the project teams, as appropriate
Developing project financial policies and procedures
Preparing and monitoring of risk management documents
Collaborating with the Technical Integration Lead on testing and configuration management efforts
University of Virginia Student System Project
D:\726927898.doc
Page 26 of 68
4/14/2020
Preparing and maintaining financial documentation as required
Collecting, analyzing, and reporting metrics documentation as defined in the project Charter
The Business Analyst reports to the Associate Project Director.
Special Projects Manager
The Special Projects Manager conducts a variety of operational studies and special projects for the Student
System Project. These studies and projects will provide vital information for the SSP itself and for the other members of the Project Team. These studies and projects may fall outside the purview and responsibilities of the other members of the Project Team, but they share the common property of supporting the activities of all other Team members, as well as all aspects of the SSP.
In this capacity, the Special Projects Manager is responsible for:Analyzing a variety of data, drawing conclusions from these data, and presenting these conclusions clearly and concisely to others
Planning, organizing, and conducting a variety of activities and projects aimed at assessment, comparison, and analysis of student information systems, their processes, requirements, policy issues, and details
Coordinating the logistics associated with these activities and projects, including software support, data collection, travel arrangements, and reporting functions
The Special Projects Manager also serves as a member of the Project Leadership Team. In this capacity, the
Special Projects Manager serves the SSP in support of all SSP team members.
The Special Projects Manager reports to the Associate Project Director.
Roles and Responsibilities: Project Administrative Support
Staff Assistant
The Staff Assistant works closely with the Business Analyst in supervising the administrative management of day to day office functions. These functions include:
Analyzing the variety of business and administrative processes needed for the day to day functioning of the SSP; this includes fiscal processes, staffing requirements, and records maintenance, physical office space, furniture, supply needs, and administrative office support.
Planning, organizing, and presenting conclusions regarding support staffing and office management of the SSP to the Business Analyst.
Working with the Director, Associate Director, and Business Analyst to coordinate the administrative office activities that support the work of these individuals.
Managing the administrative assistant support staff in collaboration with the Business Analyst, SSP
Director, and Associate Director.
The person in this position also applies knowledge of University programs, operations, policies and procedures related to SSP administrative and support services, to ensure that the project operates at optimum efficiency. This employee will be responsible for planning and coordinating these services.
The Staff Assistant reports to the Business Analyst.
University of Virginia Student System Project
D:\726927898.doc
Page 27 of 68
4/14/2020
Assistant to the Director
The Assistant to the Director supports the Director of the Student System Project.
In this capacity, the Assistant to the Director is responsible for:
Providing administrative support of a specialized nature in an academic environment
Working with teaching faculty, students, and other administrative staff
Applying policies and procedures for a program or activity and using independent judgment
Preparing forms, reports, manuscripts, e-mail, and general correspondence using computer software; maintaining inventory, records, and/or logs; scheduling activities, including travel arrangements; creating and maintaining databases and/or spreadsheets; providing customer service and general office support duties
The Assistant to the Director reports to the Project Director.
Assistant to the Associate Director
The Assistant to the Associate Director supports the Associate Project Director
In this capacity, the Assistant to the Associate Director is responsible for:
Providing administrative support of a specialized nature in an academic environment
Working with teaching faculty, students, and other administrative staff
Applying policies and procedures for a program or activity and using independent judgment
Preparing forms, reports, manuscripts, e-mail, and general correspondence using computer software; maintaining inventory, records and/or logs; scheduling activities, including travel arrangements; creating and maintaining databases and/or spreadsheets; providing customer service and general office support duties.
The Assistant to the Associate Project Director reports to the Associate Project Director.
Roles and Responsibilities: Project Teams
Functional Team Leads
The Functional Team Leads execute the project methodology for their specific application(s)through all phases of the implementation (i.e., Envision and Focus, Planning and Fit/Gap, Build and Test, Deploy and
Stabilize).
In this capacity the Functional Team Leads are responsible for:
Becoming proficient with the capabilities and features of the software application
Ensuring the timely completion of all deliverables as defined by the project methodology and other deliverables as necessary
Directing the assignments of the functional team members and monitoring the status of the assigned tasks to ensure that each objective is accomplished in a timely and effective manner
Communicating with other functional teams to ensure that the cross-impacts of redesigned processes do not conflict with those of other teams
Ensuring that new team members are properly oriented to the Project and fully understand the
University’s business strategies and the objectives of the Project
University of Virginia Student System Project
D:\726927898.doc
Page 28 of 68
4/14/2020
Discussing project policies and procedures
Introducing new team members to appropriate personnel (i.e., project office, other team members)
Ensuring that new team members have read and understand the materials included in the Employee
Manual (and have completed the steps necessary to ensure compliance with its terms)
Supervision of the following SSP Team members: o Functional Analyst o Technical Analyst as assigned to the team by the Technical Coordinator o Functional Consultant assigned to the team
The Functional Team Leads report to the Associate Director.
Functional Analysts
The Functional Analysts execute the assigned tasks as contained in the project methodology relative to their specific application through all phases of the implementation.
In this capacity the Functional Analysts are responsible for:
Becoming proficient with the capabilities and features of the software application
Ensuring the timely completion of all deliverables as defined by the project methodology and other deliverables as may be considered necessary
Communicating with other application teams to ensure that the effects of redesigned processes do not conflict with those of other teams
Documenting the current business practices and processes across departments/schools at the
University.
Documenting future business practices and processes across departments/schools at the University.
Working with the instructional designers to produce training materials
Serving as subject matter experts in creating training materials and conducting training on the new software
Supporting issue resolution to ensure project success
Supporting communications with departments/schools as determined by the Communications plan
Assisting technical analysts with understanding of the functional aspects of the software
Testing the software as determined by the Technical Integration Lead and Business Analyst
Functional Analysts report to their respective Functional Team Leads.
Technical Team Coordinator
The Technical Team Coordinator executes the project methodology for specific application/s through all phases of the implementation (i.e., Envision and Focus, Planning and Fit/Gap, Build and Test, Deploy and
Stabilize).
In this capacity the Technical Team Coordinator is responsible for:
Becoming proficient with the capabilities and features of the software application
Ensuring the timely completion of highest quality deliverables as defined by the project methodology and other deliverables as may be considered necessary
Directing the assignments of the team members and monitoring the status of the assigned tasks to ensure that each objective is accomplished in both a timely and effective manner
University of Virginia Student System Project
D:\726927898.doc
Page 29 of 68
4/14/2020
Developing and recommending best practice solution options to the Student System team based on end user requirements
Communicating with other functional teams to ensure that the cross impacts of redesigned processes do not conflict with those of other teams
Ensuring that new team members are properly oriented to the Project and fully understand the
University’s business strategies and the objectives of the Project
Discussing project policies and procedures
Introducing new team members to appropriate personnel (i.e., project office, other team members)
Ensuring that new team members have read and understood the materials included in the Employee
Manual (and have completed the steps necessary to ensure compliance with its terms)
Supervision of the following SSP Team members: o Technical Analyst o Technical Consultant assigned to the team
The Technical Team Coordinator reports to the Technical Integration Lead.
Data Warehouse Lead
The Data Warehouse Lead executes the project methodology for the data warehouse and reporting solution through all phases of the implementation (i.e., Envision and Focus, Planning and Fit/Gap, Build and Test,
Deploy and Stabilize).
In this capacity the Data Warehouse Lead is responsible for:
Ensuring the timely completion of highest quality deliverables as defined by the project methodology and other deliverables as may be considered necessary
Developing and delivering a comprehensive data warehouse and reporting solution for the student system.
The Data Warehouse Lead reports to the Technical Integration Lead
Dependent Technologies Lead
The Dependent Technologies Lead serves as a liaison for the project in assessing and understanding the impacts of systems and applications that do not fall within the prescribed scope of the student system project, yet are dependent on the student system implementation.
In this capacity the Dependent Technologies Lead is responsible for:
Establishing and maintaining open lines of communication across the University.
Becoming proficient with the capabilities, features and gaps of the software application
Understanding and communicating the impacts of dependent technology implementations to the SSP
Investigating options for functionality
The Dependent Technologies Lead reports to the Technical Integration Lead.
Technical Analysts
The Technical Analysts execute the assigned tasks as contained in the project methodology relative to their specific application through all phases of the implementation (i.e., Envision and Focus, Planning and Fit/Gap,
University of Virginia Student System Project
D:\726927898.doc
Page 30 of 68
4/14/2020
Build and Test, Deploy and Stabilize). Technical Analysts also assist in the development of functional capacity for project teams.
In this capacity the Technical Analysts are responsible for:
Becoming familiar with the functional and technical capabilities and features of the software products
(both system software and third party products)
Ensuring timely completion of all module steps as defined by the project methodology and other steps as may be considered necessary
Identifying and recommending best practice options to the SSP team based on submitted requirements
Providing technical advice and counsel to the functional team (serving as a technical subject matter experts)
Coordinating with other project technical staff and management to ensure adherence to project technical standards and to resolve technical issues as they arise
Analyzing, defining, implementing and changing software application functionality to meet business requirements and initiatives as they relate to the SSP
Creating technical requirement specifications, researching, testing, debugging modifications and new functionality
Writing required documentation
Investigating and troubleshooting system related problems
Working with the Technical Team Coordinator and the staff in the functional teams to ensure timely and quality development/configuration of the software
Acting as a bridge to the technical development staff in defining and designing approved customizations and modifications
Technical Analysts are embedded within functional teams, but report to the Technical Team Coordinator.
Systems Database Analysts
The Systems Database Analysts are responsible for sustaining the database infrastructure that enables the
University to capture, maintain, and access institutional student data.
In this capacity the Systems Database Analysts are responsible for:
Installing and maintaining database infrastructure components (e.g. database kernel, listeners, database monitoring tools)
Managing data storage, database backup/recovery; database security; configuration management
Monitoring and tuning database performance and security
Designing databases and assisting with configuration management
Investigating and troubleshooting system related problems and consulting on hardware configuration requirements
Systems Database Analysts report to the Technical Integration Lead.
Applications Database Analysts
Applications Database Analysts sustain the application data repository that encapsulates the University's
PeopleSoft student system. The Applications Database Analysts insure that application code and patches are migrated and proper procedures are followed to ensure consistency and quality in the student system
University of Virginia Student System Project
D:\726927898.doc
Page 31 of 68
4/14/2020
PeopleSoft application. The application database analysts accommodate data needs that are specific to the
PeopleSoft student system.
In this capacity the Applications Database Analysts are responsible for:
Establishing roles/responsibilities, running application and database scripts
Troubleshooting application issues, monitoring application performance, and maintaining global application setups
Analyzing, developing and maintaining schema objects (e.g. tables, constraints, indices, and triggers); strategies for schema-level data security; data migrations; and database consultations
Applications Database Analysts report to the Technical Integration Lead.
Portal Administrator
The Portal Administrator interfaces with the Student System Project teams and the Campus Solutions community to understand the University's portal requirements and implements procedures to accommodate them.
In this capacity, the Portal Administrator is responsible for:
Establishing, supporting, and maintaining the PeopleSoft portal environment and web development initiatives of the SSP team
Creating and maintaining the PeopleSoft Enterprise Portal. (This includes branding and configuration of the delivered capabilities of the portal as well as maintaining links to content providers.)
Applying portal content approved by a governing portal team and providing access to the contents within the portal
Working closely with the security administrator and the ITC networks and infrastructure team in adhering to the University's guidelines and strategy for security and single-sign-on
The Portal Administrator reports to the Technical Integration Lead.
Security Administrator
The Security Administrator interfaces with the Student System Project teams and the Campus Solutions community to understand their security needs and implements procedures to accommodate them.
In this capacity, the Security Administrator is responsible for:
Ensuring that the user community understands and adheres to necessary procedures to maintain security within the PeopleSoft system
Conducting accurate evaluation of the level of security required
Documenting and working to resolve PeopleSoft security related issues
Devising improvements to current procedures
Developing models of possible future configurations
Providing production and development support in the area of security for applications and projects
Creating and maintaining security for the production, development, test, and training user profiles
Creating and maintaining permission lists and roles in all environments
Adding and updating the query trees in all environments
Troubleshooting connection issues from the Portal
University of Virginia Student System Project
D:\726927898.doc
Page 32 of 68
4/14/2020
Assisting application development groups with database related issues
Creating security validation and auditing process and access control maintenance procedures
Performing evaluations of potential tools and utilities
Participating in disaster recovery (DR) planning and testing
Providing input regarding PeopleSoft security standards and best practices
The Security Administrator reports to the Technical Integration Lead.
Programmer/Developers
Programmer/Developers are responsible for analyzing, developing, testing and implementing PeopleSoft application functionality for the Student System Project that enables the University to capture, maintain, and access institutional student data.
In this capacity the Programmer/Developers are responsible for:
Developing and maintaining application code using PeopleTools, JAVA, and other products to convert, extend, and integrated the PeopleSoft student system with other University systems
Investigating and troubleshooting system related problems and work
Working with the technical analyst and functional analysts to ensure requirements are met for the implementation of the PeopleSoft Student System.
Programmer/Developers report to the Technical Team Coordinator.
Local Support Partner
The Local Support Partner (LSP) for the SSP is responsible for providing technical support for the entire
Project Team.
In this capacity, the Local Support Partner is responsible for:
Ensuring that the network in the SSP team building is maintained and available for all SSP team members
Providing and maintaining the SSP project server and the applications that reside on it (including
Traction, Tutor, other project documentation, etc.)
Providing workstation support, including ordering, installing, configuring, and testing new hardware, and repairing broken hardware
Providing help (troubleshooting, fixes, and other assistance) to SSP team members on an “as needed” basis with regard to workstation software or hardware
Managing the security access system for the SSP building
The Local Support Partner reports to the Technical Integration Lead.
Communications Systems Programmer
The Communications System Programmer will provide support for and expertise in the use technical elements of communications related to the Project, particularly in the use of Microsoft SharePoint.
In this capacity, the Communications Systems Programmer is responsible for:
Designing, developing, maintaining, and enhancing complex computer and related manual systems
University of Virginia Student System Project
D:\726927898.doc
Page 33 of 68
4/14/2020
Exercising wide latitude in assessing needs and determining alternatives
The Communications Systems Programmer reports to the Technical Integration Lead.
Instructional Designers
The Instructional Designers design, monitor, implement and evaluate a training plan to develop tools, applications, and courseware that will assist technical professionals, functional professionals, and end-users in learning how to use the software applications efficiently and effectively.
In this capacity the Instructional Designers are responsible for:
Becoming proficient with the capabilities and features of the software application
Collaborating to design courseware on the effective use of the system and its business practices
Overseeing a plan to design tools, applications, and courseware that will assist functional and technical instructors in the delivery of information
Providing primary design support to a specific functional team to ensure the delivery of quality instruction to technical professionals, functional professionals, and end-users
Ensuring the timely completion of all training deliverables related to a specific functional team as defined by the project methodology and other deliverables as may be considered necessary
Communicating frequently with other SSP teams, other instructional designers, and the Strategic
Planning Manager to ensure that training is consistent between SSP teams and phases and to prevent the creation of obstacles for other teams
Serving as the documentation resource for the team
The Instructional Designers work with the Special Projects Manager for adherence to the Training Plan.
Roles and Responsibilities: Consulting Resources
Consulting Project Manager/ Lead Functional Consultant
The Consulting Project Manager is the Engagement Manager for consulting and is generally responsible for project operations. The Consulting Project Manager works closely with the Project Director and Associate
Director.
In this capacity, the Consulting Project Manager is responsible for:
Coordinating, maintaining, and updating the project plan
Ensuring timeliness of deliverables
Adhering to the Quality Plan
Tracking issues and outcomes of the decision process
Adhering to the Testing Plan
The Consulting Project Manager reports to the Project Director and Associate Director (U.Va.).
Technical Lead Consultant
The Technical Lead Consultant is responsible for advising the Technical Integration Lead on the day-to-day technical activities of the Project and planning for the longer-term technical activities of the Project.
University of Virginia Student System Project
D:\726927898.doc
Page 34 of 68
4/14/2020
In this capacity, the Technical Lead Consultant is responsible for:
Executing the project plan for technical aspects of the Project
Directing the day-to-day assignments of consulting technical staff members
Ensuring that all technical issues are researched and approaches are explained, as the resolution may impact the current implementation and on upgrades
Communicating project issues to the Technical Integration Lead
Guiding the technical teams through deliverable preparation
The Technical Lead Consultant reports to the Consulting Project Manager and to the Technical Integration
Lead (U.Va.).
Functional Consultants
The Functional Consultants are the primary functional experts for the implementation of the software applications. Their focus is on supporting the Associate Project Director (U.Va.), the Consulting Project
Manager/Functional Lead Consultant, and the respective functional teams to which they are assigned during implementation.
In this capacity, the Functional Consultants are responsible for:
Guiding the teams through deliverable preparation
Ensuring system set-up, development of training material, and other functional efforts are executed per the project plan
Identifying, and where appropriate, resolving functional issues as they arise
The Functional Consultants report to the Consulting Project Manager and to their respective Functional Leads
(U.Va.).
Technical Consultants
The Technical Consultants are the primary technical experts for the implementation of the software applications. Their focus is on supporting the Technical Integration Lead (U.Va.), the Technical Lead
Consultant, and the respective functional teams to which they are assigned during implementation.
In this capacity, the Technical Consultants are responsible for:
Guiding the teams through deliverable preparation
Ensuring data conversion, testing, and other technical efforts are executed per the project plan
Identifying, and where appropriate, resolving technical problems as they arise
The Technical Consultants report to the Technical Lead Consultant and to the Technical Integration Lead
(U.Va.).
Teams and Meetings Framework
Teams
Admission Team
Team Members
Admission Project Lead
Functional analysts
Technical analysts
University of Virginia Student System Project
D:\726927898.doc
Meeting Frequency and Purpose
At least weekly
As per Associate Director and team leads
Page 35 of 68
4/14/2020
Teams Team Members
Reporting liaison
Training liaison
Data Reporting
Team
Administrative Team
Business Analyst
Staff Assistant
Assistant to the Director
Assistant to the Associate Director
Technical Integration Lead
Data Warehouse Lead
Manager, Data Services
Database and Data
Services Team
Dependent
Technologies Team
Development Team
Technical Integration Lead
Manager, Data Services
Application DBAs
System DBAs
Technical Integration Lead
Dependent Technologies Lead
Senior Technical Analyst
Technical Coordinator
Developers
Integration Team
Project Team
Associate Director
Admission Project Lead
Registration and Records Project
Lead
Student Finance Project Lead
University Services Project Lead
Technical Integration Lead
Business Analyst
Technical Coordinator
Strategic Planning Manager
All team members
At least weekly
Reviews and plans hiring and staff issues, scheduling and general office administration
At least weekly
Reviews and plans project progress for data access and reporting
At least weekly
Reviews and plans databases, patches, security, and configuration control
Meeting Frequency and Purpose
At least weekly
Reviews and plans progress for dependent technologies
At least weekly
Reviews and plans development work
At least weekly
As per Associate Director; projects and team status reporting; critical problems and proposed solutions; reviews of issues, personnel, specific needs, timeline, quality, risks, etc.
Updates at significant points in the Project
Project Leadership
Team
Registration and
Records Team
Director
Associate Director
Technical Integration Lead
Business Analyst
Communications Manager
Strategic Planning Manager
Special Projects Manager
Registration and Records Project
Lead
Functional analysts
At least weekly
Reviews and plans for decisions related to the project’s status reports, issues resolution, budget, resource allocation, project risks, consulting, University readiness, special projects, etc.
At least weekly
As per Associate Director and team leads
University of Virginia Student System Project
D:\726927898.doc
Page 36 of 68
4/14/2020
Team
Teams
Student Finance
Team Members
Technical analysts
Reporting liaison
Training liaison
Student Finance Project Lead
Functional analysts
Technical analysts
Reporting liaison
Training liaison
University Readiness
Team
Director
Associate Director
Communications Manager
Strategic Planning Manager
Special Projects Manager
Training Manager
Assistant to the Director
Meeting Frequency and Purpose
At least weekly
As per Associate Director and team leads
University Services
Team
University Services Project Lead
Functional analysts
Technical analysts
Reporting liaison
Training liaison
Weekly, in conjunction with Project Leadership
Team
Develops a planned approach to institutional change associated with the Project in order to prepare the University community, maximize the project’s transformative potential, and minimize the risk of its failure
Reviews and plans for activities one month out that support the evolution of University readiness
At least weekly
As per Associate Director and team leads
University of Virginia Student System Project
D:\726927898.doc
Page 37 of 68
4/14/2020
Project Assumption and Scope
Project Assumptions
1.
It is assumed that legacy administrative systems will be supported until replaced by PeopleSoft functionality and that the legacy system will be retired not later than one year after the new student system is operational. However, changes and enhancements to existing systems will be kept to an absolute minimum during the Project, e.g., to meet legal compliance requirements.
2.
Interfaces between PeopleSoft and ISIS will exist during implementation. ISIS and the mainframe will be maintained for no more than one year after project completion.
3.
The new student system will be implemented according to a phased rollout, wherein all modules go live by fall 2009. When project funding ends (December, 2009) and the project ramps down, ongoing system maintenance will require a new budget.
Scope
1.
Implementation of PeopleSoft Campus Solutions, including the following modules: Academic
Advisement, Campus Community, Campus Self Service, Enterprise Gradebook, Enterprise
PeopleTools, Enterprise Portal, Financial Aid, Recruiting and Admissions, Student Financials, Student
Records
2.
Delivered functionality in PeopleSoft that replaces current functionality in other systems (e.g., SEVIS functionality, Arts and Sciences transfer database, etc.)
3.
Degree audit functionality in PeopleSoft (Academic Advisement) or an upgraded version of the current degree audit solution (VISTAA DARS), which requires an interface to the student system—to be determined by the Vice President and Provost
4.
Provision of, interface to, and rules governing the use of R25 for instructional space—in collaboration with UREG and the Office of the Vice President and Provost
5.
Implementation of an integrated web application for undergraduate admission, and a consolidated approach to graduate and professional school admission, both integrated with PeopleSoft—as determined by the Vice President and Provost and the Vice President for Research and Graduate
Studies
6.
Development and installation of an architecture and strategy for conversion of student data and provision of mission-critical reports as identified in cooperation with users of the student system
7.
Integration and extension of current document management functionality to current users and to undergraduate and some graduate admission offices
8.
Development of a University-wide approach to change management; knowledge transfer; adoption of proactive electronic communication as a primary mode of communication, as appropriate; a comprehensive training program for various users of the new system; and communication with units whose business processes, organizational structures, and staffing requirements are affected by the new system
9.
Other systems as approved by the Executive Committee as a Request for Exception, Interface or
Customization
University of Virginia Student System Project
D:\726927898.doc
Page 38 of 68
4/14/2020
Interfaces
SSP will develop interfaces or, in limited cases, provide a list of requirements to the department(s) responsible for developing the interface(s)
1
to:
1.
The University’s identity management system—as determined by the Vice President and CIO
2.
The University’s course management and course evaluation systems—as determined by the Vice
President and Provost
3.
InfiNET—the e-commerce solution implemented by a project team in the Comptroller’s area
4.
Sunguard’s Advance system according to FERPA-based guidelines
5.
Oracle HR and finance systems, as required for integration of data
6.
Multiple, approved, mission-critical, dependent applications for which delivered functionality in
PeopleSoft does not exist (e.g., Parking and Transportation or Housing; see diagram, Appendix
One: Current Student System Functionality and Data Flow for more information)
SSP is responsible for successful implementation of these interfaces; ongoing costs associated with maintenance, upgrades, etc. are not included in the project budget.
The following diagram presents a pictorial representation of the SSP Scope.
University of Virginia Student System Project
D:\726927898.doc
Page 39 of 68
4/14/2020
Self Service
Portal
Communication
Training &
Outreach
Resolution of
Strategic Issues
Conversion/
Legacy
Security
Core Functionality
Admission
Registration &
Records
Student Finance
University Services
Advising Support
Integration/
Interfaces
Reporting/Data
Structure(s)
Information
Assurance
Dependent
Technologies
Self Service
Portal
University of Virginia Student System Project
D:\726927898.doc
Page 40 of 68
4/14/2020
Scope Management and Change Control
The scope management process is the primary vehicle for defining the boundaries of the Project and ensuring that management has the opportunity to make timely trade-offs between the three key project variables of cost, schedule, and functionality. Inadequate control can lead to unexpected cost and schedule overruns.
Potential changes must be identified early, documented carefully, and resolved at levels consistent with project decision-making parameters.
Scope Change
Scope changes are broadly defined as those activities not originally defined by the project scope and project plan. More specifically, scope changes include:
Business-related scope items not listed in the scope definition or plan (e.g., additional functions, business processes, application modules, versions/releases, programs, databases)
Provision or development of work products or deliverables not included in the project plan
Participation in activities not previously included in project plan’s list of work activities
A change in the guiding principles or assumptions defined in the scope definition or plan
A change in responsibilities, as defined in the scope definition or plan, including any request for exception granted by the Integrated System Executive Committee
Reallocation of project staffing
Any rework of completed activities or work products resulting from changing requirements
Delays caused by a change in previously agreed-upon acceptance criteria
Investigative work to develop impact statements for major scope change requests.
Scope Change Management
If a member of the SSP team requests a change in scope for the project, the feasibility of the change is evaluated within the team. A white paper is drafted to provide an assessment and comprehensive evaluation of the impact of the change on work effort, cost, and schedule. All costs must be taken into consideration, including documentation, management overhead, system performance, and schedule impact.
The Project Director must approve the assessment provided in the white paper and seek approval from the IS
Executive Committee if the change indicates that an adjustment to the schedule or budget is necessary.
If a school or department seeks consideration of an exception, customization, or interface to the student system, or requests permission not to use the architecture(s) provided by the project if offered, it must submit a Request for Exception, Customization, or an Interface through the Student System Project for consideration by the Integrated System Executive Committee.
Such requests must be completed within one month of the school or department requesting the exception being informed of proposed functionality.
A decision to grant an exception, customization, or interface will be based on its merits for the University as a whole. Should such a request be approved by the Executive Committee, the school or unit must consistently comply with all standards related to the student system and will, if determined by the Executive Committee, bear all costs associated with implementation of an interface, including but not limited to costs incurred by the
University of Virginia Student System Project
D:\726927898.doc
Page 41 of 68
4/14/2020
SSP; costs associated with meeting University security standards and audit requirements; testing; upgrades; patches; maintenance of data feeds; etc. of its excepted system(s) in a timely manner according to the specifications provided by the student system.
The form by which to request an exception, customization, or interface will be posted to the Community
SharePoint site.
The Executive Committee will provide the precise terms under which any approved exception, customization, or interface will operate.
Appeals of the Committee’s decisions may be submitted through the Chair of the Review Committee to the
Executive Committee.
Risk Management Strategies
ERP implementations, because of their transformative potential, possess inherent and significant risk. The implementation of a new student information system heightens the risk associated with the first two phases of the Integrated Systems Project. Whereas the Finance and Human Resources implementations directly involved approximately 2,000 University employees and four central process owners, the Student System
Project will affect and involve nearly every constituency within the University.
Introduction
The implementation of a new student information system will affect and involve executives, key stakeholders, process owners, and users including students, faculty, and staff; will have a significant impact on all key missions of the University; and will inform both internal and public perception of the University.
In addition, the traditional decentralization of decision-making across schools and departments of the
University, combined with an academic culture that values deliberate consideration of varying points of view, can come into conflict with limited options for ways to do academic business in a vendor-supplied system.
Project governance structures outside of existing decision-making groups may be viewed as temporary or inconsequential.
Finally, requirements for reporting to various state and federal agencies and the compliance issues associated with those activities, as well as the intrinsic desire of higher education institutions to conduct research on their own internal activities, combine to create a complex set of expectations from internal and external audiences.
This reality increases the level of risk associated with these processes.
The following success strategies and risks, identified by Bearing Point Consulting, will inform the project’s risk management approach.
Success strategies:
Actively build a base of support for the Project
Focus on the real challenges – people and processes – from the start
Invest in documenting current business processes
Implement in waves, beginning with core functions
University of Virginia Student System Project
D:\726927898.doc
Page 42 of 68
4/14/2020
Meet or exceed users’ expectations for support
Take into account the many hidden costs
Be realistic in identifying the right ERP package for your organization
Keep your eye on the big picture and how it can impact your project
Treat milestone dates as sacred
Risks:
Insufficient executive support
Treating an ERP implementation as an IT project rather than a transformative business project
Inexperienced project management
Indecision
Poor communication
Insufficiently robust technical infrastructure
Altered source code
Insufficient testing prior to “go live”
Insufficient and inadequate training
Unreasonable expectations
Project Risk and Mitigation Strategies
At the outset of the SSP, the following risks and mitigation strategies were identified and validated by the IS
Executive Committee:
1.
The inherent tension between a centralized student system solution and the loosely federated culture of schools, programs, and activities that comprise the University of Virginia; insufficient motivation to standardize around system capabilities.
IS Executive Committee must address this issue squarely and provide visible support to the
Project.
Clearly engage on an as-needed, predefined basis the academic and administrative decisionmaking representatives from the vice presidents and deans to react to recommendations and provide comments for decision-making by the IS Executive Committee.
Define project parameters and timeline in order to assure project success.
Include Senior Vice President for Development and Public Affairs (University website, nexus between student system and alumni/development systems) and Vice President for Research and Graduate Studies (graduate admissions and financial assistance).
Failure to mitigate could result in scope issues and excessive customization to accommodate “local” processes affecting cost and timeline.
2.
Unclear definition of which University entities will participate in the SSP. Traditionally independent schools of the University may wish not to participate in a centralized student information system beyond the level of participation they currently enjoy. University-wide benefits may not be achieved without full participation of most schools and central offices (admission, financial aid, registration and records, etc.).
Define participants early in the Project and seek commitment for continuing participation.
Utilize clear mechanisms to seek exception to participation in the SSP.
University of Virginia Student System Project
D:\726927898.doc
Page 43 of 68
4/14/2020
Adhere to clearly defined Request for Exception or Customization process to request exceptions that currently exist or that that may arise as the Project progresses (see page 44 for scope change management).
Involve IS Executive Committee-level leadership in decision-making mechanisms and processes.
Failure to mitigate could result in vague scope issues that lead to distraction of the Project Team from its responsibility for implementation and consequent increased costs.
3.
Insufficient attention to dependencies created by dependent technologies or created by the Project itself; insufficient conservation of resources allocated to projects that duplicate SSP efforts.
Establish scope of SSP.
Establish accountability for decisions pertaining to the feasibility and practicality of dependent technologies
Establish responsibilities related to dependent technologies.
Establish strong communication vehicles to collaborate with dependent technologies; be aware of timelines and status of these within the project plan
Collaborate with ITC.
Collaborate on dependent technologies to ensure successful interfacing, if necessary.
Share consulting resources to ensure that the implementation of dependent technologies is ontime.
Failure to mitigate may result in missed deadlines, conflict detrimental to project success, and/or cost overrun.
4.
Approaching the implementation of a new student system as a technology project rather than as a vehicle for organizational change that achieves the University’s strategic priorities.
Gain clear, defined executive support for alignment of organizational changes.
Gain consensus on project scope.
Emphasize and publicize executive support for the Student System Project.
Assure that project timelines allow sufficient time to optimize process improvement and changes in organizational structures, budgets, resources, etc., in key audience groups.
Failure to mitigate may result in achieving less than optimal results in terms of student service, system capabilities, and system acceptance among the user community.
5.
Insufficient attention to change management (i.e., lack of institutional approach to the Project, poor audience-specific messaging, insufficient personal and credible interactions among stakeholders, poor or passive communications, inadequate training, poor preparation of managers and supervisors to implement changes, etc.).
Proactively identify and mitigate change management risks throughout the University’s leadership structure(s).
Develop and adhere to a defined strategy for change management in order to develop the same level of preparedness among all stakeholder and audience groups.
Hire qualified team members with change management expertise and responsibility.
Disseminate and demonstrate support for the Business Case for SSP.
Effectively leverage the influence of “champions” of the Project throughout the University.
University of Virginia Student System Project
D:\726927898.doc
Page 44 of 68
4/14/2020
Failure to mitigate may result in increased resistance to change, poor adoption of new processes and technologies, high error rates during the stabilization period, and service issues.
6.
Lack of project’s integration with existing governance structure (SSN, ISIS Review Committee,
SESPOG, Process Simplification, IT governance, etc.) and competing activities; immaturity and marginal nature of project-specific governance and operational structure.
Review existing governance structures and gain representation from SSP to them.
Create and publicize project governance mechanisms, including processes for resolution of strategic issues, for decisions related to systems issues, for exceptions to participation in SSP, and for approval of IT projects that compete for project-related resources.
Participate in development of revised governance and organizational structures that change as a result of the SSP.
Coordinate projects and initiatives to take advantage of synergies and common goals; share resources.
Failure to mitigate may result in wasted effort on conflicting projects and reduced resources available to achieve project objectives.
7.
Insufficient level of creativity, energy, and risk tolerance among all project stakeholders and contributors.
Involve executive leadership in sending messages to direct reports that encourage full participation in the Project.
Hire team members from inside and outside the University who have creativity, energy, and a high risk tolerance.
Allow for demonstration of talent, and remove those who do not contribute.
Create effective approaches to team development and for the professional development of individual team members.
Develop effective approach to knowledge transfer throughout the life of the Project.
Create reward mechanisms that address the contributions of team members.
Failure to mitigate may result in sub-optimal system design, loss of input from stakeholders critical to project success, and loss of project team members.
8.
Possible changes in executive leadership and key stakeholders at the University throughout the
Project.
Have extensive conversations between new leaders and project leadership to define relationships affecting the Project, and to develop strategies to address issues in the context of the project’s timeline, resources, etc. Maintain accurate documentation of evolving roles and responsibilities during periods of change during the project period, as well as postimplementation.
Insure that the Project stays informed of and responds to the University’s changing needs and priorities within the context of project parameters.
Failure to mitigate may result in conflict detrimental to project success and expending resources on projects that conflict with the SSP.
9.
Underestimation of time commitment of individuals in academic and administrative units outside the
Project.
University of Virginia Student System Project
D:\726927898.doc
Page 45 of 68
4/14/2020
Have key leaders (VPs and Deans) state to their direct reports and others that the SSP is a priority for them, and that managers and supervisors must give the project’s requirements their attention and their resources.
Have departments and schools create strategies for staff support of the Project that address
University, departmental, and project priorities and needs.
Failure to mitigate may result in limited subject matter expert participation, resulting in a less than optimal design and reduced acceptance of the processes and technology.
Lessons Learned
The following lessons learned, documented in “Assessing the Risks of Commercial-Off-the-Shelf
Applications” (Information Technology Resources Board of the United States Government, 1999), will inform the evolution of the project’s risk management approach:
1.
Understand the Commercial Off-the-Shelf (COTS) product: visit others and consider prototyping and piloting the software
2.
Examine the “gap”: understand the gap between what your organization needs and what the software does well before the implementation begins
3.
Incorporate lessons learned: pay attention to experiences of similar organizations
4.
Secure required resources: be sure that the time, financial and personnel resources are dedicated; insure a balance between technical and functional experts on the team
5.
Focus on data and interfaces: build interfaces before deciding on a business solution, then create a business solution that works
6.
Involve functional users: users who understand the issues can minimize obstacles to implementation
7.
Validate performance and scalability: be sure that the product has supported user numbers and geographical demands like yours
8.
Select mature products: use “road-tested” products
9.
Fully understand contractual conditions: source code and modifications to source code, conditions at contract expiration, etc.
10.
Plan well for sustainability: maintenance includes the system, interfaces, integration with other systems, accommodation of hardware/operating system changes
University of Virginia Student System Project
D:\726927898.doc
Page 46 of 68
4/14/2020
Issue and Risk Management Processes
Issue and risk management processes have been established to facilitate good decision-making at all levels and to ensure the monitoring and effective resolution of issues and risks. Such processes are management tools for situations that can have an impact on team performance, implementation, and the quality and successful completion of the Project.
A centralized, automated Project Risks and Issues Management database (PRISM) has been developed and will be utilized throughout the Project to track:
Issue/Risk Identification
Documentation
Communication
Resolution/Implementation
Maintenance
Issue Types and Risk Documentation
During the course of implementation, team members may identify or become aware of issues. The following questions may help determine whether an issue should be tracked in PRISM:
Is the issue relevant to the Project?
Will the issue have significant impact on the Project, e.g., increased cost, project delay, or change of scope?
Does the issue require further clarification or investigation?
What is the priority status of the issue or its level of impact on the Project? o Critical: Critical issues require immediate attention since their impact could result in project failure or serious delay, cost increase, and productivity loss. o High-1: High-1 issues require urgent analysis prior to implementation planning in order to identify options for policy-level discussions. Decision-making and resolution of policy options may require the involvement of executive-level stakeholders. Lack of resolution could lead to the immediate halt or significant delay in project productivity. High-1 issues may be elevated to Critical status if not addressed in a timely manner. o High-2 : High-2 issues require full analysis prior to implementation planning in order to identify options for system-level discussions. Options for delivered functionality within the system must be considered, since the decision-making and resolution of these issues may require the involvement of multiple key departmental stakeholders. Lack of resolution could lead to the immediate halt or significant delay in project productivity. High-2 issues may be elevated to Critical status if not addressed in a timely manner. o High-3 : High-3 issues require some analysis prior to implementation, but decision-making and resolution of these issues most likely resides within the project team. Lack of resolution may require advice from key stakeholders. High-3 issues may be elevated to status High-2 if not addressed in a timely manner. o Medium: Medium issues carry some impact and require analysis to determine if and when they are part of the implementation. o Low: Low issues are excluded from the implementation but are retained as “parking lot” issues.
University of Virginia Student System Project
D:\726927898.doc
Page 47 of 68
4/14/2020
In the course of identifying and documenting issues and/or engaging in other project-related activity, team members may identify and/or become aware of potential or actual risks. These and other risks may be documented in PRISM as issues in and of themselves; as issues, these risks will be rated as:
Red : issue needs to be addressed immediately; it indicates an aspect of the project that is not on track or reflects another, significant concern
Yellow : issue could become a problem if not addressed; it indicates an aspect of the project that is on track but it nonetheless signals caution or pending concern
Green : issue is on track
Team members may enter an identified issue on behalf of the team or a stakeholder or consultant into PRISM.
The issue is assigned a status of “open” and the Project Leadership Team reviews open issues weekly.
When an issue or risk is entered into PRISM, the Team Leads, Technical Integration Lead, and Associate
Director review the issue and verify its priority status. They assign tasks, support responsibilities, establish a decision deadline, and identify the decision-maker(s) or review group that is responsible for determining what information is necessary to resolve the issue. The designated decision-maker or review group, in conjunction with the team member supporting the information collection process, is notified of responsibilities pertaining to the issue. All team members are responsible for informing the Project Director and Associate Project
Director through PRISM at the earliest possible date of any issues that may pose risk to the project, as well as the decision-maker(s) for the issue.
The project team member who is assigned an issue is responsible for collaborating with key stakeholder(s) and decision-makers on the team, as appropriate and will gather and organize the necessary information, including an impact analysis that addresses functionality, cost, and schedule. This documentation will include a timeline for resolution as well as a recommendation and default decision. Issues that have not yet reached a
“critical” level will be continuously monitored in the weekly status reporting cycle by the team member who is supporting the issue.
Prior to the deadline, the decision-maker on the team will consider the information, assess its adequacy to make the decision, and make the decision.
The team’s decision-maker approves the documentation or modifies it appropriately. If the decision-maker determines that the information is inadequate, the Associate Director or Project Director may nonetheless request a decision even in light of the uncertainty. If the decision-maker is unable or unwilling to make a decision by the established deadline, the Associate Director or Project Director will adopt the default decision proposed by the team, or may transfer decision-making authority to him/herself or another appropriate group.
When the issue has been resolved and the resolution approved, the team member supporting the decisionprocess documents the resolution in PRISM.
Open issues that are not critical will be managed and resolved according to whether they are strategic or system issues.
University of Virginia Student System Project
D:\726927898.doc
Page 48 of 68
4/14/2020
Strategic Issues
Strategic issues are those issues that may have University-wide, cross-functional policy, budgetary, or organizational implications and that require higher level policy and/or change management activity in order for the Project to proceed with clear direction. Academic, financial, or any issues that carry implications for the review of policy are considered by the team as strategic issues.
System Issues
System issues are those that pertain to system-related and/or technical matters and solutions that affect and/or are affected by business processes. During the evolution of the implementation of the student system, for example, there will be gaps between the student system software as it is delivered from the vendor and the functionality that is desired by users. In those situations, there must be a governing methodology for identifying and addressing such gaps. Resolution of system issues during the Project will rely on information and analysis that includes inputs from key stakeholders.
University of Virginia Student System Project
D:\726927898.doc
Page 49 of 68
4/14/2020
Decision-Making Process
Decisions are made according to procedures outlined in the project Charter and are based upon consultation with appropriate constituencies and with the best information available at the time. Some decisions may rely on the review and approval of subsets of individuals who are members of each of the groups listed below.
Item
Critical Issue Resolution
Strategic Issue Resolution
System Issue Resolution
Reviewing and/or Approving Parties
Project Leadership Team, Policy Review Group (PRG), IS Executive
Committee (Ex. Comm.)
Project Leadership Team, Core Advisors to the Student System (CASS),
PRG, Ex. Comm.
Project Leadership Team, Core Advisors to the Student System (CASS),
Local Project Groups (LPG), Ex. Comm.
Risk Resolution
Organizational Changes
Functionality Gaps
Revised Business Processes
Project Leadership Team, PRG, Ex. Comm.
Project Leadership Team, CASS, PRG, Ex. Comm.
Project Leadership Team, CASS, PRG, Ex. Comm.
Project Leadership Team, LPG, CASS, PRG, Ex. Comm.
Revised Roles and Responsibilities
System Modifications
Project Leadership Team, CASS, PRG, Ex. Comm.
Project Leadership Team, LPG, CASS, PRG, Ex. Comm.
System Usability and User Acceptance Key Stakeholders, Instructional Designers, Project Leadership Team
Issue Management and/or Change Control Process
Once pertinent information is gathered and materials are prepared according to the protocol described above, a complete summary and recommendation for resolution will be prepared by the team. The Project Director,
Associate Director and others, as appropriate, will consult with key stakeholders and others, as necessary, to review and decide on resolutions to the issues.
In resolving such issues, a primary goal for the SSP is to rely on the best practices as contained in the delivered application. Keeping the application as “vanilla” as possible alleviates difficulties when revisions and upgrades are implemented and limits the proliferation of specialized elements of the system that are expensive to design, develop, test, and maintain. Choices of configurations made during the implementation will consider the needs of the stakeholders, the capabilities of the system, academic mission criticality, legal and compliance requirements, costs, and how to address best the requirements of the greatest number of users.
In order to ensure the long-term functionality and viability of the system(s) installed during the implementation of the student system, customizations, modifications, and bolt-on applications that are not an initial part of the vendor-supplied software package(s) will be made only in exceptional circumstances.
(“Customizations” are software components developed as adjunct processes to the application.
University of Virginia Student System Project
D:\726927898.doc
Page 50 of 68
4/14/2020
“Modifications” are software changes made to the application and may be changes to the core software or to the table structure. “Bolt-on applications” are separate software packages that interface with the application.)
Requests for adaptations to the basic software system as it is constituted when delivered will be referred to the
IS Executive Committee for resolution through the Request for Exception or Customization process (see page
45) or at the discretion of project leadership. The Project Director and Team will consult with key stakeholders in order to assure the preparation of a full description of the requested adaptation, an outline of the pros and cons of various options for solution, a statement of the timeline for resolution of the issue required by the project timeline, and articulation of a default solution.
The timeline for decisions that is embedded in dependencies contained within the project timeline will be honored.
The following diagram provides a pictorial representation of the SSP Issue Management and/or Change
Control Process.
University of Virginia Student System Project
D:\726927898.doc
Page 51 of 68
4/14/2020
Issue Management And/Or Change Control Process
Document/Update
Issue in PRISM
Review New
Issues and Risk
Reports
Monitor Issue
Resolution
Progress
No
Does the Issue
Require a
Change
Request and/or
Issue Paper?
Yes
Draft Change
Request and/or
Issue Paper with
Recommendation
Implement Option
No
Review Change
Request and/or
Issue Paper with
Recommendation
Require
Governance
Input?
Yes
Policy Matter?
Communicate
Disposition
No
Review Change
Request and/or
Issue Paper
Research
Additional
Information and
Consult
Stakeholders as
Appropriate
Decision Date
Approaching or
Need to
Escalate?
No
Provide
Recommendation
& Concerns
Yes
Review Change
Request and/or
Issue Paper
Research
Additional
Information and
Consult
Stakeholders as
Appropriate
Yes
Decision Date
Approaching or
Need to
Escalate?
No
Provide
Recommendation
& Concerns
Yes
Review Change
Request and/or
Issue Paper
Provide
Recommendation
& Concerns
Recommendation
Implemented
University of Virginia Student System Project
D:\726927898.doc
Page 52 of 68
4/14/2020
Management of Deliverables
Introduction
Deliverable management guidelines establish the rules and responsibilities for creating, approving, and maintaining project deliverables. They identify the documents and data to be managed, as well as the associated format for, review process for, and retention of these deliverables
Creation and Documentation of Deliverables
The Project Team is responsible for drafting deliverables and involving appropriate project stakeholders in their creation and review.
Review and Approval of Deliverables
To ensure that the risk is minimized, project direction is consistent, and project standards and procedures are being adhered to, review and sign-off is required. Specific deliverables will be assigned in concert with the implementation partner.
Maintenance of Deliverables
Working deliverables are stored on the shared drive, accessible to all team members. Upon sign-off and approval, deliverables are placed on the SharePoint Community site for stakeholder reference. Explanations of both the shared drive and SharePoint site follow.
Tollgate Process
The Project Team is responsible for delivering pre-defined work products, or deliverables, as key milestones are reached. In order to ensure the timely and successful delivery of such products, each project phase will contain a tollgate process that is designed to involve stakeholders, solicit their comments, revise deliverables if feasible within project guiding principles, and provide a mechanism for documenting stakeholders’ concerns.
In the “pre-tollgate session”, stakeholders review drafted deliverables and provide feedback within a specified timeframe for the team’s consideration through the person the team has identified as the “owner” of the issue.
The team then considers revision(s) to deliverables and presents resulting changes, if any, at the “tollgate session” prior to the close of the current phase of the Project.
Because stakeholders are responsible for understanding deliverables as they relate to their business areas, identified decision makers are required to sign off on of the team’s final deliverables if they accept them.
However, if stakeholders have reservations or concerns related to the project’s deliverables, they and SSP will jointly document issues and concerns within a specified timeframe. It is expected that, if stakeholders’ concerns are accurately documented and conditions addressed by project leadership, they will sign off on the team’s deliverables for the phase.
It is the responsibility of the stakeholders to communicate information related to and impact of deliverables within their departments. The diagram below provides more information about the tollgate process.
Phase Nearing
Completion
Tollgate Process
Identify Next
Phase
Deliverables
Draft Current
Phase
Deliverables
Incorporate
Feedback
Present Draft
Deliverables at
Pre-Tollgating
Session
Incorporate
Feedback
Review Current
Phase Draft
Deliverables
Provide Feedback
Present Draft
Deliverables at
Tollgate Session,
Addressing
Feedback
Deliverables
Satisfactory?
No
Work with
Stakeholders to
Arrive at Consensus within Specified
Timeframe
Reach
Agreement?
No
Yes
Yes
Document Issues
Review Draft
Deliverables
Provide Feedback
Sign Off on
Deliverables
Sign Off on
Deliverables with
Conditions
Addressed
Next Phase
Deliverables
Identified
Phase Completed
Status Reporting
Status Reports are an important tool to:
Provide the right level of information about each project (overall progress, milestones, issues, and risks)
Provide a forum for escalating issues and matters of concern to the appropriate level
Establish consistent and simple procedures for providing project updates
This document describes the project-wide guidelines for status reporting within a team, within all areas for which Integration Leads are responsible, and for the Project Leadership Team on behalf of the project as a whole.
Individual Status Documentation
Team members utilize PRISM as their primary tool to capture work activities and status. All team members have authorization to create new issues and tasks in PRISM. Before creating any new issues or tasks in
PRISM, team members should seek approval from their respective Team Leads. At a minimum, the team members should notify their respective Team Leads when new issues or tasks are identified.
When issues or tasks are documented in PRISM, they may be assigned to individual team members. The assignee documents percentage complete on a regular basis. Upon task completion, the assignee updates the issue or task to “closed.”
Reports are generated from PRISM to address new issues, closing issues, and high risk issues.
Project Status Reporting
The Integration and Team Leads are responsible for maintaining and communicating the status of the work of their teams. In addition to monitoring their team’s progress through PRISM, each lead should hold regularly scheduled status meetings. PRISM documentation and reports, status meetings, and the project plan form the basis for ongoing status reports.
Reports that inform the status reporting process are listed below:
Name Data Source Frequency Description Report Generator
Risk Report PRISM Weekly
New Issues
Report
Closing Issues
Report
Weekly Status
Highlights
PRISM
PRISM
Risk Report,
New Issues Report,
Weekly
Weekly
Weekly
Report generated on a weekly basis from PRISM to show
“Red” (high) risk issues
Report generated on a weekly basis from PRISM to show all issues entered over a specific time frame (past week)
Report generated on a weekly basis from PRISM to show all issues with due dates within the next 30 days
Report prepared on a weekly basis from the Risk and New
Integration Leads and Team Leads
Integration Leads and Team Leads
Integration Leads and Team Leads
Integration Leads
Name
Project Plan
Data Source
Closing Issues Report
Frequency
Integration Team and
Team Leads meeting
Weekly
Description
Task Reports to highlight project challenges and risks
Report prepared on a weekly basis from the team leads meeting discussion of project progress and status
Project Leadership Team Status Report Process
Status Reporting Process
Report Generator
Consulting
Project Manager
Update PRISM
TUESDAY
Ensure Team’s
Status is Updated
FRIDAY PM
Email Reminder for Status Updates
THURSDAY
Update Issue
Status in PRISM
FRIDAY AM
Run and Review
Risk, New Issues,
Closing Issues
Reports
MONDAY AM
INTEGRATION
TEAM AND TEAM
LEADS MEETING
Review Risk, New
Issues, Closing
Issues Reports
Review Project
Plan
MONDAY PM
Prepare Weekly
Status Highlights
TUESDAY
Update the
Project Plan
TUESDAY
Send Weekly
Status Highlights to PLT Members
WEDS AM
Send Updated
Project Plan to
PLT Members
WEDS AM
PLT Meeting
Review Project
Plan and Weekly
Status Highlights
WEDS PM
Provost Status Reporting
The Project Director will utilize the weekly Team Status Reports as the basis of a monthly report provided to the Provost. The monthly report will inform the Provost of project milestone status, monthly accomplishments, upcoming activities, and issue and risk status.
University of Virginia Student System Project
D:\726927898.doc
Page 56 of 68
4/14/2020
Executive Committee Status Reporting
The Project Director will utilize the weekly Team Status Reports as the basis of a monthly report provided to the Executive Committee. The monthly report will address project status regarding:
Budget
Schedule
Scope
Planned business goals
Risks
Issues requiring Executive Committee action
Each of the first five elements of the report will be rated according to risk, as follows:
Red=High Risk; Yellow=Medium Risk; Green=Low Risk
R Y G
Commonwealth of Virginia Status Reporting
The University is required to report progress on and the status of major IT projects on a quarterly basis to an agency of the Commonwealth of Virginia. The Student System Project is a major information technology initiative and thus participates in these procedures and documentation.
The Project Director is responsible for providing a quarterly status report/project scorecard to the Provost who, in turn approves and provides the report to the Chief Information Officer (CIO) of the University. Upon approval, the CIO provides the project’s scorecard to the Commonwealth.
The University’s format for project status reporting to the Commonwealth is found below.
University of Virginia Student System Project
D:\726927898.doc
Page 57 of 68
4/14/2020
Major Project Scorecard
Project Description:
Project Budget and Timeline:
Key Project Indicator
Project Remains Within
Budget
Project Remains within
Schedule
Project Remains within
Approved Scope
Project Remains on Track to
Meet Planned Business
Goals
Project is Managed to
Minimize and/or Mitigate
Identified Risks
KEY:
G =Green/On Track Y
=Yellow/Caution--On
Track, but could become a problem if not addressed
R
=Red/Not on Track/Needs to be Addressed
Project Assessments
Best Practice Independent Verification and Validation (IV&V)
University policy stipulates that projects of the magnitude and complexity of the SSP will adhere to best practices offered by external agencies for software IV&V to help ensure that projects are completed successfully within budget and on time.
The SSP participates in the required IV&V process at appropriate milestones and according to the project quality plan.
Audit
University Auditor
The SSP will engage the Audit Department throughout the implementation to ensure University audit requirements are met in the areas of o Input controls – who can input data in system o Processing controls – who is allowed to modify data o Output controls – who can view and distribute data
University of Virginia Student System Project
D:\726927898.doc
Page 58 of 68
4/14/2020
o Database controls – who can modify data without going through the application o Operating System controls o Network controls – who has access to the network o Methods of access – who makes decision about who gets access and with which roles, etc.
Auditor of Public Accounts (APA)
The University is required to present periodic updates on issues of security to the APA. The Project
Director is responsible for providing these updates via the University Auditor.
Audit of Capitalization Costs
The SSP is required to capitalize all direct costs for the Student System software implementation.
These include payroll expenses for functional and technical staff, development costs including supporting software, and all contracted services and materials directly related to software development. The SSP Business Analyst will prepare reports for the University Auditor.
Project Toolkit
New Employees
As the Project Team grows, new employees will be given a standard orientation by their supervisor or supervisor’s designee. They are encouraged to participate in the University benefits sessions, attend orientation sessions, and interact with direct supervisors, to include seeking out evaluations and counsel.
Employees should review the New Employee Handbook (G:\Administration-SSP\Policies and
Procedures\EMPLOYEE MANUAL.doc) to familiarize themselves with project information. Information includes: obtaining parking passes, how to set up hardware/software, getting email and phone access, setting up voicemail, etc.
University of Virginia Student System Project
D:\726927898.doc
Page 59 of 68
4/14/2020
Standard Project Applications
The standard desktop and/or laptop tool set for team members consists of the following:
Application
Windows
Word
Excel
PowerPoint
Project
Visio
Corporate Time
SharePoint
CaseWise Corporate
Modeler
PRISM
User Productivity
Kit
XP
2003
2003
2003
2003
2003
6.0
2003
10
Version
All project employees must complete security awareness training for the University of Virginia http://www.itc.virginia.edu/security/ as well as the Electronic Access Agreement
(http://www.itc.virginia.edu/policy/form/eaa.pdf) prior to receiving access to the student system or other applications.
No unlicensed software is to be loaded on University equipment.
University of Virginia Student System Project
D:\726927898.doc
Page 60 of 68
4/14/2020
University Readiness
Communications Objectives and Strategic Goals
Objectives
The objectives of the communication plan are to:
Open lines of communication
Manage expectations
Increase awareness of the project
Communicate: o Required involvement o Process changes o Project status and results
Strategic Goals
The strategic goals of the communication plan include:
A well-informed audience
Understanding and acceptance of the project and its goals
Dedication to learning how the new system works and how to operate it successfully
A timely transition from old to new systems
Awareness of change management issues and proactive management of those issues
End User Assistance and Support Objectives and Strategic Goals
Objective
The key objective of the end user assistance and support strategy is to ensure that end users are capable of using PeopleSoft Campus Solutions to fulfill their roles and responsibilities effectively. To achieve this objective, targeted audience populations will be identified and appropriate training activities and methods of delivery developed to accommodate a wide variety of end users with varying degrees of familiarity with technology.
Strategic Goals
The strategic goals of the end user assistance and support strategy include:
The identification of training milestones, which have been incorporated into the overall project plan
The utilization of a User Productivity Kit (UPK)
The allocation of two FTEs for instructional design
The development of a matrix of target end user audiences and training delivery methods
The identification of strategic goals, e.g., a University-wide model for Help Desk support that is transparent to the user
University of Virginia Student System Project
D:\726927898.doc
Page 61 of 68
4/14/2020
Communication and End User Assistance Plan
Approach
Enterprise-wide communication and effective end-user assistance will depend heavily on the contributions of
Functional Team Leads and Project leadership. Functional leads and Subject Matter Experts will serve as primary change and communication agents with personnel in departments and will use standardized communications as defined in the Communication Matrix.
The diversity of individual target audiences affected by and involved in the student system implementation will require a different type, level and frequency of communication and end-user assistance materials for each constituency. Each target audience will have a mechanism for providing feedback, and records of these communications will be maintained to insure action items have been properly addressed.
Continual assessment (formal and informal), structured stakeholder feedback, and user forums will help ensure that stakeholders receive required information and assistance, which will change and evolve during the course of the project. The Communications and Strategic Planning Managers will proactively assess stakeholder needs and recommend communication activity to the Project Leadership Team.
Critical Communication Success Factors
The following conditions are critical to the successful execution of this Communication Plan:
The Executive Sponsor, Executive Committee, and other governance groups understand the importance of communication and will play an active role in key communication events (visible, consistent, and communicative project sponsorship)
Financial support (budget) and resources will be provided to design, develop, and deliver effective communication materials and events
Feedback is confidential and used constructively to improve effectiveness of communications
The following actions are incorporated into all communications activities: o Actively include constituents in all phases of the project o Listen to constituent concerns and suggestions o Follow-through on promises o Provide regular communications early and often o Explain the need for change/why SSP is happening now o Share timely information o Effectively answer the questions, “What is in it for me?, Why should I care?, How does this differ from earlier implementations?” o Receive and respond to ongoing feedback
Approval turnaround for communications is efficient to ensure quality, timely delivery
The Case for Action
A “Case for Action” provides the compelling business case or rationale for undertaking a major initiative such as this. This is an integral message in introducing the Campus Solutions project to the community.
For nearly 10 years, the University of Virginia has been engaged in an effort to replace disparate and obsolete administrative systems with an enterprise-wide, integrated system, consistent with the
University of Virginia Student System Project
D:\726927898.doc
Page 62 of 68
4/14/2020
University’s strategic vision to “transform the University’s physical and administrative infrastructure to support the activities of a top-ranked national university, effectively and efficiently.”
The third phase of the Integrated System Project—the SSP—will replace ISIS, the current student information system of record. The functionality and underlying technologies of ISIS cannot meet current or future administrative or programmatic needs of students, faculty, or administrators. For example: o Because of its aging technology platform, ISIS lacks both the flexibility to meet routine business needs and the ability to effectively incorporate new technologies, despite maximal effort to incorporate web front ends and other modifications. o ISIS was not designed to include a variety of functions that are now requirements at top-ranked institutions, e.g., a real-time course offering directory. It requires significant manual effort to accommodate new programs, fees, and academic schedules. o It is increasingly difficult to change ISIS to accommodate expanding informational and reporting needs.
The SSP affords the University an opportunity to adapt and enhance institutional policies and processes and to provide: o a set of accessible, convenient, effective tools that enable students, faculty, and staff to focus on the substance of their interactions rather than the mechanics o an infrastructure designed to facilitate future enhancements to address changing student and faculty service needs and expectations o a central, information-rich repository that provides an opportunity for enhanced decision making at all levels o an environment with a unified, cohesive “look and feel” in which transactions are entered only once, data elements are consistently named, etc. o more self service features
The implementation of a new student information system provides a technological infrastructure that is up-to-date, integrated, reflects “best business practices,” will evolve to capitalize on future advances in information technology, and provides the adaptability and flexibility necessary to respond quickly to new business needs and requirements.
The new student system helps position the University for growth and change.
Roles and Responsibilities
Leadership Involvement
The Student System Project will result in changes to U.Va.’s core business source documents and processes due to both new system tools and transaction methodology. Successfully implementing these changes will require visible buy-in and support from the Executive Sponsor, members of the Executive Committee, and other governing bodies. One demonstration of active support will be participation in all appropriate communication events and the timely completion of key assignments in support of the Project.
Responsibilities for these executives and directors include, but are not limited to, the following:
Participation in team meetings, key communication events, and required training sessions, as appropriate.
Contribution to newsletters and other internal communications.
Communication of the goals and benefits of the project within their spheres of influence.
Communication Roles and Responsibilities
University of Virginia Student System Project
D:\726927898.doc
Page 63 of 68
4/14/2020
The project director is the official spokesperson for the project. The project office is primarily responsible for project communication. All out-going communications must be routed through the project director, associate director, communication manager, or strategic planning manager to ensure that:
the information is accurate
the message is consistent with the project vision
the writing is clear and understandable
the format and style fit within the established identity of the project
Requests for information from outside or within the University should be routed to the Communications
Manager.
The Communications Manager will work with the project team leads to produce the following deliverables:
Articles and updates regarding the project, primarily for internal communications
Creation and dissemination of project media treatments for use at promotional events, presentations, and special meetings
Planning and coordination of meetings to share the project vision and objectives
The Strategic Planning Manager will work with the project team leads and instructional designers to produce the following deliverables:
Training curriculum/content/materials
Matrix of target training audiences/training content/training calendar
Appropriate feedback mechanisms to monitor effectiveness
The Communications and Strategic Planning Managers interact extensively with governance groups, the project directors, and the project team throughout the project to achieve the following objectives:
Identify audiences and their information/end-user assistance needs.
Identify communication vehicles, meetings, events, and other communication opportunities
Create and disseminate messages
Solicit feedback and monitor effectiveness of communication
Leveraging Communication Efforts
Communication will be based on a Communication and Strategic Planning Matrix , which organizes project stakeholders by specific targeted audience with specific information needs. The matrix determines the form, media, timing, and frequency of communications which will be leveraged through:
A plan that is dynamic and interactive
The integration of communication initiatives with key project events
A clear, expeditious approval process
Messages delivered in a style that underscores the new direction, behaviors, and results
Focus on change “stories” and on behaviors needed for positive business results
Communication of a unified message from the top—leverage leadership
Delivery of key messages by internal staff rather than by consultants—to ensure organizational acceptance
Addressing concerns about the impact of the project on the user community
Consistently-worded key messages in all communication efforts that explain: o What the project is about;
University of Virginia Student System Project
D:\726927898.doc
Page 64 of 68
4/14/2020
o Why the organization is implementing the change and cannot continue with the status quo; o Benefits of the new process; o When key events will occur; and o Who to contact with questions.
Identify Target Audiences
Messages and end-user assistance/training efforts will be geared to each of the following stakeholder audiences, by phase. o Executive Committee o Policy Review Group o Core Advisors to the SSP o Student System Advisory Committee o Provost o Deans o Faculty o Students o Student Process Owners o Staff o Managers, Supervisors o Integrated System Deployment & Support o Information Technology and Communications o Remote sites o Auxiliary units (Student Health, Housing, Parking and Transportation, Dining, IDs, Alumni,
Development o Parents o Alumni/Donors o Board of Visitors o Information Technology Investment Board (to the Vice President and Chief Information
Officer through the Vice President and Provost) o Virginia Legislature, Community of Charlottesville, other external parties o Vendors related to system o Sponsors o Federal and state agencies, accrediting agencies
Vehicles for Communication
Wherever possible, the project will identify and utilize existing communication vehicles, e.g., standing meetings, departmental or school publications, and will employ, as appropriate:
Organizational publications
Memos
Posters
Bulletin boards
Face-To-Face
User Group Sessions
Board meetings
Executive meetings
University of Virginia Student System Project
D:\726927898.doc
Page 65 of 68
4/14/2020
Directors’ meetings
Staff meetings
User forums (brown bag sessions)
User Fairs
Electronic
Website
Videotaped messages for regional sites
Videoconferencing
Monitoring Effectiveness
Throughout the course of the project, frequent assessments will be made to ensure that target audiences effectively receive information, messages, and appropriate training/assistance. Assessments, formal or informal, will be documented and incorporated into future efforts.
Topics for Communication
The following topics will be included in the Communication and Strategic Planning Matrix:
Introduction of the project, project name, goals and expectations
The “case for action,” explaining why we’re doing this and the benefits we will realize
Key metrics to measure success – what will be used, how do we measure against them?
Executive commitment and expectations
Management commitment and expectations
Implementation milestones and timelines
Project status and progress
Budgetary status (actual costs vs. budget)
Identify project team
Impact of implementation effort on operations
Software functionality (what will the software do, overall and area specific)
Glossary of new terms
Preview of business process changes – area specific
Policy and procedure changes / implications
Training strategy and plans
Testing results
Supporting Documentation
Communications and Strategic Planning Matrix
University Readiness Database
Shared Drive
The SSP shared drive provides additional working space on a network server. The server is backed up on a nightly basis by ITC. The shared drive will be the repository for documents in progress. Draft documents are marked as such on each page of the document, preferably in the header. Final versions of all other documentation are housed in folders on the SharePoint site and marked “Final”.
University of Virginia Student System Project
D:\726927898.doc
Page 66 of 68
4/14/2020
Project Team SharePoint Site
The Project Team Site is used as a repository for final archival documentation. It is available to team members.
Community SharePoint Site
The SSP Community Site is available to all members of the SSP governance structure and other key stakeholders. Stakeholders can review documents and provide feedback to project team members.
Issues, status reports, and meeting agendas/minutes are posted to the Community site and portal.
SSP Web Site
The public SSP Web Site at http://www.virginia.edu/integratedsystem/studentSysProj/index.html houses project information of use and interest to the community at large, including status reports, timelines, governance structure, documentation, training information, etc.
University of Virginia Student System Project
D:\726927898.doc
Page 67 of 68
4/14/2020
Appendices:
Appendix One: Current Student System Functionality and Data Flow
MyUVa Portal
Whois/LDAP
Directory
Instructional
Toolkit
Course
Evaluations
Orientation -
Access
Database
Manual
Inputs &
Updates
ISO - fsaAtlas
Library -
VIRGO
VISTAA -
Degree Audit
HR/Payroll
–
Oracle &
Windstar
Billing
Receivable
System
ImageNow
SAS/AF
SFS - Track
SFS - Funds
Management
ISIS Online
Schools
– Admissions, Student
Finance, Registration & Records,
Document Management,
Research, Graduate Studies
Housing -
Oracle
Database
Housing –
Family Hsng
Database
Housing -
Quickbooks
Billing
ISIS
Admission
Registration & Records
Financial Aid
Student Financials
Advising Support
Reporting Data Structure
Resource 25
Institutional
Assessment
& Studies
Blackboard
Comm. Svcs.
- TOMAS
Manual
Tuition & Fee
Inputs
Admission -
AppTracker
Bookstore -
PRISM
ID Card,
Dining – CS
Gold
Parking &
Trans.
–
Power Park
Athletics -
CAi
Course
Offering
Directory
Information Warehouse
ISO - Studio
Abroad
DofS - BIAS
Reporting
Web Site
Advance
Cashiering
Oracle
Financials
Athletics -
Ticketmaster
Student
Affairs -
Database
Hoos
Online
Board of
Elections
Career
Services
DofS - IRIS
(Incident
Reporting
System)
Student
Health -
Medicat
Legend
Brown
–
Executive VP &
Chief Operating
Officer
Green – VP &
Chief Financial
Officer
Red – VP for
Student Affairs
Orange
– VP for
Management &
Budget
Black
– VP &
Chief Information
Officer; systems support and interfaces
Purple
– VP &
Provost
Yellow – VP for
Research &
Graduate Studies
Blue – Senior VP for Development
& Public Affairs
FEDERAL
Common Origination & Disbursement
Central Processing System
SEVIS (Student Exchange Visitor Information System)
Internal Revenue Service National Student Loan Data System
Veteran’s Affairs INS (Immigration and Naturalization Service)
Integrated Postsecondary Education Data System
Information Inputs to and Outputs from External Partners (Reporting, Compliance, Interfaces, etc.)
STATE
State Council for Higher Education of Virginia
Department of Taxation
Auditor of Public Accounts
State Police
OTHER
Campus Partners ViaKlix Tuition Management System
Bank Of America Collection Agencies Chickering
ELM (Federal Family Education Loan Program)
Educational Testing Service American College Test Semester at Sea
National Student Clearinghouse Credentials, Inc College Board
Southern Association of Colleges and Schools National Collegiate Athletic Association
Atlantic Coast Conference American Football Coaches Association
U.S. News and World Report Association of American Universities Data Exchange
National Research Council Southern University Group etc.
