Project Charter Document

University of Colorado
STUDENT INFORMATION SYSTEM

REPLACEMENT PROJECT
Note: This document is a DRAFT Project Charter for replacing the
University's current SIS. It represents the collective input of more than
100 members of the University community from all of the campuses and
the System Office. The SIS Project Advisory Committee served as the primary
reviewers of this document. Additional input is welcomed from others in
the University community. Please send your comments to:
trish.pottersmith@cusys.edu
PROJECT CHARTER
Prepared David Makowski, Assistant Vice President, University of Colorado
By: Trish Pottersmith, Director of SIS Development, University of Colorado
Lisa Fliam, Project Manager, CIBER Inc.
Bruce Moore, Manager, CIBER Enterprise Solutions
Date: 5/7/2019
Abstract: This document describes the business case, objectives, scope and
potential risks for the Student Information System (SIS) Replacement project the
University of Colorado. It is the primary output of the Planning Definition phase
for this project, and should be updated to reflect new information developed during
the Project Planning phase.
The University of Colorado and CIBER, Inc.

CHANGE HISTORY
VERSION DATE CHANGED BY CHANGE
0.1 4/25/2005 Bruce Moore Original Charter Outline and CIBER templates
0.2 5/10/2005 Bruce Moore Charter Outline with potential objectives, risks,
and other summary information.
0.3 5/19/2005 Bruce Moore Incorporates changes from SISG+ Advisory
Group review.
0.4 5/20/2005 Bruce Moore Consolidated objectives, risks and other
executive summary items to provide for clearer
and more uniform presentation.
0.5 5/26/2005 Bruce Moore Incorporated feedback from validation meetings,
drafted Project Principles, expanded and revised
the Governance section.
0.6 5/26/2005 Bruce Moore Drafted introductory materials, including
strategic drivers and high-level Project Timeline.
Recast Project Principles to better summarize
them.
0.7 6/1/2005 Bruce Moore Re-summarized executive summary, moved
details into Project Overview or detailed sections
as appropriate and corrected formatting.
0.8 6/13/2005 Bruce Moore Incorporated edits from SISG+ meeting
6/10/2005. First draft including all detail areas
except Vendor Selection. Also added Project
Definition Phase Overview to the executive
summary.
0.9 6/29/2005 Bruce Moore Final draft incorporating SISG+ member edits,
and edits to Strategies and Controls areas. Also
completed Vendor Selection Strategy, and
appendices.
1.0 7/25/2005 Bruce Moore and First approved version for internal release.
David Makowski

Table of Contents
CHANGE HISTORY ....................................................................................................................................................II

EXECUTIVE SUMMARY ............................................................................................................................................1
INTRODUCTION .............................................................................................................................................................1
PROJECT DEFINITION PROCESS OVERVIEW...................................................................................................................3
SUMMARY RECOMMENDATIONS...................................................................................................................................4
STRATEGIC BUSINESS DRIVERS ....................................................................................................................................5
PROJECT OBJECTIVES ...................................................................................................................................................6
PROJECT PRINCIPLES ....................................................................................................................................................7
PRELIMINARY PROJECT TIMELINE ................................................................................................................................7
SCOPE ...........................................................................................................................................................................9
RISKS.......................................................................................................................................................................... 12
PROJECT OVERVIEW .............................................................................................................................................. 13
BUSINESS CASE .......................................................................................................................................................... 13
DETAILED PROJECT OBJECTIVES ................................................................................................................................ 16
DETAILED PROJECT PRINCIPLES....................................................................................................................... 19
DEPENDENCIES ........................................................................................................................................................... 23
PROJECT STRUCTURE ............................................................................................................................................ 24
ROLE DESCRIPTIONS .................................................................................................................................................. 28
PROJECT OPERATING AGREEMENT ................................................................................................................. 34
DECISION MAKING AGREEMENT ................................................................................................................................ 34
TEAM OPERATIONS .................................................................................................................................................... 38
PROJECT MANAGEMENT STRATEGIES ............................................................................................................ 40
VENDOR SELECTION ................................................................................................................................................... 40
PROJECT PLANNING .................................................................................................................................................... 45
TESTING ..................................................................................................................................................................... 45
TRAINING ................................................................................................................................................................... 48
DOCUMENTATION ....................................................................................................................................................... 51
DEPLOYMENT ............................................................................................................................................................. 52
CHANGE MANAGEMENT ............................................................................................................................................. 53
PROJECT COMMUNICATION ........................................................................................................................................ 54
PROJECT MANAGEMENT CONTROLS ............................................................................................................... 56
DECISION-MAKING AND ISSUE ESCALATION PROCESS ............................................................................................... 56
ISSUES MANAGEMENT ................................................................................................................................................ 56
POLICY MANAGEMENT ............................................................................................................................................... 59
CHANGE CONTROL ..................................................................................................................................................... 60
DELIVERABLE ACCEPTANCE ...................................................................................................................................... 62
QUALITY ASSURANCE ................................................................................................................................................ 62
RISK MANAGEMENT ................................................................................................................................................... 63
APPENDICES .............................................................................................................................................................. 70
APPENDIX 1 – PROJECT CHARTER INTERVIEWEES ...................................................................................................... 70
APPENDIX 2 – INITIAL FUNCTIONAL REQUIREMENTS ................................................................................................. 71
APPENDIX 3 – SAMPLE ISSUES TRACKING LOG .......................................................................................................... 81
APPENDIX 4 – SAMPLE DELIVERABLE ACCEPTANCE FORM ........................................................................................ 82
APPENDIX 5 – SAMPLE RISK MANAGEMENT LOG ....................................................................................................... 84
APPENDIX 6 – VENDOR EVALUATION APPROACHES ................................................................................................... 85

Project Charter Executive Summary
Executive Summary
The purpose of this document is to provide information to University decision makers regarding
the need for a project to select and implement a system to replace the University of Colorado’s
Student Information System (SIS). The executive summary provides historical information on
SIS, describes why a replacement is needed, and defines the high-level need, objectives and
scope for a possible replacement project.
The sections following the executive summary outline proposed project governance, project
management strategies and controls that CU can use in the course of a phased replacement
project.
Introduction
The Student Information System (SIS) has served the University of Colorado’s needs since 1988.
SIS is the authoritative system of record for core student data including, but not limited to
Admissions, Advising, Student Records, Student Billing and Receivables and Financial Aid.
Over 4,000 administrators, faculty and staff from all CU campuses use SIS (or SIS data through
other downstream systems) to support their academic and administrative needs; and more than
60,000 students have direct web-based access to SIS, using self-service applications to assist
them with their student administrative needs. The Student Information System is one of the
most mission-critical systems for the University of Colorado.
The University of Colorado is one of 22 institutions of higher education that implemented a

version of SIS that runs on the Computer Associates Integrated Data Management System (CA
IDMS) platform. This data management system, or database system, was designed to run on
IBM mainframe computers, and the combination was a strong choice in the mid 1980s, when this
version of SIS was selected and implemented at CU.
Both technology and the needs of higher education have changed considerably in 20 years.
Recognizing that CU’s needs were outstripping the capabilities of SIS, University Management
Systems (UMS), in consultation with current SIS users at CU, undertook a project to extend the
life and functionality of SIS in 1998. This project had the support of SCT (the vendor for SIS),
and achieved significant success. However, even then it was apparent that this solution was not a
viable long-term strategy.
By 2002-2003, vendors for the SIS application, and for the core technical infrastructure it relies
were moving away from supporting this type of application. Specifically,
 Computer Associates (CA, the database vendor) was “deemphasizing” support for IDMS
in favor of newer technologies, and
 SCT (the vendor of the SIS application) had plans to discontinue support of SIS in favor
of newer product lines.
 Other software support tools critical to the operation of SIS on the mainframe are ending
their lifecycle and will become less reliable or expensive to replace.

Page 1 of 91
During 2004, CU system and campus academic staff conducted preliminary interviews and
research to determine the need for, and feasibility of, a SIS replacement. This effort developed
greater urgency in June of 2004, when SCT announced that they would discontinue support for
this version of SIS in 2009. Further, the retirement of core technical staff presents CU with even
a more significant risk than loss of SCT support because CU relies more heavily on the expertise
in UMS than on SCT support. Because of core SIS technologies are no longer mainstream, there
is no pool of qualified people from which to recruit, nor are there any training classes to train
new staff.
These interviews also made clear the fact that SIS is not keeping up with the needs of its users, or
the broader demands of higher education in the internet age. SIS is a “back office, batch driven,
expert user” system that requires training and experience to use, and in which the data used to
make decisions can be days or weeks old. Today’s students (and other users) expect 24 hour a
day, 7 day a week access to information, and they expect to see near real-time data. Current
off- the-shelf systems offer near-real time, 24x7 access, and allow a much broader audience
including back office administrative staff, faculty and students to all have access to the
information they need through intuitive web-based pages.
SIS has provided CU good service over 20 years, and the University has extended SIS’s
operational lifetime through several internal initiatives, such as the 1998 project mentioned
above. However, the system’s operational lifetime is nearing its end, with a known cutoff of
support in 2009. Any project involving a system this complex, and with this many functions and
users will require several years to define, plan and implement. CU must begin considering
replacements now.
SIS Replacement Options

The SIS Governance group considered options for a potential SIS replacement, which include:
Continue to use the existing application after vendor support is discontinued. CU staff would
maintain and extend the application, as they have done in past. However, as noted above, the
application, database and operating system technologies are all becoming outdated, and will not
be updated or improved by their respective vendors. Further, the pool of technical staff with
skills in these technologies is shrinking, and there are no courses offered by vendors to train new
staff. SIS is an enterprise system at CU, and the risk of a significant system failure is simply
too high to consider this option.
Build an in-house Student Information System. CU staff would select a newer technology,
define the ideal system, build and maintain it. 20 years ago when there were fewer strong “off
the shelf” products available, some universities made this choice. Unfortunately, this option is
not recommended because it is prohibitively costly in time and effort. CU would first have to
pick a technology to use for development, learn it, and then start the development project. The
software industry estimates that one trained and experienced person can write 30 to 50 lines of
software code per day, and the existing (functionally inadequate) SIS contains more than 2
million lines of code. It would take between 40,000 and 60,000 person days to program a new
system. The most optimistic estimate, assuming a dedicated 40 person technical staff, requires

Page 2 of 91
more than three years for programming tasks alone, ignoring all functional definition and design,
testing, documentation, training, etc. A more realistic estimate would be ten years for the
implementation project. Once the project is completed, the University becomes the only user of
the application, and must dedicate significant resource to the long-term maintenance and
improvement of the application.
Select a proven vendor in the higher education market. CU will explore the costs and effort
required to implement the application offered by vendors with a proven record at complex,
research one institutions like CU. Assuming that total project costs are acceptable, this is the
option recommended.
Project Definition Process Overview

By early 2005, the SIS Governance committee and others had determined that a project to extend
or replace SIS was needed, and contracted with CIBER to conduct a “Project Definition” effort
to better understand potential project scope, objectives, strategies and controls. One goal of the
project definition phase was to be as inclusive as possible, and hence multiple meetings were
held on each campus. In order to facilitate review and editing of this document while
maintaining the widest participation possible, the membership of the SIS Governance (SISG)
group was broadened to include representatives of faculty and academic administrative staff
from each campus, as well as System Administration staff. This broader group was named the
SISG+ Advisory Group, and served as the primary reviewers of this document.
Project Definition Phase

The project definition phase1 is a crucial first formal step in every project. It establishes a
foundation for the project by ensuring that all project participants share a clear understanding of
the project goals and agree on how these objectives will be achieved. By working through this
process, CU defined the project vision, scope, and objectives – what the project is designed to
achieve. The process included group meetings at each campus to inform and solicit feedback
from potential project stakeholders, and to begin to identify potential project team members –
those who will participate in the implementation. These interviews were the first key
communication points through which CU personnel had an opportunity to provide input and
ideas on not only how the new SIS system should be implemented, but also why it should be
implemented and on what goals/milestones implementation success or failure will be measured.
The project definition phase began with a review of existing project documents2, and individual
interviews with UMS executives and staff who are involved with supporting the current SIS. The
members of the SIS Governance group spoke with their respective campus leadership and jointly
compiled lists of potential interviewees on each campus, in the following categories:
 Academic administrators (e.g.: Associate Deans and/or Associate Vice Chancellors)
1
Classic project management uses five phases: Initiate, Plan, Execute, Control, and Close. For this project CU
combined all Initiation and some Planning activities into one project “Definition” phase.
2
Existing project documentation includes meeting minutes from SISG meetings, and from meetings CU held with
other users of the IDMS version of SIS, UMS planning documents, vendor demonstration notes and evaluations, and
“lessons learned” from previous system implementation projects at CU.

Page 3 of 91
 Academic departmental administrators (e.g.: daily users of SIS)

 Other consumers of SIS Data (e.g.: Housing Office, Library, Campus Bookstore)
All invitees to these interviews received an introductory document explaining the project
definition phase, and the intent of the requirements gathering meetings. During the last week of
April and the first week of May 2005, a total of seven two-hour requirements gathering meetings
were conducted (two at UCDHSC, three at UCB, and two at UCCS) with the groups identified
above. During these meetings, participants were asked to contribute potential project objectives,
risks and functional requirements.
The results of these meetings were summarized into a PowerPoint presentation outlining
proposed objectives, risk and draft scope. This presentation was emailed to the same list of
initial invitees, to request validation. During the week of May 23rd 2005, one validation meeting
was conducted per campus to solicit feedback on the work done so far.
In addition to campus interviews with these groups, members of the SIS project team (including
project management staff, and SISG members) provided informational updates to faculty
governance groups, Deans, Department Chairs, and various Vice Chancellor groups on each
campus.
The deliverable for the project definition phase is this project charter document.
Summary Recommendations
At the conclusion of the project definition phase, the members of the SISG+ Advisory Group
recommend the following:
1. The SISG+ Advisory Group believes that the existing SIS should be replaced with a
commercial, vendor-supported product, and not attempt to extend the life of SIS through
the use of in-house staff.
2. SISG+ recommends that CU should continue to pursue a phased project management
approach to this project, with formal decision points at the end of each phase. This limits
the University’s financial and resource exposure to one phase only, and allows CU to
arrive at a much more accurate estimate of the final project cost and effort even before
selecting a vendor or incurring contractual obligations.
3. SISG+ recommends that CU approve funding and resources to move into a requirements
definition phase, during which the University will compile complete functional and
technical requirements for a new system, and engage in detailed evaluations of the top
candidate systems.
At the end of the requirement definition phase CU should have more accurate total estimate of
project cost and effort, and a clear understanding of which of the possible vendor applications
will be the best fit for the University.

Page 4 of 91
Strategic Business Drivers

There are several strategic business drivers for the SIS Replacement project.
Changing Higher Education Environment: The business environment and fundamental needs
of Higher Education have changed in the last twenty years, and the ability of the current SIS to
adapt to these changes has decreased over time.
Loss of Vendor Support: In June 2004, SCT (the vendor for SIS) notified CU that support for
this version will be phased out in 2009. An unsupported system will be more costly (perhaps
prohibitively so) for CU to maintain, and puts the university at risk of a system failure. This loss
of vendor support creates several related business drivers:
 Declining Use at Peer Institutions: Of the 22 original users of SIS, 17 have moved to
new systems, and the remainder will in the next few years. As the number of user
institutions shrinks, CU loses both vendor leverage, and a qualified pool of potential new
hires with experience with this product and its technical components, such as COBOL.
 Dated Technology: The current version of SIS is based on dated technology that is no
longer mainstream, and that will not be significantly improved moving forward. This
limits CU’s ability to upgrade functions, interface with other applications and perform
system maintenance.
 Staffing Concerns: The combination of loss of vendor support, loss of peer users and
aging technology presents CU with a staffing risk, since the pool of individuals with
experience with this application is shrinking.
Opportunities Presented by New Technology: In the nearly twenty years since SIS was
implemented, both the functionality and technology of “off the shelf” software systems have
dramatically improved. Moving to a new application will provide for a much more intuitive,
easier to use system, easier and broader access to information, and greater flexibility to meet
centralized and decentralized needs, and CU’s evolving needs. Also, today’s students expect
nearly continuous and real-time access to university information systems. SIS doesn’t allow this,
and its core design and technology will never truly allow this.
User Support for Change: During project definition interviews with more than one hundred
current and potential users of SIS, there was significant support for replacing the current system.
Most interviewees felt it was time to move to a system that was easier to use, and more flexible.
This confluence of user and community support should not be wasted.

Page 5 of 91
Project Objectives
Potential project objectives were derived from existing documents and from facilitated
interviews with stakeholders on each of the CU campuses.
The summary objectives below provide the highest-level view of goals for the project. These are
further supported or amplified by the detailed project objectives in the body of the report below.
Summary Objectives
Objective 1: Provide a system that substantially improves service to students, faculty, staff and
other users, and that supports institutional initiatives, taking into account growing service
demand, and stable or shrinking staffing and fiscal budgets.
Objective 2: Implement one integrated University system of record for student and program data
that allows for the flexibility to meet specific campus and academic unit needs. Ensure that
project and production processes, structure and staffing consider centralized and decentralized
needs and approaches.
Objective 3: Improve the quality and timeliness of the institutional and student data CU
maintains, and ensure that data quality continues to improve.
Objective 4: Empower end-users with access to integrated data for analysis to support
operational and strategic decision-making.

Page 6 of 91
Project Principles
Project principles do not directly lead to a project deliverable or output, but provide the
framework for making informed decisions, and foster the successful achievement of project
objectives. These principles were derived from lessons learned during the implementation of the
Administrative Streamlining Project and other sources about successful project management.
If the SIS Replacement Project is approved, CU will follow the principles articulated below
during the planning and implementation phases of the project. The summary principles above
are further supported or amplified by the tactics noted in the project overview below.
The summary objectives below provide the highest-level view of goals for the project. These are
further supported or amplified by the detailed project objectives in the body of the report below.
Summary Principles
Principle 1 - Formal project management: CU will implement and execute formal project
management processes to ensure the success of this project. These will be based on project
management best practices and lessons learned from previous implementation projects at CU,
and will be adapted to the specific needs and structure of this project.
Principle 2 – Inclusive project governance: CU will establish a project governance structure that
involves faculty, staff, and students; the campuses and system administration; and executives,
functional and technical system users appropriately. This structure, those appointed to it, and
their attendant responsibilities will be made publicly available on the project website.
Principle 3 – Transparent project decision making: CU will establish a decision-making process

that is transparent, clearly documented and that takes into account the different kinds of
decisions (strategic, tactical, operational) and the scope of effect (system configuration,
departmental, university-wide, etc.) these decisions may have. Decisions will be made by the
appropriate groups or individuals.
Principle 4 – Open and effective communication: The project will include full, open and
collaborative communication to all university and other affected constituencies.
Principle 5 – Balance of scope and needs: CU will make every effort to achieve the best balance
between a technology replacement project, and one including business processes improvement.
Preliminary Project Timeline

At this early stage of the project the timeline is very high level, and summarizes major phases
and near-term decision points. At each of the decision points noted below, CU should evaluate
the work done to date, and formally decide whether or not to proceed to the next phase. At each
decision point, the University may determine that the costs of proceeding are too high, and may
close, delay or diminish the scope of the project. In this way, the phased approach limits the

Page 7 of 91
University’s cost and resource liability, while gathering the information needed for a complete
cost and effort estimate.
This timeline will be updated as upcoming project decision points are successfully passed, and
project details and timing are better understood.
 2003-2004: Preliminary research, initial vendor demos
 April-June 2005: Project definition interviews and charter
 July-September 2005: More communication about the proposed project and additional
feedback on the draft charter. Gather additional detailed information on functional
requirements for a new system.
 October 2005: Decision point – Phase 2 approval and funding to proceed with
detailed requirements definition
 October 2005-March 2006: Detailed requirements definition

 additional vendor overview and demonstration sessions
 requirements gathering and documentation
 begin to refine project scope both as to modules to be implemented, and the
degree of business process improvement to be included
 estimate costs and effort required for the entire implementation project
 Spring 2006: Decision point –Vendor selection, and funding approval for
implementation planning
 Summer-Fall 2006: Project planning phase

 create detailed project plan
 update project charter to reflect implementation plan
 finalize appointments to project governance structure, including vendor and
consulting support
 finalize project budget
 put project control structures in place
 Late 2006 – Early 2007: Decision point - Project launch, and funding approval for
implementation
 2006 – 2010: Project implementation and roll-out phase

Page 8 of 91
Scope
Project scope is used to define what major system functions, modules and interfaces will be
included in the funding, planning and implementation effort of the project. It is important to
define both what will be included in scope, and what will not be in scope, so that this information
is clearly presented to all project stakeholders.
The project scope does not include a detailed listing of functional or technical requirements,
which will be developed in the functional requirements phase later. Rather, scope is used to
ensure that candidate systems include major critical functionality, and also to begin to estimate
project cost and effort at a high level.
As the project progresses through definition, detailed requirement definition, and to vendor
selection the scope will be refined. Prior to implementation planning, the project scope must be
clearly and completely defined. Any changes in scope after the implementation phase begins
must be handled through change control, and are very likely to affect the project schedule,
resources and cost.
One of CU’s most significant scope concerns is whether this should be a “straight technology
replacement project” or one that includes significant business process improvement. This has
implications beyond cost and duration of the project, since it impacts and is affected by
university culture, previous system implementation experiences, and current and planned change
management processes. This discussion must happen at the highest level, and across the
university community; any decision must be made prior to the project planning phase, since this
decision has a profound effect on implementation approach and planning.
In Scope
At this time (the project definition phase) the items included in scope are derived from two
sources:
1. Major functions that are present in the legacy system, and that must be carried forward
into the new system.
2. Major functions that are known to be present, or required as core functionality, in any
candidate new systems.
The Student Information Systems replacement project at CU will include the implementation of
at least the following modules or functions:
 Admissions, Recruitment and Customer Relationship Management
 Degree Audit, graduation check out and transfer credit
 Course and classroom scheduling
 Course inventory
 Student Records and Registration
 Financial Aid, including information on student employment
 Billing and Receivables System
 Data on course instructors and teaching assistants
 Academic Advising

Page 9 of 91
 Workflow and automation tools to enhance productivity

 Self-Service functionality for students, faculty, staff and others (such as online
gradebook, online class rosters, and other similar functions perhaps provided through a
portal)
 Provide better support for undergraduate, graduate and professional programs, as well as
Continuing Education, Online and Extended Studies, and other constituencies.
 Data warehousing and reporting
 Interfaces to other internal and external systems, to be defined in a later phase of the
project.
 Information about academic programs from degrees to major options to certificates.
 Implementation of portal strategy, either by studying integration with existing portal
implementations or through the vendor provided portal.
Possibly In Scope
The list below contains third-party modules that are candidates for inclusion in scope. Each of
these should be explicitly evaluated for its benefit to the University, and the likely cost of
inclusion, during the detailed requirements definition phase of the project. Prior to the beginning
of implementation planning, each of these items must be explicitly included or excluded from
scope.
 Document Imaging (two possibilities: an integrated solution; or extending or
consolidating the existing solution for all campuses)
 Document Management, including electronic forms (two possibilities: an integrated
solution; or extending or consolidating the existing solution for all campuses)
 Implementation of some or all functions of a vendor-provided portal, versus integration
with existing portal implementations.
 Better integration with or incorporation of campus shadow systems such as new-student
orientation, study abroad, pre-collegiate, etc.

Page 10 of 91
Not In Scope
Finally, this list includes some functions or modules that are probably not in scope for this
project. This list was derived from the following sources:
1. Major functions that are currently handled by other systems at one or more of the CU
campuses, especially where those systems already provide acceptable service.
2. Major functions that are not present in candidate new systems.
This list is not exhaustive, and only includes functions that were identified in project discussions
to date. The list should be updated as other functions are identified and excluded from scope.
Specifically, this list should be updating during the implementation, when a scope change is
rejected after passing through change control.
The following functions, modules or applications will not be included in the scope of this
project, however each must be interfaced with the SIS replacement as appropriate:
 Learning Management System (i.e.: WebCT or Blackboard)
 Housing Management System
 Library Management System
 fsaAtlas for SEVIS compliance

Page 11 of 91
Risks
The University of Colorado will implement a comprehensive risk management process as
described later in the project controls section of this document. This process will be used to
identify and manage risks throughout the project, and will be an on-going and dynamic process.
A detailed list of preliminary project risks and potential mitigation strategies appears in the risk
management section of this document, however two of the initial risks and potential mitigation
strategies are presented here as examples:
EXAMPLES OF PROJECT RISK POSSIBLE MITIGATION

Enterprise Resource Planning (ERP) System 1. Plan and execute a comprehensive
Project Credibility communication plan. Include regular
Previous enterprise system initiatives have updates to stakeholders through various
had mixed success, which causes a credibility communication channels.
gap for this project. 2. Ensure that this project’s principles and
plan include the lessons learned from
earlier CU ERP projects.
3. Fund and involve Project Liaisons for
each campus, and ensure that campuses
and departments have opportunities to
participate, and provide feedback
throughout the project.
4. Hold a project-wide kickoff meeting that
includes all project members from the
team up through the Executive Sponsor.
5. Provide early overview, demo and training
opportunities for team members and other
stakeholders to become familiar with the
process.
6. Ensure that the project team includes
experienced vendor and consulting
support.
Project “Sticker Shock” 1. Begin communicating the reasons this
The realistic cost of the project will cause project is necessary now, and
negative push-back from both university and communicate this widely.
external constituencies. 2. Clearly explain how this project will
(positively and negatively) affect support
The project may not secure adequate funding for students, faculty and staff.
for the desired scope. 3. Ensure that the project budget and scope
is realistic both in terms of achieving
project objectives, and in the context of
the University’s other priorities.
4. Provide cost estimates as soon as they are
sufficiently understood.

Page 12 of 91
Project Charter Project Overview
Project Overview
Business Case
The initial impetus for a SIS Replacement project came from the vendor of SIS (SCT) who
notified CU that support for this release of the system would be discontinued in 2009. Although
this is a significant concern, it is important to note that this is not the only factor CU considered
when evaluating the need to replace SIS. As noted in the executive summary, there are several
strategic business drivers for the SIS Replacement project. Some of these are “negative” drivers
(i.e.: the loss of vendor support), but it is important to note that this project also presents CU with
several positive opportunities.
Changing higher education environment: The business environment and fundamental needs of
higher education have changed in the last twenty years, and the ability of the current SIS to adapt
to these changes has decreased over time. The current SIS was based on a high volume
administrative business office support model, and higher education business process from the
early 1980s. New applications will better reflect the new business processes, and the new data
and information needs relevant to higher education in 2005 and the future. New systems are
designed to be more flexible and extendible, to better meet the demands of expanded clientele,
including faculty, staff and students. New systems are also designed to support on-demand and
real-time access to data, and to provide better automation and workflow, which allows
universities to be more nimble in meeting customer needs.
Opportunities presented by new technology: In the nearly twenty years since SIS was
implemented, both the functionality and technology of “off the shelf” software systems have
dramatically improved. These offer:
1. Much simpler and more intuitive end-user navigation, which allows users to become
effective in a shorter time, and expands the potential user community beyond “expert
back-office users” to faculty, students and other infrequent users.
2. The ability to audit and store a great deal more information than SIS.
3. Much easier end-user access to data through reporting and interfaces.
4. Easier technical support and maintenance of the system.
5. Much easier integration and interfacing with other internal systems (i.e.: the Library
database, the CIW, etc.) and external systems (Department of Education, etc.)
6. Vendor-delivered support for new federal mandates, such as SEVIS and the Patriot Act.
7. Higher system availability, because of improved batch processing.
User support for change: During project definition interviews with more than one hundred
current and potential users of SIS, there was significant support for change. Most felt that SIS
had provided good service, and that CU had done an excellent job extending its lifetime. But
most interviewees felt it was time to move to a system that was easier to use, and more flexible.
This presents CU with a unique opportunity: Large system implementation projects involve
significant cost, effort and change, and are almost always resisted by some portion of the user
community. Further, CU has had mixed success with some previous implementations, leading to

Page 13 of 91
natural concern over attempting another. Despite that, the interviewees generally felt this project
was necessary. This confluence of user and community support should not be wasted.
Loss of vendor support: In June 2004, SCT (the vendor for SIS) notified the loose consortium
of schools using the IDMS version of SIS that support for this version will be phased out in
2009. SCT offers two newer product lines that provide the same service (and significantly
enhanced functionality), so it is not cost-effective for the company to continue to support this
older technology. Because CU has a significant development staff in place to support SIS, the
loss of vendor support primarily affects the Financial Aid module, which requires frequent
regulatory updates and these were always provided by the vendor. However, CU has always
been able to use vendor support for updates and bug fixes, and this will no longer be true.
Opportunity for improved vendor support: While the loss of vendor support for the IDMS
version of SIS presents a challenge, there is a concomitant opportunity: CU will be moving to a
newer, more supported system. Given the improvements in technology over the last 20 years, it
is likely that more of the functionality CU needs will be delivered “out of the box” and less
customization will be required. As a result, CU should experience better vendor support, for a
larger portion of the system than has recently been the case. This may allow CU staff to
concentrate more on extending the functionality and reach of the application (through interfaces,
reporting and configuration), and less on routine maintenance.
Declining use at peer institutions: As noted above, CU was one of 22 schools that originally
implemented the IDMS version of SIS. Over time, all but five of those schools have moved to
other systems, and as of June 2005, the remaining five schools are actively considering SIS
replacements. Sharing common technology with other schools gives CU greater leverage with a
vendor, and provides for a common pool of technical and functional experience. As this pool
shrinks, CU loses both vendor leverage, and a qualified pool of potential new hires with
experience with this product.
Dated technology: The IDMS version of SIS is based on dated technology that is no longer
mainstream, and that will not be significantly improved moving forward. This has several
effects:
1. CU is limited both in the ease with which modifications to the system can be made, and
in the amount of time and effort each requires.
2. The effort to integrate or interface this system with others is much greater than current
technology allows.
3. System updates and maintenance require longer than they would with newer technology.
As a result, the system does not provide high availability.
4. The pool of individuals with technical expertise with this system is shrinking, and staff
turnover and retirements will affect CU’s ability to effectively support the application.

Page 14 of 91
Staffing concerns: The combination of loss of vendor support and aging technology presents
CU with a staffing risk.
1. If CU has to assume full support for SIS when vendor support expires, this would likely
result in a need for more staff, during a time when service demand is rising, and staffing
levels are projected to remain stable, or shrink.
2. The pool of individuals with technical expertise with this system is shrinking, and staff
turnover and retirements will affect CU’s ability to effectively support the application.

Page 15 of 91
Detailed Project Objectives

The detailed objectives below were derived from documents compiled over the last several years,
as CU considered the future of SIS, and from the project definition interviews conducted in
preparation for this project charter. Summary objectives are re-stated here, with supporting
objective for each noted below.
Objective 1: Provide a system that substantially improves service to students, faculty, staff and
other users, and that supports institutional initiatives, taking into account growing service
demand, and stable or shrinking staffing and fiscal budgets.
 Select and implement an application that provides workflow and automation tools that
enhance productivity, and provide more effective communication with prospective students.
 Implement a system based on flexible technology that can support evolving institutional
priorities and end-user needs.
 Implement “self-service” applications to allow students, faculty, staff and other system
constituencies to have direct access to their own data.
 Implement an application whose core end-user functions accommodate infrequent users, and
do not require extensive training to use them effectively.
 Maintain the capabilities of the current system (i.e.: don’t lose any of the critical
functionality CU modified the current SIS to achieve).
 Provide easier access to information through tight integration with the portal, and through
the implementation of easier reporting tools.
 Provide better integration of and service to Online and Extended Studies, Continuing
Education, Study Abroad, medical campus and other users who were not effectively served
by the legacy application.
 Select a system based on technology that provides real-time or near real-time interfaces
between appropriate internal and external entities.
 Implement a system that provides robust and configurable security, and that will effectively
implement relevant federal and state legislative requirements, as well as University policy.
 Utilize tools and technologies that make it easier to exchange data with both appropriate
internal systems (i.e.: course management systems, library, bookstore and housing) and
outside entities (other databases, vendors, Department of Education, etc.).
 Implement the necessary technical infrastructure to expand the provision of high system
availability and reliability, moving toward near 24 hour per day, 7 day per week, 365 days
per year.

Page 16 of 91
Objective 2: Implement one integrated system of record for student and program data, that allows
for the flexibility to meet specific campus and academic unit needs. Ensure that project and
production processes, structure and staffing consider centralized and decentralized needs and
approaches.
 Implement a system that allows for a single, university-wide view of student (and other) data,
but that also allows for customized, focused views, as required by campuses or academic
units.
 Implement a system that allows CU to easily record credit, non-credit and other “learning
activities” and choose how this information is reported.
 Implement a system that allows CU to track both standard academic term-based and non-
standard academic term-based programs and activities.
 Develop a process and structure that provides robust, ongoing, updated documentation, both
during the project and after the cutover to production.
 Develop a process and structure that provides robust, ongoing, updated training, both during
the project and after the cutover to production. Ensure that training is provided at the right
time for a given audience.
 Implement an application with configuration options and a development toolset that allow
campuses and academic units (when appropriate) to create custom views of data, to easily
add data elements as needed, and to create custom workflow and reporting.
 Ensure that any significant changes to the centralized/decentralized model are properly
planned, budgeted, and staffed for success through implementation and into production.
Ensure that any functions that require increased training or effort from departmental staff are
appropriately identified and supported.

Page 17 of 91
Objective 3: Improve the quality of the institutional and student data CU maintains, and ensure
that data quality continues to improve.
 Work to understand and clean up legacy data, before and during conversion into the new
system.
 Utilize the greater flexibility, detail and “granularity” of a new system to track data CU can
not currently store in SIS.
 As appropriate, consider revising business processes and adopting best practices to ensure
consistency in handling data, while taking into account the differing needs of campuses and
units.
 Use delivered software controls to assure data standardization and integrity.
 Where appropriate, allow the individuals who “own” or are closest to data to perform data
entry, rather than centralized staff who are less familiar with it.
 Ensure that any significant changes to the centralized/decentralized model are properly
planned, budgeted, and staffed for success through implementation and into production.
Ensure that any functions that require increased training or effort from departmental staff
are appropriately identified and supported.
 Where possible and reasonable, consolidate disparate “shadow” databases into the single,
enterprise repository.
Objective 4: Empower end-users with access to integrated data for analysis to support operational
and strategic decision-making.
 Take advantage of both existing and improved portal and data warehouse capabilities to
provide users with integrated access to multiple data sources.
 Where desirable, consolidate disparate “shadow” databases into the easily-accessed
enterprise repository.
 Deliver a common tool set to end-users for data reporting, extraction and analysis. Provide
users with the knowledge, training and capacity to enable them to perform their own
reporting.
 Utilize tools and technologies that make it easier to exchange data with both internal systems
(course management systems, library database, bookstore, housing database) and outside
entities (other databases, vendors, Department of Education, etc.).

Page 18 of 91
Detailed Project Principles

The project principles below were derived from lessons learned during previous system
implementations at CU, and from implementation experiences at other institutions of higher
education. These guiding principles will affect project structure, project operational and
administrative processes, and the interaction of the project with the larger University community.
Principles do not directly lead to a project deliverable or output, but support a better project
environment, and foster the successful achievement of project objectives.
Summary principles are re-stated here, and further amplified by the tactics noted in the table
below.
Principle 1: CU will implement and execute formal project management processes to ensure the
success of this project. These will be based on project management best practices and lessons
learned from previous implementation projects at CU, and will be adapted to the specific needs
and structure of this project.
 CU will use the project definition phase and charter document to establish clearly why the
project must be done, project objectives and scope, project governance and structure,
project controls and management strategies, and suitable method(s) for monitoring progress
and success.
 The implementation and deployment plan will include the transition to production, and will
attempt to predict and respond to the issues and needs of a post-production environment.
 CU will assess training, documentation and reporting needs as part of implementation
planning, and appropriate work related to these areas will begin in early phases of the
project.
 CU will define and set up the necessary processes and resources for change management,
issue management, risk management and both project and product quality assurance
activities as part of the implementation planning phase.
 System dependencies will be fully understood and documented, and external projects and
initiatives that may affect this project will be monitored throughout the life of this project.
 CU will require an extensive validation of a vendor or product’s ability to meet project
goals and functional requirements, prior to making a vendor selection.
 Service Level Expectations (SLEs) for the new system and environment will be formulated
and published, to clarify the level of service system users should expect from the system,
and from central university support, and to clarify the process users should follow to get
support. Existing Service Level Agreements (SLAs) will be updated to reflect new
expectations.

Page 19 of 91
Principle 2: CU will establish a project governance structure that emphasizes collaboration,

cooperation and participation by faculty, staff, and students; all campuses and system
administration; and executives, functional and technical system users appropriately. This
structure, those appointed to it, and their attendant responsibilities will be made publicly available
on the project website.
 CU will establish the “right” champion(s) to advocate for, and articulate the need for, the
project.
 CU will establish an Executive Steering Committee to provide executive-level support for
the project. This group will be established and cohesive prior to the beginning of detailed
implementation planning.
 Project executives will establish an agreement with the Chancellors and President about the
expected extent of their involvement. Project governance will involve the Board of
Regents appropriately.
 The project budget will include a full-time project director and/or manager, with full-time
project administrative staff as appropriate to handle project communications, management
and tracking, financial tracking and human resources issues.
 The project budget will include funding for each campus to have a full-time project liaison.
In addition, the project budget will support part-time participation by other campus and
departmental experts, so that they may engage in project tasks (testing, configuration
review, process review, documentation and training development, etc.).
 CU will establish a Governance/Stakeholder Advisory Group to represent the strategic
needs and viewpoints of faculty, students and other constituencies including (but not
limited to) Continuing Education, Study Abroad, Extended and Online Studies.
 The SIS Governance Advisory group (SISG+) will be involved throughout the project, and
this group’s membership and charge will be updated to accommodate the expanded reach
of the new system.
 CU will create a separate project staff and backfill their former positions, both in system
administration and on the campuses, to ensure that team members can devote their attention
to the project, and that academic units are not left under-staffed.
 The appropriate IT and technical staff will be included in the project team. This will
include staff who work with technical architecture, authentication/authorization, identity
management, provisioning, web and portal design, and others, as well as application
development staff.

Page 20 of 91
Principle 3: CU will establish a decision-making process that is transparent, clearly documented

and that takes into account the different kinds of decisions (strategic, tactical, operational) and the
scope of effect (system configuration, departmental, university-wide, etc.) these decisions may
have. Decisions will be made by the appropriate groups or individuals.
 The project will establish a Policy Advisory Group and policy management process, to
consider how project policy issues will be integrated into, or managed through existing
University policy.
 In addition to the Policy Advisory Group, the project governance will include the SIS
Governance Advisory Group, and a Governance/Stakeholder Advisory Group to represent
the strategic needs and viewpoints of faculty, students and other constituencies including
(but not limited to) Continuing Education, Study Abroad, Extended and Online Studies.
 The project governance structure will include both project and University executives,
regents and others with authority over project decisions, and their roles will be clearly
defined.
 Campuses and departments will be represented through dedicated Project Liaisons and
through other part-time positions to be defined. These individuals will be apprised of, and
involved in appropriate decisions.
 The decision-making process will explicitly reference the governance structure, so that it is
clear “who makes what decisions.”
 CU will establish a format for documenting decisions, including the original issue,
alternatives explored and costs, those who participated in the process, and the final
decision. These documents will be publicly available both during the project and once the
application is in production.
Principle 4: The project will include full, open and collaborative communication to all university
and other affected constituencies.
 CU will establish communication with faculty, staff and other potentially affected
constituencies in the earliest phases of the project, and maintain this throughout the project.
 The project will involve faculty, staff and student governance groups.
 The project plan will be explicit about the total costs of the project, especially those to be
funded by campuses or units outside of the project budget.
 The project will included a detailed and complete communication plan, identifying the
target audiences, the right messages, the appropriate senders, the communication channels,
and the right timing for communication. This plan will establish communication guidelines
for internal team communications as well as those to executives, and university and other
stakeholders.
 CU will establish and maintain connections between the project team, advisory groups,
campus, academic departments and system offices through organizations such as a
“Liaisons” group.
 The project management team will actively manage expectations for all project participants
and stakeholders throughout the project.
 Project communications will clearly and accurately present what the project (and system)
can and will do, versus what it can’t or won’t do.
Principle 5: CU will make every effort to achieve the best balance between a limited technology
replacement project, and one including business processes improvement.

Page 21 of 91
 This project will take advantage of strategic and tactical opportunities presented by other
technology initiatives and projects at CU.
 When delivered functionality conflicts with existing business processes or needs, CU will
give equal consideration to
1. Process change (revising the business process to meet system requirements),
2. System modification (customizing the system to meet business process
requirements), and
3. A blend of process change and systems modification.
 When considering options for addressing change, each approach will be researched and
documented, and the short- and long-term costs for each will be estimated. Options will be
escalated through formal issue, change and risk management as appropriate, and the final
decision will be publicly documented.

Page 22 of 91
Dependencies
Dependencies are other projects or efforts that will definitely happen, but that are not part of the
scope of this project. They must be considered in the context of the SIS replacement project
because they may offer strategic opportunities, and because their success or failure may
significantly impact this project. They may also compete for resources.
The project management teams for the SIS Replacement project, and each of the projects noted
below must maintain regular communication. Because of this, the governance structure for each
major project might need to include a liaison from the other projects considered to be significant
dependencies.
Significant changes in resource needs, deliverables or timing for any of these projects may need
to be handled through risk management for this SIS project.
Significant External Dependencies

1. The ongoing student and faculty/staff Portal projects at UCB, UCCS and UCDHSC.
2. The UCDHSC and UCCS document management projects.
3. The online grading project.
4. The ongoing Degree Audit evaluation project.
5. The COGNOS (new query and report-writing system) implementation in System
Operations.
6. PeopleSoft Financials and Human Resources system upgrades, as needed over the next
several years.
7. The Identity Management, Authentication and Authorization, and Provisioning Projects

Page 23 of 91
Project Charter Project Structure
Project Structure
The Project Governance model below is for discussion. The final model at CU may be very different from this example.
SIS Replacement Project

Proposed Organizational Model
President’s
Board of
Executive
Regents
Team
Executive
Steering Campus Project Liaisons
Committee
Advisory Groups
Governance/ Project
Policy/Procedure SISG+ Management UCCS
Stakeholder UCB UCDHSC
Advisory Advisory Team
Advisory
Group Group
Group
Project Teams (100% commitment)
Account Admissions Student Academic

Executive Billing and
Manager and Records and Financial Aid Advising and
Receivables
Project Recruitment Registration Degree Audit
Manager
Data
Integration
Vendor and/or Application Technical Warehouse/ Production
and
Consulting Team Development Infrastructure Reporting Support
Consultants Interfaces
Solutions
Self-Service
Training & Security and
PR/Marketing/ Tools for
User Access
Communications Faculty,
Documentation Management
Students, etc.

Page 24 of 91
Executive Steering Committee

The Executive Steering Committee is comprised of Vice Chancellors from each campus and
from appropriate system offices.
Name Title and location
Project Management
The project management team will include CU staff tasked with following project management
best practices, and with project communication and administrative tasks including
documentation and training coordination.
CU Project Manager(s)
Vendor Project Manager(s)
Project Administrative Support
Training Coordinator
Documentation Coordinator
Vendor Account Manager(s)
Advisory Groups
The Advisory Groups provide guidance to the individual project teams, to the Project Director,
and to the Executive Steering Committee. They will be responsible for analyzing project issues,
policy questions and decisions in the broader context of the University environment, and within
State and Federal regulations.

Page 25 of 91
Advisory Groups function throughout the implementation project, and must be transitioned into
an operational mode, once the project is complete. Feature requests, configuration changes,
policy issues and strategic initiatives will continue to arise throughout the life of the product at
CU, and a standing committee or committees should exist to address these needs.
Governance/Stakeholder Advisory Groups

The Governance/Stakeholder Advisory Groups represent the strategic needs and viewpoints of
faculty, students and other constituencies such as Continuing Education, Study Abroad,
Extended Studies, etc.
Policy/Procedure Advisory Group

The Policy/Procedure Advisory Group is comprised of individuals who routinely recommend
and implement University policy, and those who work with State and Federal legislative bodies.
This group should include representation from University Legal Counsel, and University
Lobbyists, among others.
SISG+ Advisory Group

The SISG+ Advisory Group includes current members of the 3-campus SIS Governance group,
selected associate deans and associate vice chancellors from the campuses, and faculty
governance representatives, either from Faculty Council or the campus governance groups.
Campus Project Liaisons

Campus Project Liaisons are fulltime project members from each campus who are responsible
for advocating for their campus’ needs and viewpoints, and providing two-way communication
and feedback between their campus and the project. The project budget should include funding
to support participation from this group, specifically for mileage reimbursement, and to support
teleconferencing and videoconferencing (since they may not always be able to participate in
person).
Project Implementation Team

Advisement Functional Lead – 50% time
Advisement Process Analyst – 100% time
Admissions Functional Lead – 50% time
Admissions Process Analyst – 100% time
Billing and Receivables Functional Lead –
50% time
Billing and Receivables Process Analyst –
100% time
Financial Aid Functional Lead – 50% time
Financial Aid Process Analyst – 100% time
Student Records Functional Lead – 50% time
Student Records Process Analyst – 100% time

Page 26 of 91
Task Teams
Membership to be determined
Task Teams will be created and organized throughout the duration of the implementation
project. Each team will be assigned responsibilities and action items by the
Implementation Team. For example, a Task Team may be organized to test and
prototype the functionality of the student registration in the new ERP. The team(s) will
report their outcomes and findings to the Implementation Team. Please note that these
teams are dynamic. That is, they may be created and dissolved as required to perform
specific tasks during the implementation.
CU Technical Team
Infrastructure Lead
Application Developer
Database Administrator
Network Analyst
Web Administrator
Security Administrator
Vendor Implementation Support

On-Site Management Functional Experts
Account Management
Technical Support

Page 27 of 91
Role Descriptions
Following are descriptions of project roles. Some of these roles may be shared and the
responsibilities assumed by more than one individual. In other cases, a person may assume more
than one role. An important factor in the quality and effectiveness of the project is to ensure that
all of the responsibilities are assigned to the appropriate individual(s).
Executive Sponsor
The Executive Sponsor has the authority to resolve project management issues, assign resources
and to recommend or approve project expenditures, plans and organization. This senior executive
will be the driving force behind the project, and have a unique ability to identify issues that need
to be considered from a university-wide point of view. The Executive Sponsor may also empower
others with some of the responsibilities noted below as appropriate.
Typical Responsibilities
 Defines organizational and reporting relationships.
 If necessary, prioritizes the major elements of the implementation.
 Approves and allocates the necessary resources for the implementation.
 Determines the ability of the organization to support planned changes in terms of financial
and other resources, i.e., backfill positions, hardware, training, etc.
 Responsible for assessing the institutional impact of issues and determines the ability of
the organization to supplement or reinforce business unit strengths.
 Provides tie-breaking vote in the event that a management group is unable to reach
closure on its own or when business decisions have implications beyond functional
jurisdiction.
 Approves and accepts all project related contracts and deliverables.
Executive Steering Committee

The Executive Steering Committee is comprised of senior executives and principal stakeholders
who are committed to the project and have the authority to make policy decisions that have
departmental and institutional-wide impacts.
This committee also provides input to the Executive Sponsor on project issues escalated by the
Project Manager. Typically, an issue is presented to the Steering Committee when the issue
impacts the project budget, timeline or institutional policies. Issues impacting more than one
department or organizational unit may also be presented to the Steering Committee for resolution.
 Provides advice and input to the Executive Sponsor
 Sets direction and defines organizational goals.
 Defines project ownership
 Resolves conflicts (e.g. resource, requirements conflicts).
 Monitors the status and progress of the implementation.

Page 28 of 91
 Provides feedback to the Project Manager and Implementation Team.

 Communicates with other groups to champion ongoing project support and sponsorship.
 Gains approval and acceptance on key decisions.
 Maintains a basic understanding of the system.
Project Manager
The Project Manager is responsible for project coordination and communication while staying
within the parameters of the budget and timetable. The Project Manager is responsible for
managing University activities on the project. This individual is the primary point of contact for
project team members (staff and consultants) and is responsible for resolving internal issues
within the agreed-upon timeframes.
The Project Manager will manage the activities of all consultants including those provided by
subcontracted vendors; will ensure coordination between this and other projects at CU; and will
provide overall project guidance.
The Project Manager will manage the activities of all CU staff, both technical and functional,
and work with line managers to ensure appropriate participation in the project.
 Manages the implementation project, including but not limited to the following:
o Develops and maintain the project plan
o Monitors the status and progress of the project, and the quality of deliverables.
o Identifies and manages project risks.
o Monitors project scope and expectations.
o Provides project direction, organization, resource alignment, and allocation.
o Reviews and approves deliverables.
o Ensures consistency of activities and deliverables across teams.
o Manages project priorities.
o Monitors project schedule and milestones.
o Identifies resource needs.
 Leads the Implementation and Task Teams. This includes coordinating and/or
facilitating team meetings and communication between all teams and the University
community.
Vendor Lead
The Vendor Lead is responsible for following the Vendor implementation methodology and for
completing project deliverables in accordance with the contract provisions and the Project
Charter document. The Vendor Lead works closely with the Project Manager to communicate
project progress, identify and resolve key issues, and carefully manage the scope of the project.
 Supervises Vendor team.
 Assists with developing and maintaining the project plan.

Page 29 of 91
 Monitors project progress.

 Reports on project status to University and Vendor management.
 Follows project controls that ensure the quality of project deliverables and minimize
disruption to the project schedule.
 Provides application knowledge and expertise to the client and to the Project Team.
 Ensures that the client accepts all deliverables and that the appropriate sign-offs are
obtained.
Vendor Account Manager

The Vendor Account Manager provides leadership and quality assurance for the project, and
functions as the primary Vendor contact for accounting issues. The Account Manager works
closely with the Project Manager and Vendor Lead to ensure that the project deliverables are
completed and accepted in accordance with contract provisions and the Project Charter
document.
 Evaluates the integrity of the project scope.
 Performs periodic quality assessments.
 Provides assistance with issue resolution.
 Assists Vendor Lead with managing the staffing and scheduling of Vendor personnel.
 Resolves billing and contract issues.
Vendor Functional Implementation Experts

The primary role of the Vendor functional expert is to provide expertise in the application,
industry-specific areas and module-specific functions and business processes.
 Works with CU team members to best ensure knowledge transfer.
 Assists in resolving gaps, whenever possible, by recommending work-arounds, process
improvements, customizations, or modifications.
 Provides leadership and support with setting up system tables.
 Provides leadership and support with testing the system during modeling and system
acceptance to ensure that CU requirements are met.
 Assists with data identification for conversion activities.
 Reports on project status, progress, and issues to the appropriate team lead in a timely
manner.
 Transfers knowledge to appropriate CU personnel.
 Provides functional guidance to the Project Team.
 Provides options for issue resolution and identifies business process improvement
opportunities.

Page 30 of 91
Functional Leads
The functional team lead serves as the primary contact for a particular functional area, and
typically devotes approximately 50% of his or her work day over the course of the
implementation to project activities. The team lead works closely with the functional Vendor
expert and will lead the implementation of the respective module(s). The team lead will be
responsible for coordinating meetings, managing and resolving team issues, reporting progress to
the project management team as well as serving as liaison between the Project Team and
departmental management.
 Assists in the planning of the implementation project.
 Assists in the administration of the implementation project schedule/timeline.
 Reviews definition and documentation of the business processes, policies and procedures
relating to the ERP system.
 Reviews implementation requirements.
 Reviews functional specifications and test scripts for a given area of expertise.
 Collaborates with other Implementation Team members.
 Attends and participates in the implementation meetings.
 Leads his or her assigned Task Team(s).
 Responsible for achieving team milestones.
 Coordinates end-user training with their respective department’s staff.
 Reports progress of team to project management.
 Coordinates and facilitates team meetings.
 Manages identification and resolution of team issues.
 Reviews and approves team deliverables.
 Assures that deliverables meet the business and/or technical requirements.
 Acts as a project “ambassador” to other University constituencies.
Functional/Technical Process Analyst

These individuals perform as project team members and as subject matter experts and will devote
100% of their workday over the course of the implementation to the project. These individuals
will become the system experts, through direct, day-to-day knowledge transfer from consultants,
and through hands-on use of the application through all phases of the implementation.
 Provides knowledge of end user needs.
 Provides knowledge of business processes and procedures.
 Attends and participates in the implementation meetings.
 Proposes implementation requirements.
 Develops functional specifications and test scripts for a given area of expertise.
 Leads the definition and documentation of the business processes, policies and
procedures relating to the use of the system for a given area of expertise.

Page 31 of 91
 Ensures that the necessary testing, prototyping and piloting tasks are completed,
according to the agreed upon timelines and deadlines, and that related documentation is
complete and accurate.
 Provides communication of business needs and gaps to team leads.
 Examines business processes for improvement opportunities.
 Aids in and carry out testing.
 Assists with data conversion/interfaces.
 Assists in training.
 Aids in report definition.
 Assists in building and reviewing prototypes.
Infrastructure Lead
Responsible for the planning, design, and implementation of the infrastructure required to
support the applications.
 Develops and implements strategy for networks, database support and operating systems.
 Secures necessary hardware and software to support implementation.
 Responsible for the allocation of technical resources during the project, including hiring
additional staff if necessary.
 Works with Project Manager to develop training plan for technical staff.
Database Administrator
Ensures data base integrity and that data is available for retrieval.
Typical Responsibilities include:

 Sets up databases as needed by the Project Team.
 Develops and implements database backup and recovery procedures.
 Monitors and tunes the performance of databases, as needed.
 Reports status, progress, and issues to team leads in a timely manner.
 Coordinates conversion activities.
 Maintains database security.
 Performs database capacity analysis.
 Responsible for monitoring version control between database instances.
System Administration (post-implementation responsibilities)

System Administration is the on-going maintenance and successful utilization of the system
during the useful life of the production system. Systems administration activities must become
operational during the implementation of the system in order to take control of the system
immediately upon implementation. Within the University environment, these responsibilities
may be assigned to a variety of individuals. The following post-implementation responsibilities
must be assigned to the appropriate University staff prior to implementation.

Page 32 of 91
 Provides system help and education to the system users.
 Maintains security administration for the system.
 Conducts database administration support activities.
 Tests all enhancements, patches and fixes to the system.
 Acts as liaison to management concerning the system.
 Maintains the hardware that supports the system.
 Ensures that the system is current (as far as is practical and functionally necessary) with
patches and fixes to the system.
 Plans for the future evolution of the system to meet changing/expanding business
requirements in functionality.
 Ensures adequate system documentation.
 Maintains vendor contract awareness and compliance.
Training Coordinator/Documentation Specialist

This individual is responsible for the coordination of training activities and the development of
training materials and documentation.
 Coordinates the scheduling and setup of training facilities.
 Develops and maintains training materials.
 Develops, customizes and maintains end user documentation.
 Executes the Training Plan for the project.
 Maintains attendance records and evaluation forms.
Communication Specialist
All project communication initiatives will be coordinated by this person to ensure that
information is disseminated in an accurate and a timely manner.
 Executes and maintains the Communication Plan for the project.
 Updates meeting minutes and task status reports.
Administrative Support
Administrative support personnel provide assistance with the preparation of project documents,
meetings, and communications.
 Maintains calendars.
 Maintains project document library and files.

Page 33 of 91
Project Charter Operating Agreement
Project Operating Agreement

The project principles and governance model stated above provide a framework in which project
activities can be more clearly defined, understood and assigned to the appropriate groups and
individuals. Beginning with this section of the charter, the document will provide more detailed
suggestions for daily operating, management and control tactics leading to smooth project
execution.
The project operating agreement suggests a detailed approach to daily project team operations,
specifically addressing decision making, confidentiality, team operations and team
accountability.
Decision Making Agreement

Any large project will require hundreds or thousands of decisions over the course of its lifetime.
Decisions can be broadly grouped into three categories as noted below. Some decisions will
require escalation through the issue, change, policy or scope management processes, and others
simply need to be made, documented and acted on. But the process of decision-making should
be transparent to those involved, and documented so that everyone understands it.
Types of Decisions
Strategic Decisions
 Affect, or are affected by, project vision, direction or objectives
 Affect, or are affected by, project culture
 May have an impact on the institution
 Must be escalated through issue, policy, scope and/or change management
 Affect, or are affected by, external engagement and alliances
Tactical Decisions
 Determine how to resource appropriately to accomplish a work task
 Determine how a strategy will be fulfilled
Operational Decisions
 Determine the detailed steps to accomplish tasks or new processes
 Affect team operations (rather than project deliverables specifically)
 Affect content
Approach to Decision Making

Majority Rule
In a minority/majority voting decision, the majority will be defined as containing over 50% of
the total vote.
Every decision will be treated equally and documented consistently, whether the decision is a
recommendation to other members of the team, or one affecting one individual’s work output.

Page 34 of 91
Being Decisive
An implementation project of the scope and complexity of the CU SIS Replacement project must
follow a tightly managed schedule in order to succeed. Because of this, once a decision is made,
it can’t be revisited without potentially affecting the project schedule. Therefore, the project will
generally follow the rule “Once a decision is made, it is made.” Where subsequent events
make it clear that the wrong decision was reached, the issue will be escalated through the Issue
Management process as appropriate.
As noted in the Project Governance Structure above, decisions that impact quality, cost, scope or
resources will be made by the Executive Sponsor.
Consensus
Ideally, the team will achieve not only agreement, but consensus (or 100% agreement) on all
decisions.
Documenting Decisions
All project decisions should be appropriately and consistently documented, according to their
type and scope. For example, basic system configuration decisions should all be documented
during the implementation project’s configuration phase, and all subsequent changes in
configuration should update the same documents. This can be done in a variety of formats
(Word, Excel, within the system’s help or meta-data tool if appropriate), but it should be done
consistently. The tool and format used to document these decisions must support easy search
and retrieval for both the appropriate team members and end users, and should remain available
after the system is in production. It is frequently important for end-users to be able to
understand why a configuration choice was made, even years later, as the configuration adapts to
changing institutional needs.
Tactical decisions should be documented in the project workbook. This contains the detailed
project plan and management materials for the project, and should be accessible to the entire
project team.
Strategic decisions should also be documented in the project workbook, and many of them
should be briefly summarized in public forums such as the project website.
The documentation for each decision should include at least the following:
 Background discussion, if appropriate.
 Options considered, and their costs, benefits, and risks. This may not apply for some
configuration choices, but all Strategic decisions should include complete documentation
of these points.
 Which choice was made.
 Who (individual or team) made the decision and when.
 If appropriate, how the decision was communicated, and when.
Communicating Decisions
Operational decisions should be communicated within a project team, and to those directly
affected by the decision. Operational decisions that will “live with the system” over its lifetime

Page 35 of 91
must be documented in a way that allows them to be accessible even after the system is in
production. In this case, the communication might occur through custom help text.
Tactical decisions must be communicated across all project teams, and as appropriate, to external
projects or operational units that may be affected by the decision. Tactical decisions that may
impact scope, cost, quality or schedule must be escalated through the appropriate process.
Strategic decisions must be communicated both vertically through the entire project governance
structure, and horizontally across all project teams. Almost all strategic decisions should be
communicated to the project stakeholders, and some should be communicated to external
constituencies such as the legislature.
Decisions for the Executive Sponsor

All decisions requiring a “Major Change” in direction will be made by the Executive Sponsor.
These include (but may not be limited to) decisions affecting:
 Cost
 Scope
 Quality of the product
 Schedule
 Business Case
 Project Goals
All decisions will use the Trust Factor. Trust the experts: the Project Teams and Advisory
Groups.
It is important to communicate Strategic Issues to the entire team, since these may have an effect
beyond one module or area.
Decisions for the Project Manager

The following types of decisions will be made by the Project Manager:
 Chartering of task teams.
 Operational issues.
 Changes in Work Plan.
 Internal and external resource allocation issues.
 Budget issues.
 Information to share with Steering Committee and other constituencies.
 Cross-team tactical decisions.
 Change management.
 Issues to be brought to the Steering Committee.
 Information to be shared from Steering Committee meetings.
 Recruitment matters.
 Performance Appraisal issues.
 External Communication Strategy.

Page 36 of 91
Decisions for the Project Teams

The following decisions will be made by project teams, which include functional leads, process
analysts, consultants and others as needed.
 Operational Decisions – Details of work steps for new processes.
 Identifying tactical and strategic issues to bring to the full team.
 Identifying gaps to be filled by product modification or business process change, and
suggesting solutions or resolutions.
 Escalating all business process and policy/procedure changes through the appropriate
project hierarchy.
Achieving Team Decisions

 Get the information needed to address issues.
 Come prepared to explain, ask questions, discuss and understand. Don’t abdicate
responsibility for team decisions to others.
 Exercise collaboration rather than cooperation – don’t just “go along with” a decision.
 When decision is reached, members “own” the decision.
 “Complete” agreement is a commitment to how a decision was made; understanding it
and committing to the result.
When disagreements occur, team members should:

 Seek to understand.
 Look at the facts.
 Listen and be flexible.
 Present and seek alternatives.
 Call on external sources for information or help.
 Not personalize the discussion, but focus on results.
 NOT stop until issues are resolved.
Confidentiality Agreement
This project is dedicated to open, broad and transparent communication of decisions and issues.
However a project team also requires a “safe” environment in which to discuss issues and
conduct business. The following guidelines will foster better team dynamics:
 There should be no personal attribution of issues outside the team.

 It is acceptable to talk about collaboration and the overall process.
 Interpersonal differences between individuals are confidential to those involved.
 Team dynamics are confidential.

Page 37 of 91
Team Operations
 The project team will celebrate project milestones.
 A single tool will be used for project reporting.
 Full team meetings will be regularly scheduled to
o Check in and check status,
o Report out from task teams to the full team,
o Foster collaborative working,
o Provide the Big Picture.
 Full team meetings for decision-making may be scheduled on an ad-hoc basis, however:
o The agenda should be published at least 24 hours in advance,
o Whoever raised the issue takes responsibility for the agenda.
Meeting Attendance
The team will strive for full participation to ensure full team consensus.
 Ideally, this means that everyone is in the room.
 Those who can’t attend in person should try to join the meeting by video conference or
teleconference, and facilities will be provided to support this. Alternatively, those who
can’t attend in person can brief another team member to act on their behalf.
 Anyone who can’t attend a meeting should be prepared to accept the decisions reached
during the meeting.
Core Hours
 The project director will define project Core Hours, during which team members should
expect to be available, if needed.
 General meetings will be held during core hours.
Weekends
 There will be no regular work on weekends.
 Team members will only be asked to work weekends if it is essential.
Communications
 Other than meetings, e-mail will be the preferred tool for formal communications.
 Team members agree to check email and electronic calendars daily when working.
 Sub-team and team meetings
o Team meeting agendas will be emailed.
o Notification of emergency meetings will be through email.
o Cancellations will be through email.
 Weekly progress reports will be maintained centrally.
 The work plan will be kept in a location accessible to the entire team.
 Information is available to anyone who wants it.
 Issue logs will be kept by each team, and available to anyone interested.

Page 38 of 91
Balancing Work and Personal Time

All Team members should:
 Feel free to work more or less than others as long as goals and objectives are met.
 Be allowed to manage their work load and personal time.
 Take each other’s obligations into account.
 Absolutely honor each commitment made.
 Understand that fun at work is acceptable and desirable.
 Understand that work should not be your whole life: family life is important; your time is
important.
 Let each other know about commitments when they might affect project work.
 Honor people’s time - start and end meetings on time.
 Balance their own time.
 Feel free to say, ‘I need private time’
 Make core hours available to each other.
Team Conflict
Team Members should:
 Be open and explicit about issues that are happening.
 Deal directly and honestly with others.
 Deal with small things to avoid major conflicts.
 Clearly identify the conflict.
 Explore solutions, provide and accept feedback gracefully.
 Agree to sort it out or to table it with a way to deal with it.
 Forgive and move ahead.
 Escalate to Project Management if needed (or to the Executive Steering Committee if the
conflict is with Project Management).
 Notify Project Management of any conflict outside the team.
Workplan Accountability
 The Workplan will be updated regularly.
 Team members will report actual hours worked each week to project management, using
the task numbers from the Workplan.
 Team members should not commit to something they cannot deliver as specified.
 Anyone may bring up questions about the work plan and deliverables without fear of
blame and attack
 The entire team is accountable for mutual success.
 If someone is not delivering because of a performance issue, deal with it first in teams,
and escalate to Project Management if that isn’t working.

Page 39 of 91
Project Charter Project Management Strategies
Project Management Strategies

Vendor Selection
There are several steps involved in a vendor selection strategy, summarized below:
1. Establish a vendor selection committee.
2. Develop detailed functional, technical, budgetary and other institutional
requirements.
3. Define scoring based on institutional requirements.
4. Request and evaluate vendor responses (this may be an iterative process).
5. Refine the project budget, resource plan and implementation plan.
6. Secure approval to proceed with contract negotiation.
7. Select a vendor and negotiate a contract.
Vendor Selection Committee

The first task in vendor selection is to determine who will serve on the vendor selection
committee. Members of this group must be able to represent all of CU’s various
stakeholders, and must be able to devote enough time to the process to be able to help
develop requirements and the vendor scoring model, and evaluate all vendor responses
and demonstrations. The vendor selection committee is typically comprised of people
who have had, or will have significant involvement in the on-going project.
Detailed Requirements and Scoring

CU has begun to define key drivers for any SIS replacement system during the project
definition phase. During the next phase, these drivers need to be translated into a scoring
model by which candidate systems can be evaluated. The scoring model must be
completed before vendor selection begins.
Scoring will be based on how well a given application maps to CU’s needs. The first step
in creating scoring is to develop detailed requirements. Many of these requirements have
already been identified and documented
 as a result of the earlier project to extend SIS,
 in the document provided by SCT that compares IDMS to features available in the
current release,
 through participation in previous vendor demonstrations,
 and through the project definition interviews.
However these need to be brought together into one list, reviewed and refined. Also, the
requirements will be divided into different major categories. This helps to identify which
individuals should be involved in refining requirements and evaluating responses, and
also to establish the “weight” each requirement might have in the overall score.

Page 40 of 91
The graph below contains sample categories CU might use. These include:
1. Total Cost of Ownership: What will it cost CU to purchase the licenses, hardware
and resources needed to implement and maintain a system over a period of years?
2. Vendor Vision: How well does the vendor’s vision for the future strategic
direction of their company and this product map to CU’s future vision of needs in
this area?
3. Vendor Support: What support does the vendor provide in terms of regular
updates, response to customization requests and the larger user community? How
well is vendor support perceived by other users?
4. Technical Architecture: Is the application based on technology that is robust,
proven, flexible and likely to be mainstream for at least the next 10 to 20 years?
How many current users of this technology exist?
5. Functionality: Is the system configurable, flexible, and usable? How easy is it to
integrate with other systems? How easy is it to extend system functionality
without significant vendor input? How easily will CU be able to tailor the
individual user experience with regard to usability, reporting, interfacing,
documentation and training?
Although this is a sample graph, system functionality and total cost are visually
represented as having greater weight in the selection than vendor vision or vendor
support, because it is already clear that these areas are most critical to CU.
Total Cost of
Ownership
Vendor
Vision
Technical
Architecture
Vendor
Support
Functionality
3
This graph is intended as an example only. The composition of a “perfect 100%” score will be
determined by CU during phase 2.

Page 41 of 91
Request and Evaluate Vendor Responses

There are several possible vendor response approaches CU can take. For examples of
specific methods, see appendix 6.
Response Method Sample Advantages Sample Disadvantages

Request For Proposal 1. Standard approach that 1. Vendors may “spin”
(RFP) institutions and vendors their answers, resulting
are used to. in surprises later.
2. Provides an objective 2. Systems are evaluated
comparison of multiple on paper – there is no
systems. hands-on experience.
3. RFP scoring and 3. The formal RFP
weighting are familiar process is a “black
concepts for most box” process that may
institutions. force certain choices.
Scripted demonstration 1. Can clarify specific, 1. It’s not practical to do
using requirements critical functions. this for every
2. Vendor must requirement, so some
demonstrate requested functions have to be
functions (these can’t taken on faith.
be hidden or finessed). 2. Scripted demo tends to
3. End users can see the concentrate on specific
system perform the tasks, so some
functions they are integration and
concerned with. navigation elements
may not be obvious.
3. No hands-on
experience.
4. Scoring and weighting
can be harder to define.
5. Vendors may want to
limit their time
investment in this.

Page 42 of 91
Major Use Case 1. Use Cases attempt to 1. Use Cases are time-
identification for vendor address the big picture, consuming to develop,
demonstration the details and different and can’t be done for
user viewpoints. every function.
Integration and flow is 2. Use Cases are used
more obvious. more for software
2. Vendor must development – vendor
demonstrate requested demo teams may need
functions (these can’t to be educated to
be hidden or finessed). respond properly.
3. End users can see the 3. No hands-on
system perform the use experience.
cases they are 4. Scoring and weighting
concerned with. can be harder to define.
5. Vendors may want to
limit their time
investment in this.
Complete Fit-Gap with 1. No surprises – CU 1. Expensive (in cost and
multiple products would have a very good person resources) and
idea of the project time-consuming.
scope, Fits and Gaps 2. Project team has to be
and their recommended in place for Fit/Gaps.
solutions, and likely 3. CU would need to
schedule. move to the
2. Users can get some implementation phase
hands-on experience quickly, or risk having
with the product. an idle project team.
3. CU would have a better 4. There is some
understanding and duplication of effort in
documentation of reviewing two (or
current processes, prior more) systems.
to beginning 5. Potential logistical and
implementation. licensing issues.
4. Scoring and weighting
would be replaced by
documented system fit,
and fairly detailed and
informed estimates of
project cost and effort.
5. Project Team would get
early training and
knowledge transfer.

Page 43 of 91
In order to maximize CU’s confidence in the accuracy of estimated project costs

(financial and other), and the ability of a candidate vendor’s system to meet CU’s needs
while limiting CU’s financial exposure, CU may follow this blended vendor selection
strategy:
Vendor Evaluation
First Round
1. Prepare and issue a “limited response” RFI, limiting responses to no more than 10
pages. Ask for specific higher education, multi-campus SIS implementation
experience. The goal is to formally narrow the field to only those vendors whose
products can support an institution of the size and complexity of CU.
2. The Vendor Selection Committee reviews and scores all responses.
3. An Independent Verification and Validation (IV&V) vendor reviews the process and
results.
4. Publish results internally.
5. Identify possible vendor system weaknesses through discussion with peers, vendor
user groups and implementation or consulting partners.
6. Develop scripted demonstration or Use Case examples for critical application
functions or areas; those that are potentially weak in the candidate systems; and those
where CU is known to have unique or heavily customized processes.
Second Round
1. Vendors provide costing information.
2. Vendors perform onsite scripted demonstrations and/or Use Cases, as previously
defined by CU staff.
3. The Vendor Selection Committee reviews and scores second round vendors.
4. The IV&V vendor reviews the process and results.
5. Publish the first and second choice vendors internally.
6. CU will negotiate a contract for Fit Gap Analysis only, with the first choice vendor.
Fit Gap Analysis

1. Secure funding for fit gap analysis from appropriate committees.
2. Perform Fit Gap Analysis.
3. Decision: If the results of the Fit Gap are acceptable, CU will refine the project cost
and schedule estimates, and secure approval for contract negotiation. Otherwise, CU
will secure funding to perform a Fit Gap Analysis with the second choice vendor.
4. The IV&V vendor reviews the process and results.
5. Publish the results internally.

Page 44 of 91
Project Planning
A project the size and complexity of CU’s SIS Replacement project will be managed
through the Strategies and Controls initially outlined in the Project Charter, and through a
Project Work Breakdown Structure (WBS). These will be documented in the Project
Workbook, which should have major sections corresponding with the sections of the
Project Charter.
The Project Plan depends heavily on the Project Charter, a governing framework defining
the approach and established boundaries for the project. The Project Charter provides
written documentation of the high-level project objectives, strategies and controls, as well
as high-level project scope. It is also the first opportunity for the entire institution to
define, understand and agree to the project. Using this document, the project Work
Breakdown Structure (WBS) is created to plan the detailed tasks necessary to address the
completion of each deliverable.
The project WBS clearly defines the phases, resource requirements, detailed tasks,
deliverables and the target start and end dates for each phase and the overall project. The
project plan tasks are specified at a level of detail necessary to reflect task accountability
by resource. The plan also organizes the effort to achieve the ultimate deployment
following the defined implementation strategy.
The project WBS is a dynamic document and as the implementation progresses, it must
be updated to reflect the impact of business decisions and redesign, scope changes, and
risk mitigation activities. Additional detail will be added as Project Teams develop more
detailed plans. The Project Manager and Team Leads will update the project plan on a
weekly basis to reflect work accomplished and the current project status. Tasks behind
schedule will then be addressed by the Project Team and, if necessary, the Executive
Steering Committee.
Testing
Testing must be an on-going activity throughout all phases of a project and should be an
integral component of quality assurance efforts. A complete testing strategy can not be
developed until after vendor selection, so this section contains suggestions for possible
activities that could be included in a testing strategy, and a general description of the types
of testing CU should consider. A complete testing strategy and plan must be developed
once the project reaches the implementation planning phase. The Project Workbook should
be updated by the Project Director to include the Test Plan, once it is finalized.
Testing starts at the unit level, as team members test portions of the functionality
encompassed within a single module, interface, report or modification. Data modeling is
used to test delivered functionality. Customizations, interfaces and reports are first tested
by their developer before they are submitted for testing by functional users. Functional
users will conduct a unit test of the customization, report or interface and formally accept
it before it is moved to production.

Page 45 of 91
As the implementation of the project progresses, so does the nature of testing. After each
module has been thoroughly unit tested, integration testing begins. As integration testing
proceeds, more end-user participation is needed. CIBER recommends that there be one
person (a central point of contact or testing coordinator) responsible for tracking the status
of test scripts and the documented results of each test. Any test scripts which identify
errors should be tracked and given to the appropriate person to resolve. After the error has
been resolved, it should be re-tested by the same individual who originally uncovered the
error.
The next step in the testing cycle is to carry out system testing, to validate that the entire
system performs as expected. Given concerns voiced by members of the user community
over an “all or nothing” cutover, CU may choose to perform a modified parallel test. In
this scenario test scripts are created using two to four weeks of live data from a previous
month. The output from the scripts (including process, interface and reporting outputs) is
compared to the output from the legacy system. Unexpected discrepancies will be
analyzed, resolved, and re-tested. This cycle is repeated until the team (and the user
community) is confident that the new system is ready for production.
Each module Project Team should develop detailed test plans and acceptance criteria.
These plans will be integrated and coordinated for the testing of inter-module processes.
The plan should also identify one or more Testing Coordinators.
Test Scenarios
A test scenario documents the scope of a testing effort. It identifies the portion of the
system being tested, which major functions or areas are to be tested, the approach to be
used, the resources assigned, and the expected outcome of the testing. One or more test
cases will be defined to accomplish the defined test scenario.
Test Cases
A test case describes the data and the process steps required to test a portion of the system
for correctness, in support of a test scenario. A test case defines the specific functions to
be tested, any base data that must be present prior to testing, data that will be input during
the test, the process steps to be performed to accomplish the test, and the expected outcome
from the test in the form of expected data results and deliverables. Test cases should be
established for both functional and technical testing.
Test cases are also referred to as test scripts. As these test scripts are completed they serve
as a good foundation for documentation and training.
Test cases should be designed to be reusable - individual test cases should be used as a
component of later business process and integration testing, and should use the same
general format as training and documentation materials.
Functional Testing
Functional tests allow the institution to validate the utility and accuracy of end-user
processes. To accomplish functional tests, users run through a process from end to end.

Page 46 of 91
For example, the user looks up data, enters new data, executes system processes (interfaces
or batch updates), generates output (reports or queries), and verifies the results of the test.
Technical Testing
A technical expert defines a technical test to ensure that the system operates correctly from
a technical and performance standpoint. This involves the technical specialist verifying
that the system operates correctly, that interfaces are correctly developed, that data loads
correctly, that control tables are loaded, and that any system fixes are applied and operate
correctly. Technical testing should also include load testing to ensure that system
performance (including network, server and client architecture) meets expectations.
Unit Testing
This is a test with a narrow scope, relating to the test of a single module, a conversion
process, an interface, a report or query, or any other single component of the system. This
test can be both a technical test and/or a functional test, with the task owner taking
responsibility for configuration and base documentation.
Integration Testing
An integration test verifies the correctness of several system components working together.
An ERP system implementation typically includes integration testing and acceptance
1. at the time the delivered system is installed and configured with basic institutional data,
2. after any customizations and custom interfaces or processes are developed,
3. and as part of test conversions prior to deployment, to ensure that the system works
properly with all customizations and legacy data in place.
This test includes both technical and functional testing, validating the ability of the system
components to “talk” to each other and pass data correctly. Each iteration of integration
testing fosters user ownership and knowledge transfer.
Planning for intermediate sign-off points also ensures that errors are caught and corrected
at the right time. For example, performing an integration test immediately after basic
installation and configuration identifies errors in configuration or system bugs. Correcting
these early allows later integration testing to focus on errors in customization or data
conversion.
System Testing
The system test validates that all aspects of the system are functional. This will require
both functional and technical testing, and should also include a system stress or load test.
The stress test will assess the ability of the system to handle expected production-size
volumes.
Security Testing
Security testing validates that each type of user profile provides access to the correct
areas of the application, and that data inquiry and update controls behave as expected.
Security testing should include validating a user’s access to the online application, and

Page 47 of 91
any relevant batch or reporting processes the user should be able to execute. The security
test must also validate that technical and project team members have appropriate access
to development environments, but that both data and processes in the eventual production
environment are properly secured. As such, the security test should be specifically
defined within the context of the database environment.
Date Testing
Date testing is designed to test the system’s response to data-sensitive transactions. For
example, a student is dropped from a class both before and after the drop deadline to ensure
that the system behaves as expected. Date testing is performed by directly manipulating
the system date forward and backward during testing.
Acceptance Testing
The main function of Acceptance Testing is to validate that a given module or function
meets end-user expectations, and that no further development or correction is required.
User acceptance tasks should be included as milestones in the project WBS, and serve
several important functions:
1. Acceptance validates that the work in a given area is 100% complete, and will not
be revisited,
2. Acceptance gives end users a chance to interact with, approve and begin to “own”
a function or area,
3. Any re-work discovered after acceptance constitutes a scope change, and must be
handled through the issue and change control processes.
Acceptance testing should be performed at the completion of each major (i.e.: requiring
many days effort to complete) functional module, customization, interface or report. The
acceptance test is not necessary for low-effort tasks, but in any situation where re-work
would cause significant project schedule, resource or budget disruption, or where
dependent processes would be significantly impacted, the acceptance test is a necessary
quality assurance step.
The final acceptance test is the testing of the full system after it has been placed into a
“non-live” production environment. This test can include performing the same tests used
during the system test, and may include a mini parallel test with data loaded into both the
new and legacy system so that results can be cross-checked and validated. Upon user
satisfaction with the final acceptance testing, the new system goes into production.
Training
In order to provide the greatest benefit to users, gain the greatest return on investment in
a new system, and to be able to operate it effectively without consulting support, it is
critical to provide thorough and effective training. Project Team members must become
experts in the operation of the software, and end users must become self-sufficient in its
use. Executives should have enough knowledge of the system to understand its
capabilities and its requirements for operations and on-going maintenance.

Page 48 of 91
Training for Project Team members should not be restricted to the formal sessions
outlined below, but will also naturally occur as a result of active participation in the
implementation effort. Training and documentation both evolve over the course of the
project, and will continue to do so once CU is in production. Timely and active
involvement in both formal and informal experiences will position CU not only for a
successful and cost-effective implementation, but will allow for effective post-production
support without the continuing cost of consulting support.
CU’s training strategy will be further defined during implementation planning, and
should include the following components.
Project Team Training

CU team members directly involved with the implementation project activities, both
functional and technical, must attend the standard vendor application and technical
training applicable to their specific application.
Knowledge Transfer
CU project team members will participate fully in the project, from the Fit/Gap phase
through configuration, system testing and deployment. Knowledge transfer happens
naturally when project team members work with their functional and technical consulting
counterparts on a daily and weekly basis. It is this “informal” training as much or more
than any formal training that enables team members to become expert in the
configuration and use of the application. CU has committed to backfill key positions if
necessary, to ensure that team members are able to participate in this manner.
End User Training

For small groups, training may take place one-on-one within an office environment. For
larger groups CU will need to establish a training environment that will accommodate 10
to 12 users.
During Project Definition interviews, several attendees commented that this project could
not adopt a “one size fits all” approach to training, and identified some specific types of
possible end-user training:
 Basic application navigation.
 Training tailored to a specific job or business process: “Tell me what I need to
know to do my job.”
 Focused training that explains how to perform a single function, for infrequent
users who just need to know how to perform one task.
 Detailed training that includes an explanation of configuration choices for some
back-office or expert users who need to understand the process, its inputs and
outputs, and the reason for the process.
 Training in how to run reports, as well as how to create reports.
 Training to explain new features or functions that users may not be aware of.

Page 49 of 91
Mixed Delivery
Most vendors offer a mix of training delivery options including classes at remote
locations, onsite training, computer-based and self-paced training. These are designed to
maximize training while minimizing staff absence and controlling costs. In addition,
most ERP application vendors offer a training “kit” that the client can purchase and
customize to reflect institutional business practices and terms.
Dedicated Training and Documentation Staff

As noted elsewhere, system test scripts, and business process documentation can serve as
a good foundation for end-user Training Guides, however dedicated staff are required to
create and adapt these materials. It is important for CU to designate Training and
Documentation Coordinators to manage these processes, and to ensure that these
functions are supported throughout the implementation and into Production.
Support for Training in Production

It is unfortunately quite common for system training to be provided only in the context of
an implementation. Once a system is in production, most institutions abandon training as
too expensive. However the need for ongoing training was consistently and repeatedly
identified in each of the Project Definition interviews conducted for this project.
CIBER strongly recommends that project funding and planning include a plan, and the
resources to achieve ongoing training once the system is in production.

Page 50 of 91
Documentation
Documentation is critical to support end-users, to manage change to the system
throughout its lifetime, and to ensure consistent and appropriate use of the system.
Current and accurate documentation facilitates training, and reduces the cost of system
corrections and modifications. The documentation effort will be an integral part of the
project, and must be conducted throughout the course of the project, not just at the end.
The development of documentation for the system is the responsibility of project team
members, with the help of a Documentation Coordinator. This is the only way to ensure
that the documentation will meet CU’s needs. Vendor or consulting firms can also
provide guidance and support, and can provide samples and templates of end-user
documentation and customization specifications. As noted elsewhere, vendor training
and documentation “kits” may also aid in creating, maintaining and providing access to
documentation.
In order to be effective, delivered vendor system documentation must be supplemented

with documentation of all customizations and custom institutional processes or terms.
All documentation for customizations should be kept in the Project Workbook, and
summaries should be incorporated into end-user manuals or online help. Customization
documentation will include bridges and interfaces to and from the system, all reports,
queries, and logic designed and built to extend the delivered system, all procedures
needed to operate the system, and terminology used in conjunction with the system.
Documentation falls into the following categories:
User Documentation
User documentation consists of detailed descriptions of how to utilize the completed
system. This includes business processes, desk procedures to be used in concert with the
on-line system, and run procedures for any batch runs. It should also include definitions
where CU terminology is different than that used within the vendor’s system
documentation. User documentation should be process based, offering “how to”
guidance as staff perform their daily activities.
CU may elect to define two or more levels of user documentation, one for typical users
and another for “power users” who have additional system responsibilities such as table
maintenance, troubleshooting, etc. This would consist of the basic user’s manual plus
documentation of the additional functionality.
User documentation is not static. To be of value, it must be updated as system

functionality changes or new procedures are implemented. Documentation planning
should include the designation of staff responsible for on-going documentation
maintenance through out the life of the system. CIBER recommends that documentation
be located in a centralized, on-line location with easy user access. This will eliminate
excessive paper consumption and allow updates to be done in one place without
distribution concerns.

Page 51 of 91
Setup and System Documentation

Setup documentation describes the various table setups in the system. This
documentation will contain the rationale for table setup choices, as well as listings of
table contents. Table definition begins in the Fit/Gap process and continues through all
subsequent phases. Setup documentation is often initially developed by vendor or
consulting resources, but must be maintained by CU staff through the project, and into
the operational life of the system.
System documentation consists of several parts. File layouts for all bridges and
interfaces to and from the system will be documented. Any customizations or added
logic will be documented. All designed reports and queries that extend the system will be
documented with layouts and logic specifications. Database designs and data rules
outside of the vendor database will be documented. In short, all extensions of the system
that make up the resulting solution should be documented.
Deployment
A deployment plan can not be developed until after vendor selection, however a general
overview of deployment considerations is provided here, to guide later planning.
Deployment of the new system will take place throughout the life of the project, and
extend into the production life of the system. Access to the system will need to be
provided in a systematic way, supported with training.
Project Team members will be the first group requiring access to the application. Any
software needs to be installed and appropriate security granted prior to system modeling
with CU setup values.
As the project progresses, more business users will need system access as they assist with
populating control tables, building test cases, and testing. Procedures must be developed
to request, approve, and maintain user access. Access security is further described below.
Security
Security encompasses who will have what access to information housed within the
system. There are many layers of security to be understood and configured in order to
ensure that CU’s data is secured according to federal, state and institutional guidelines.
All security configuration and management must be the responsibility of CU staff, not
consultants or vendor, throughout the project. This ensures that CU staff become expert
in managing security early on, and also ensures that the layers of security that fall outside
the immediate scope of the project (database access, network firewall and the like) are
integrated into the project appropriately.
At the outset of the project, CU should identify staff with the skills to configure and
manage the general areas of security noted below
1. Network environment security: Although network security is a general IT
security responsibility for CU, any new SIS application will greatly expand the

Page 52 of 91
number of potential remote users (via Self Service over the web), and also change
the way some network resources are used within the CU network cloud (through
use of batch and end-user reporting capabilities). At least one CU employee must
be expert in network, file and print server security, firewall, web access, etc., and
this person must participate in the installation and configuration of the application
environment, and on-going security discussions about user accounts and access.
2. Application Security: At least one CU employee must receive formal vendor
training in managing application security, and should have the responsibility of
Security Administrator included in his/her formal job description. This will
include managing user accounts, profiles and permission lists, a well as security
related to batch processes and end-user query and reporting. It will also include
managing how developers access development tools, and what objects they can
affect.
3. Database Security: The project team must include a DBA who is expert with
security at the database level. This includes configuring access both for
functional end-users and for application developers, and establishing a security
plan for both operational and backup or offline copies of all data.
4. Security Policy: Security includes both technical and regulatory considerations.
The CU security team should include an employee who has access to, and
understands, the State and Federal regulatory requirements CU must conform to,
and can interpret them in the context of the project. This becomes even more
important as CU expands web and self-service access.
System security will be defined throughout the course of the project. The specifics for
providing security access and data usage within the system will be determined as the
project progresses. Prior to acceptance testing, CU should execute a security test to
verify that the setup properly restricts access while allowing for individuals to complete
their work.
Change Management
Any project with the scope of an ERP implementation will introduce change into an
organization, and CU may use this opportunity to review existing processes, and adopt
best practices where they provide benefit and can be implemented with reasonable effort.
These kinds of changes can impact both individuals and departments, and may affect
departmental interactions, working habits and even institutional culture. Institutional
change must be carefully managed to ensure that the outcome of any change is positive.
A strong Change Management program will include an integrated communications plan,

training and documentation plan, and an organizational development plan, which will be
tied into the overall project so that activities take place at appropriate times.
Once the project moves into the implementation planning phase, CU should plan for, and
develop a support structure for the following general phases of a Change Management
process:

Page 53 of 91
 Planning the Change Program: developing a dynamic change plan with

milestones and feedback loops tied to the phases of the system implementation.
 Generating Sponsorship: Ensuring that the leadership team is on board and

committed, and that they understand and act on their roles as required for the
successful outcome of program. As CU moves forward, the Steering Committee
and Project Sponsors will need to fill this role.
 Managing Organizational Impacts: Determining the extent to which current

processes and institutional characteristics are aligned with the requirements of the
planned business processes. Understanding the new work processes that will be
implemented, and defining the job and workplace skills required to support the
new organization. Assessing the current level of skill within the affected user
population and comparing current to desired skills.
 Preparing End Users: Providing stakeholders with a clear understanding of

specific changes, how the changes affect them, and how the changes fit into the
bigger picture is imperative to create end user acceptance and advocacy.
 Providing Production Support Post Go-Live: Because CU will implement

several major student system modules and additional reporting tools in
overlapping phases, there will be a need to provide production support for some
modules while others are still being implemented. The demand will be
particularly heavy when implementation activities have to be coordinated with the
normal calendar of the student lifecycle. The organizational and staffing impacts
of these competing needs have to be considered and managed.
Project Communication
Project Team communication serves a vital link to the University community, helping to
share important decisions and milestones. From executives to end-users to students,
individuals are much more responsive to change when they have a sense of involvement,
and some advance notice of possible changes.
Communication serves several key goals: education, obtaining buy-in, and providing
information to those individuals impacted by changes to policies and practices. The
implementation project is a vast and complicated process that impacts an organization
and the participants in a variety of ways throughout its duration and at its conclusion.
That is why it is essential to carefully plan the communication that will occur over the
course of the project.
Key Elements of the Communication Plan:

 Project Events and/or Milestones
 Communication Audience
 Mode(s) of Communication
 Key Messages

Page 54 of 91
 Frequency of Communication
 Communication Owner
 Planned Communication Date
An effective Communication Plan:

 Provides an organized and planned approach to the delivery of key communications
during the course of the project.
 Clearly assigns responsibility, outlines the schedule of communication to key
audiences, and identifies the most effective mode(s) of communication.
 Supports the change management effort by providing change information
incrementally over a period of time.
Process Process Steps

Define Key Events, 1. The Implementation Team defines the key audiences.
Audiences, and 2. The Team identifies viable and effective modes of
Communication communication.
Vehicles 3. The Team reviews the Key Events that should be included in
the Communication Plan.
By Target Audience 1. The Team reviews, by target audience, each Key Event and
Define Key Events and devises the message as well as mode(s) of communication.
Communication 2. The Team documents each Key Event and the recommended
Message message.
Communication Plan The team selects a member who becomes responsible for the
Manager Assigned development of the detailed communication plan and the
communication as defined in the Communication Plan.
Communication Plan 1. The Communication Manager completes the detailed
Created and Distributed Communication Plan.
to the Team 2. As events occur, the Communication Manager is responsible
for executing the communication to target audiences or
assigning the task to another team member.
CIBER will deliver a complete Communication Plan as part of Project Definition. This
plan should serve as the foundation of the Communication section of the Project
Workbook.
CU has already set up a project website, and this will be supported and updated
throughout the project.

Page 55 of 91
Project Charter Project Management Controls
Project Management Controls

Decision-Making and Issue Escalation Process
The Operating Agreement section above contains detailed suggestions for making and
documenting decisions during the project. However, in the context of escalation, CIBER
recommends the following additional guidelines:
 The Project Team Leads should be empowered to make decisions on how to
utilize the delivered vendor applications to meet the University business
needs.
 The Project Management team will address issues that affect the project
workplan, resource requirements, deliverables or internal project schedule.
 The Executive Steering Committee will address University policy issues, and
changes of scope, cost, calendar or quality.
 The appropriate Project Advisory Group(s) and Project Liaisons will be
involved as necessary to provide guidance, and to advocate both for their
respective constituencies, and for the project when a decision is reached.
Decision delays, especially on critical issues, can adversely impact the project timeline
and budget. As the project progresses, project team members will become more involved
with analysis and testing of system processes and how these processes will support the
University’s business needs. During these activities, issues may arise that could impede
the progress of the project. If an issue cannot be resolved by the team leads within one
business day, it will be brought to the attention of the Project Director.
If the issue cannot be resolved within a second working day, the Project Director will
introduce the issue to the Executive Steering Committee for deliberation, and a final
resolution will be made.
Issues Management
Issues are events requiring a decision to avoid negative impact on the project. These
events exclude changes in system functionality, system problems or scope changes. Most
issues result when a project’s needs require a change in a University’s culture, business
practice or procedures. Effective risk management should anticipate many such events
but it is not possible to avoid all issues. Issues arise throughout the project and must be
addressed expeditiously. Some issues require research or additional information; others
can be dispatched immediately. All project issues must be assigned and tracked until
resolved.
Success Factors:
It is important to quickly identify and define potential issues to ensure project activities
are not delayed. Project Team members should work together with Project Liaisons and

Page 56 of 91
“owners” of the affected business area to achieve a well thought-out solution. Careful
consideration should be given to the following:
 Communicate the issue-handling process to entire Project Team.
 Create a central issue repository with access for all Project Team members.
 Conduct team discussions to properly identify and document the issue.
 Report the issue status to all affected.
 Assign a specific resource to lead the resolution process.
 Prioritize issues according to urgency and impact on the project.
 Follow a defined escalation process for high-level issues.
The Issue Management process contains the following five steps:
Track Issue
Assign Responsibility
Determine Resolution
Escalate Unresolved
Publish Issue Report
Each team will maintain a local copy of their own issues log, which will also be
communicated to project management. The Project Manager will maintain a summary
Issues Log. This iterative process, which is the responsibility of the entire team, is
further described below:
1. Track project issue

At a minimum, the following information is required for the reported issue:
 Name of the person reporting the issue.
 Date the issue was identified.
 Nature of the issue.
 Issue identifying number.
 Consequences and timeframe of consequences if issue is not resolved.
2. Assign responsibility for each issue

The Project Manager will identify and publish an owner for each issue (i.e., someone
given the responsibility to ensure the issue is closed in an appropriate manner). The
Project Manager will set target dates for closure and interim status reporting and add
the following to the Issues Log:
 Name of the issue owner.
 Target Date for issue closure.
 Interim Date(s) for reporting status.

Page 57 of 91
3. Determine Issue Resolution

The Project Manager will document the recommended resolution to the issue and any
alternatives to be considered and add the following to the issue report:
 Resolution required to solve the issue.
 Impact of implementing resolution.
4. Escalate Unresolved Issues

The Project Manager will raise awareness of unresolved issues to the correct
stakeholders as soon as possible to minimize negative project impacts.
 Suggest resolution strategies and identify where lead or Executive support is
needed.
 Follow through on the direction given by the stakeholders and Advisory Groups.
The Project Manager will approve the resolution actions recommended. If the
recommended action impacts the scope, schedule, cost, or quality of the project, the
change control process will be triggered.
The Project Manager will add the following to the Issues Log:
 Final disposition of issue.
 Who is responsible for carrying out the resolution.
 Executive approval, if required.
 Close out date.
5. Publish Issues Log

The Project Manager will maintain a log of all issues. The Issues Log will be visible
to all team members. They will ensure accuracy of the log and the status of each
issue. At a minimum, the Issues Log will have the following information:
 Issue identifying number.
 Date issue identified.
 Brief description.
 Who was assigned the research.
 Final disposition.
 Close out date.
The Project Manager will ensure that a complete history of all issues is retained. The
Project Manager will notify key stakeholders in writing within five business days about
new issues that may cause a significant change in project scope, schedule, cost, or
quality.
A sample Issues Tracking Log is included in Appendix 3.
Technical Issues Tracking

A centralized Technical Issues Log will be established for tracking system errors/issues
and their resolution. This log can then serve as a technical troubleshooting document for

Page 58 of 91
CU resources. This log must include cases submitted to the system vendor, as well as
their resolution. CU’s helpdesk software may be used in place of a Technical Issues Log,
so long as project-related issues can be separately categorized and easily accessed by
project team members. An advantage to this approach is that issues become the
foundation of the system knowledgebase.
Policy Management
As noted above, some issues that arise during the project will require a change in the
institution’s procedures or policies. Issues that affect business procedures for a single
business unit or function may be handled through normal Issues Management, however
those issues that affect procedures for more than one unit, or that affect official
University policy require additional review.
As part of the Project Governance structure, CU will create a Policy/Procedure Advisory

Group comprised of members who routinely recommend and implement University
policy, and those who work with State and Federal legislative bodies. This advisory
group should be involved any time University policy is significantly affected.
The escalation process for policy issues should follow the same first three steps noted in
Issue Management above, but diverges at step four:
4. Escalate Policy Recommendation to Project Liaisons
The Project Manager will escalate a policy analysis and recommendations first to
Project Liaisons for review and comment by each campus. Any changes or notes
received from Project Liaisons will be returned to the issue owner to be incorporated
into the recommendation.
5. Escalate Policy Recommendation to Policy/Procedure Advisory Group

The Project Manager will next escalate policy analysis and recommendations to the
Policy/Procedure Advisory Group, who will review the proposed new policy in the
context of existing University policy and the broader state and federal context.
Once a policy is reviewed and approved by the Policy/Procedure Advisory Group, it

may follow one of three paths:
6. Optional: Escalate Policy Recommendation to Executive Steering Committee

Policy changes or recommendations that have broad impact, or that may require a
change in staffing, project scope or cost to the institution should be escalated to the
Executive Steering Committee for review prior to formal implementation.
7. Optional: Public Review of Policy Recommendation

Policy changes that have broad impact or that may result in a change in staffing or
cost to the institution may require a public comment period. In this case the “public”
would typically be University faculty, staff and students, but in some rare cases it
may include the greater University community.

Page 59 of 91
8. Publish Policy Recommendation/Escalate to Change Management

Once a policy has been properly reviewed and approved, it should be published as
appropriate to its level and type. All policy issues must be tracked in the Issues
Management Log, and in the Project Workbook. Changes to University policies
should also be published with other similar policies as appropriate.
Finally, if the policy involves changes in university culture or procedures, it should be

escalated through Change Management
Change Control
The change management process addresses the needs and affects of change on the
University and its organizational structures and business processes. Change
management is concerned with how the project affects the institution, and should live
beyond the implementation of any new system.
The change control process encompasses any alterations to the tasks, resources, schedule,
quality, or costs of deliverables for the project itself. Change control is internal to the
project, occurs primarily during implementation, and is used to control and maintain
scope, schedule and budget.
The Fit/Gap process is the primary discovery tool for determining changes to the baseline
system. CU intends to pursue a balanced strategy when gaps are identified, as articulated
in the fifth project principle, and re-stated here:
“When delivered functionality conflicts with existing business processes or

needs, CU will give equal consideration to
 Process change (revising the business process to meet system
requirements),
 System modification (customizing the system to meet business
process requirements), and
 A blend of process change and systems modification.
When considering options for addressing change, each approach will be

researched and documented, and the short- and long-term costs for each will
be estimated. Options will be escalated through formal issue, change and
risk management as appropriate, and the final decision will be publicly
documented.”
Once customizations and modifications have been identified and approved as a result of
the Fit/Gap process, any additional changes to the baseline system will regulated by the
change control processes.
Some changes are imposed on the project as a result of external events beyond the control
of the team. Examples of these external events include turnover of team members, illness
of a key project resource or imposition of new requirements by an external regulatory

Page 60 of 91
body. Each of these changes must be evaluated for its impact on the project, and
agreement reached on the approach to address the change.
Change control will include effective tracking, monitoring, and control over changes by:
 Establishing a central point of control and a decision-making process.
 Minimizing any changes, even those that are easy to make (which can cause a
project to go out of control when too many are proposed). This step includes
identification and analysis of alternatives.
 Requiring a business case to be documented and approved through the appropriate
approval process. This process should be used for both changes identified in the
Fit/Gap process and any subsequent changes.
Change control also includes changes to the tasks agreed to in the Project Charter and the
Project Plan approved at the conclusion of the implementation planning phase. New
requirements that surface over the course of the project (resulting in increased estimates
of effort) are also subject to the change control process.
Examples of events or circumstances that may invoke the change control process include:
 Someone requesting a system modification.
 Resolution of an issue requiring a change.
 Identification of an action to address a risk.
 Software release upgrades.
 Changes in CU’s business climate.
 Team lead turnover.
 Decision to change the content or format (and therefore the quality) of training or
documentation.
 Inability to support Project Team commitments.
Key Elements of the change control Process:

 Establishment of project baseline, usually the Project Charter and Project Plan,
variation from which triggers the change control process.
 Documentation and analysis of proposed changes, including alternatives and
costs.
 Formal approval process.
 Structured tracking of proposed changes.
Notification of intended changes must be communicated in writing from Functional

Leads to the Project Manager, and should include justification and analysis of the impact
on the project. This analysis must include an estimate of the system objects affected, any
impacts to the target module and to other system modules, and an estimate of the time
required to complete the change.

Page 61 of 91
Deliverable Acceptance
Deliverable Acceptance is an essential part of the functional users taking ownership of
the new application. Deliverable Acceptance can be associated with individual tasks,
project milestones, or vendor payment points. It may also have legal and contractual
ramifications. Acceptance of individual tasks is more a function of individual ownership
and accountability, while acceptance of a milestone frequently has contractual
implications. Re-visiting tasks after a milestone signoff is likely to cause a change of
scope.
Deliverable Acceptance will require sign off by the appropriate team lead and functional
director, as well as the Project Director.
In order to maintain the project schedule, end users should take no more than ten (10)
business days from initial delivery of each deliverable to confirm that the deliverable
substantially conforms to the specifications. Should any Deliverable Acceptance request
be declined, it will be required for the person rejecting to state specific reasons. This
allows for the Project Team to understand and focus on the issues causing the refusal and
act on them in a timely manner.
If an end user does not provide notice to the Project Manager during the 10 day period,
the deliverable will be deemed accepted.
Upon rejection, the responsible team member or members may take 10 days (or longer, if
mutually agreed upon in writing) to correct the issues identified when the deliverable was
rejected. The deliverable will then be resubmitted to the Acceptance process.
Please see Appendix 4 for a sample Deliverable Acceptance form.
Quality Assurance
There are several methods to monitor and assure project quality. One of the most
important is for the appropriate CU staff to be fully engaged in all phases of the
implementation project. This ensures that the University’s business needs are
communicated to the project team, and are therefore more likely to be met. It also
ensures that once the application is in production and consultants have departed, CU is
fully prepared to utilize and support the application.
The Project Charter outlines controls and strategies, including testing requirements,
signoff of deliverable acceptance, and development standards. These are further
elaborated in the Project Workbook. Adherence to and successful execution of the
established procedures for change control, risk management, Issues Management, Status
Reporting, and Communications help to assure quality output.
The testing approach described above is another key component in Quality Assurance.
Any project that involves software should include “code review” in the Quality
Assurance plan. This step identifies errors in programming code (in customizations,

Page 62 of 91
interfaces or reports) before it gets to the system testing stage. Carefully and
consistently following the progression from reviewed and approved functional
specification, to reviewed and approved technical specification, to developer unit-testing,
to user unit-testing ensures that a program is accurate prior to integration with the
application.
Finally, CU may consider using a non-project resource to provide a review on a periodic

basis, usually after meeting major milestones. The objective of these reviews is to ensure
that the project is complying with established processes and methodologies. This
resource could be a University of Colorado employee who is not involved in the project,
but who has sufficient awareness and expertise to be able to evaluate it at a high level.
Alternatively, CU could use an external consulting firm or other resource for this
purpose.
Risk Management
Risks are events that could have an impact on the project, and that require an action (not
just a decision) to respond to. Risks may affect any or all or the major aspects of the
project: scope, schedule, resources, and quality. The risk management process is a
structure for identifying, assessing, addressing, monitoring, and communicating the status
of potential risks.
It is important to note that a project can include both positive and negative risks, and both
types require identification and planning. Negative risks are easier to identify. For
example, if a critical member of the team becomes ill and can’t complete his tasks, this
delays other tasks, and may cause a ripple effect through the entire project.
But it is as important to consider and manage positive risks. For example, the team may
complete work on a major task several days before they were scheduled to. If the
following (dependent) tasks can’t also be moved up, then a window of slack time
develops. This can be capitalized on for other work, if it is recognized in a timely
manner. If this slack time isn’t handled properly, then some members of the team may be
idle until the next task can start.
Once a risk is identified, risk mitigation strategies will be developed and invoked to
eliminate or reduce the potential risk whenever possible. On a monthly basis, project
management will formally review these risks and the documentation will be updated to
reflect new risks and any changes to probability, impact or strategies, actions,
assignments, and deadlines. When the impact of a risk could become an obstacle to the
project success, or when previously identified risk mitigation actions remain incomplete,
the risk will be escalated to the Executive Steering Committee.
The risk management log is used to track the key risks associated with the project,
estimate the likelihood they will occur, and estimate possible loss due to each risk. The
Probability column should be based on previous experience or best guess estimates.
After identification, risks with the highest probability are given the highest priority. See
appendix 5 for a sample risk management Log.

Page 63 of 91
In any given week, Project Management should be focused on the top five or ten risks, as
prioritized above. “Active” high-priority risks should be escalated to the Executive
Steering Committee as needed for resolution.
The table below outlines initial risks identified during project definition meetings on each
of the campuses, and with various central and administrative offices. This is an initial list
that can serve as the foundation for the complete risk management log, to be created
during Implementation Planning.
RISK POSSIBLE MITIGATION

SCT support for IDMS: 1. Implement critical functionality in the
SCT will not support IDMS past 2009. new system before legacy support
expires.
2. Extend legacy support through the use
of internal staff until the new
application is in production.
3. Investigate participating in a coalition
of other IDMS users to provide legacy
support until the new application is in
production.
Staffing: 1. Create a separate project staff. Where
CU staff will not be able to dedicate necessary, develop a backfill strategy
sufficient time to the project, which will and budget for institutional positions
cause delay. so that team members can concentrate
on the project.
Staff with full time departmental and 2. Assign a full-time project manager,
project responsibilities will fail to execute and appropriate full-time project
either effectively. In a worst case, this can administrative staff.
cause both project failure, and a 3. Work with line managers to eliminate,
breakdown in departmental operations. or properly fund, competing projects
or priorities.
Staff turnover during the project will 4. Ensure that the project budget
result in the loss of functional and includes contingency funds for hiring,
technical expertise. or for consulting support.
5. Consider hiring into project positions.
It is not clear how the transition from 6. Where appropriate, cross-train project
implementation to a production team members in more than one
environment will affect staffing, both of module or function.
project and backfilled positions. 7. Develop a Staffing Plan for the
transition to a production environment
that takes into account the changes in
both project and backfilled positions.

Page 64 of 91
Executive Support 1. Work with Executive Steering

The continuing transition at the executive Committee to monitor staffing and if
level at both campuses and system offices necessary develop project succession
may erode support for the project. plan.
Enterprise Resource Planning (ERP) 1. Plan and execute a comprehensive
System Project Credibility communication plan.
Previous enterprise system initiatives have 2. Ensure that this project’s principles
had mixed success, which causes a and plan include the lessons learned
credibility gap for this project. from earlier CU ERP projects.
3. Fund and involve Project Liaisons for
each campus, and ensure that
campuses and departments have
opportunities to participate, and
provide feedback throughout the
project.
4. Hold a project-wide kickoff meeting
that includes all project members from
the team up through the Executive
Sponsor.
5. Provide early overview, demo and
training opportunities for team
members and other stakeholders to
become familiar with the process.
6. Ensure that the project team includes
experienced vendor and consulting
support.
Project “Sticker Shock” 1. Begin communicating the reasons this
The realistic cost of the project will cause project is necessary now, and
negative push-back from both university communicate this widely.
and external constituencies. 2. Clearly explain how this project will
(positively and negatively) affect
The project may not secure adequate support for students, faculty and staff.
funding for the desired scope. 3. Ensure that the project budget and
scope is realistic both in terms of
achieving project objectives, and in
the context of the University’s other
priorities.
4. Provide cost estimates as soon as they
are sufficiently understood.

Page 65 of 91
Current Process Documentation 1. Individuals who understand business

Many of CU’s current business process operations in a given unit or
are insufficiently documented or not functional area must be available to
documented at all. This increases the the project (as Subject Matter Experts)
effort to understand them, revise or adapt in order to transfer their knowledge to
them to a new system and document them the project team.
in the new environment. 2. The project team must include staff
with the responsibility of
documenting current and revised
processes throughout the
implementation.
3. The project plan must allow additional
time to walk through, understand and
document current processes.
Communication 1. Ensure that the training and
Users are not aware of all the capabilities documentation includes materials both
or functions that are already available in for critical job functions, and to
SIS. If this isn’t addressed, the same issue explain new features and functions.
will occur with the new application. 2. Devote one portion of the project
website to an overview of features and
functions. Start with legacy
information now and transition to the
new application as features come
online.
3. Consider presenting this kind of
information at already scheduled
“brown bag” sessions.
4. Add this issue, and proposed solutions
to the Communication plan.
Responding to External Legislative 1. The project plan must include an
Mandates effort to research and anticipate those
Legislative mandates, regulatory and that are known to be forthcoming.
compliance issues (for example, from 2. The project team should include an
CCHE) will arise during the course of a advisory group comprised of members
multi-year project. who work with these agencies
regularly.
The US Department of Education is 3. The project budget should include
considering a proposal to move to unit contingency funding to accommodate
record level reporting in IPEDS. unforeseen events.

Page 66 of 91
System Cutover 1. The project plan must include both

The transition from one system to the next thorough testing and quality assurance
should be seamless to students, and should activities, and these must be executed
go smoothly for faculty, staff and other during implementation.
users of the legacy application. 2. This project should work closely with
the faculty/staff and student portal
projects to ensure tight integration.
3. The training plan must accommodate
both casual, first-time and “expert”
users, and training needs to be
properly timed with deployment.
Ongoing consolidation of UCDHSC 1. Ensure that UCDHSC staff are
The ongoing consolidation of UCDHSC significantly involved in this project.
will have an effect on project staffing, new 2. Ensure that the project
system design and configuration, and data communication strategy includes a
warehouse design. It may also require method for changing UCDHSC needs
changes in the legacy application. to be quickly and effectively
communicated to project staff.
UCDHSC Transition to Residence 1. Create a separate project staff, so that
Campus SIS project team members are not
The UCD downtown campus is significantly engaged in the UCD
transitioning to a residence campus, transition.
beginning in Fall 2005. 2. Maintain close contact with UCD staff
involved with the transition to see if
and how this might affect the SIS
Replacement project.
Relocation/Renovation Projects 1. Create a separate project staff. Where
necessary, develop a backfill strategy
Possible relocation of system and budget for institutional positions
administration offices from Boulder to so that team members can concentrate
Denver. on the project.
2. The project budget should include
The potential HSC move to the contingency funding to accommodate
Fitzsimmons campus between 2006 and unforeseen events.
2008 may affect project staffing, and
divert institutional resources.
The UCB College of Business will be

moving out of their building for
renovation.
The UCB Film program is moving from

Macky to ATLAS in 2005 or 2006.

Page 67 of 91
Infrastructure 1. The project plan must include tasks

The technology that users need to access that include technical architecture
the system must be in place prior to their review and planning for elements
first access to the system. from server and related systems
through network architecture, security
and provisioning, to end-user
equipment.
2. A technical architecture team must be
included in the project structure.
3. Select a new system whose core
functions are presented through a
minimal client.
4. Users should be notified well in
advance of the minimum desktop
configuration required to run the new
application, so that requests for
equipment can be integrated into
normal budget request cycles.
5. Project team members must receive
the correct equipment prior to the
beginning of the implementation
phase.
6. The project training and deployment
plans must be synchronized with any
equipment rollout.
Helpdesk and User Support 1. The Helpdesk staff must be well
Good helpdesk and user support is trained, properly staffed and
required for a successful implementation. confident.
2. The deployment plan must include
helpdesk roll-out prior to any end-user
access.
3. Helpdesk knowledgebase and tracking
software must be in place to monitor
issues and resolutions.
4. The project plan should include a
discussion of both centralized and
decentralized (i.e.: departmental
liaisons) support.

Page 68 of 91
Accreditation Projects 1. Ensure that the project

The consolidated UCDHSC will be communication plan includes a
gearing up for a site visit for re- method to regularly inform the staff
accreditation in 2011. Although this who will be preparing for
should occur after the implementation, it accreditation of the project status.
will require significant effort and long
lead time. If the SIS project is delayed,
these two projects may compete.
UCB will go through Accreditation

Review in approximately five years.
Preparation for this will start in 2008.

Page 69 of 91
Project Charter Appendices
Appendices
Appendix 1 – Project Charter Interviewees

Page 70 of 91
Appendix 2 – Initial Functional Requirements

As noted in the executive summary, the SISG+ Advisory Group recommends that CU
conduct a thorough Functional and Technical Requirement Definition phase prior to
vendor selection. However many functional needs were identified over the last two
years, during team meetings, vendor demonstrations, and the Project Definition meetings.
These are documented below in order to capture them in one place. Since CU has not
yet conducted formal functional requirements definition, these needs are simply listed
without elaboration at this time.
In its current form, this constitutes a system and project “wish list” more than a functional
requirements list. Many of the items listed below are truly functional requirements that a
candidate vendor application should meet. Others could only be achieved through
significant work with third-party applications, and cannot be reasonably expected of the
candidate system. For example, “single-sign on” to all applications including CU’s third-
party warehouse is not something a candidate system can provide. However the system
should be able to support single sign-on. Further, some items (such as the need for a
good helpdesk staff) are project or institutional requirements, not functional
requirements.
The items below are grouped by the current major functions of SIS, and are not
prioritized. Once CU moves into formal requirements definition, these should be
regrouped according to desired functionality (for example, it appears that CRM could be
a section of its own), and given weights or priorities.
General Requirements
1. Ease of use – better navigation, fewer codes, and fewer screens to perform a task.
2. Fewer codes and better translation of codes and values on pages.
3. Workflow capability.
4. Event-driven notifications or triggers, including student and staff “alerts.”
5. Integrated “instant messaging” (no detail with this comment – is this event
notification?)
6. Workflow and event-driven notifications should extend to “peripheral” users of the
system (i.e.: those who receive data primarily through interfaces rather than direct
login). For example, a user commented “When the student changes his or her address
in SIS, that information should get to everyone who needs it.” (This may require a
universal directory solution, and may therefore be out of scope.)
7. Rules-driven system, and simple, easy-to-maintain business rules management.
8. Better integration across campuses, and across current “divisions” such as B1, B2,
D1, D2, etc.
9. Access to real-time data (this can also be a constraint and a performance risk.
10. A focus on automation, rather than manual processes to accomplish system tasks.
11. Support for single sign-on to all portions of the integrated system.
12. Audit trails for changes to data. This capacity should be configurable by the
institution, so that the data CU wants to audit can be audited.
13. Field-level security (not just page or menu level security).

Page 71 of 91
14. Time-based security. Students can drop and add for only a limited time; and this also
applies to registration and courses. The ability to control screen access/security by
term (as we do in the summer), when deadlines have passed, etc. CU may want to
expand this capability to other areas.
15. Consistency of security – the same security a user has in the application should apply
to what the user can access in the data warehouse, or other portions of the system.
16. It should be easy to add fields as new data needs arise.
17. Summary and aggregate screens, so that users don’t have to look at five pages to see
what they need for on task.
18. The ability to track more historical information in a variety of areas.
19. Support for mixed-case characters.
20. Support for special characters (like mathematical symbols).
21. New methods of searching for students – by name, SID, birth date, major, college –
more than is currently displayed on screen 002.
22. Large note/anecdotal comment fields, including information about who wrote them,
and when they were written.
23. Faculty (and other infrequent users) should be able to be true “users” of the new
application, and not need to ask someone else for help.
24. The system should be intuitive enough (or provide sufficient, easy-to-find and use
documentation) that infrequent users, brand-new workstudy students, and first-time
users should be able to perform some limited tasks with little or no instruction.
25. Provide more user control over things currently done centrally. For example,
designating types of event notification, creating new contact/response codes, and
other table changes.
26. Flexibility in designing, placing and releasing holds.
27. Easy reporting for non-technical users.
28. Many ways to access system “help” information (explanation text directly on screens,
online user manual, computer-based training, etc.).
29. Easy access to help information, searchable in a variety of ways. Help text in
layman’s terms, not technical terms (unless appropriate). This should include the
ability for technical users to start from element or object name and trace their way
back to menus, pages and functions.
30. System documentation that is easy to customize and maintain.
31. Integrated web self-service.
32. Online address changes.
33. Online selective service registration certification.
34. Maintain and improve current web functionality.
35. The ability to track the data required for a “residence campus” (i.e.: immunization
data, etc.).
36. Good helpdesk staff.
37. The system should enforce business rules and data edits across the entire application.
For example, graduate courses should only be taught by graduate faculty, but the
current application doesn’t enforce that rule.
38. The system should support cross-campus authorization so that a student from one
campus can easily get services (library, etc.) on another.
39. Support for many address types, and the ability to track history for each.

Page 72 of 91
40. The ability to accommodate parent data (for the parent database).
41. The ability to track an individual from student prospect all the way through to alum.
Technical Requirements
1. Fast system response.
2. A robust system that can handle thousands of simultaneous users (students, faculty
and staff) using the application through self-service, back-office, batch and reporting
facilities.
3. Stable technology.
4. Full Macintosh compatibility.
5. ADA compliance and 508 compliance.
6. Integrated email functions (i.e.: the ability to send email to an individual, or a freely-
defined group from within the system).
7. Much easier context-based correspondence with students from within the system.
8. Easier creation of email accounts for new students.
9. Multiple database environments.
10. A way to easily identify whether you are in TEST, PRODUCTION or other database
instance.
11. An easier method (or toolset) for uploading student information (probation codes,
advisor names, etc.) in bulk.
12. Open architecture or support for open architecture.
13. Hierarchical processing and workflow.
14. Tools to provide better integration with other data sources (e.g.: the Alumni database,
Faculty Productivity database, HR and Financials, shadow databases, etc.)
15. Support for both real-time and batch processes.
16. The ability to run batch processes without taking the system out of service.
17. Improved, more frequently-refreshed test systems.
18. Batch interfaces should enforce the same edits that online processes do.
19. Real-time access to information for both an individual and aggregate data.
20. Reports and data extracts should be available in a variety of formats (CSV, Excel,
XML, PDF, etc.)
21. Data extracts should be easier to change in response to changing needs. The process
is time-consuming now.
22. The ability for each campus to develop their own reports, summary pages, etc. The
ability to allow each campus some control over their own processes and use of the
system, while maintaining central edits and controls.
23. Select a vendor that is forward-thinking in terms of emerging technology – access
through PDAs, etc.
24. An application that runs on multiple platforms.
25. Automated address cleanup (or interface to a product that provides address validation
and cleanup).
26. Process to handle duplicate records.
Interfaces
This list is very incomplete, and will be better defined during implementation planning.

Page 73 of 91
1. FSA Atlas
2. Integration with existing document imaging/document management solutions.
3. Some graduate programs at each campus are using a program called “Apply
Yourself” which the new application must integrate with.
4. Parking application
5. Disability Services
6. Housing
7. Pinnacle (our web app, /electronic prospect card)
8. U-portal (admitted student portal)
9. Accord and Cardiff (our imaging system)
10. Mentor (state wide web application)
Admissions/Student Records/Registration
1. Flexibility in defining how a course is listed (on-campus, off-campus, online, etc.).
2. Cohort tracking.
 As soon as the student is identified,
 Students may be part of multiple cohorts,
 From admissions, registrations, etc. all the way through reporting,
 Provide a better alternative than contact coded,
 Allow flexibility in how long the cohort is set/taken off – 1 term, entire
academic history, CU institution level
3. The ability to store more than three current applications, and the ability to maintain
application history.
4. Conditional drop-add.
5. Course Management.
6. The ability to search for courses in real-time, via the web, by core area, department or
college. This should display only open courses, by time, etc. This function should be
visible to students and faculty/staff.
7. The ability to search for other sections of a denied/closed course
8. Ability to view enrollment for student for all campuses, all semesters.
9. Enrollment management and reporting.
10. Test score uploads and near match process.
11. Support for online application.
12. Classroom scheduling, or integration with a variety of classroom scheduling products.
(The most-often mentioned product is “Schedule 25/Resource 25”, but a number of
institutions have also said they like “AdAstra” better.)
13. Integration with other online applications – for example, medical students use a
national service, rather than applying to one institution at a time.
14. Faculty should be able to enter their own grades online.
15. Users should be able to see related admissions and records information on one (or
only a few) screen(s). Right now most users have to toggle back and forth to view
and update this information.
16. Open calendars (not tied to term basis for classes) for things like drop/add/payments,
grading, refund deadlines – to the section level.
17. Drop add, payments, refunds; department access – how long a student can access
drop/add for a particular course (currently done at term level). Example: student has

Page 74 of 91
same deadline for whole schedule, regardless of when course starts; with payment
and fin aid tied to that deadline.
18. The ability to handle courses that begin in the middle of a term properly, and without
excessive manual steps.
19. Track, update and manage High School index codes.
20. Provide support for enrollment prediction modeling.
21. Real-time quick admit – i.e.: create the term record immediately.
22. Real-time schedule planner integrated with registration, and identification of course
alternatives if courses are closed, or there is a conflict. In this case provide best-fit
schedule (especially at orientation).
23. Real time notification of course is cancelled – to select the events without lots of
programming.
24. The ability to set course restrictions by GPA, test scores, etc, and display restrictions
so students know specifically whey they’re ineligible for the course.
25. Time assignments for registration.
26. Online graduation application.
27. Graduation checkout, all the way through commencement planning.
28. Easy creation of the schedule for the next term. The current term roll process is
inflexible and requires much manual effort.
29. Support for programs such as “Maymester” (which has a compressed term).
30. The ability to change with changing institutional needs. As an example, UCB looked
into a new tuition model for graduate education but couldn’t move forward because
SIS would not support it technically.
31. Prospect Management and Customer Relationship Management (CRM) as part of
core student recruitment and admissions functionality (not through bolt-on).
32. Contact management (may be the same as CRM).
33. Advisors, students, faculty and staff should all be able to see the same view in order
to best assist on phone calls, and this information should be real-time.
34. The ability to fully and correctly track graduate program data – the current system is
too “undergraduate-focused.”
35. The ability to track graduate and professional school (i.e.: Law, the Med School, etc.)
applications.
36. Multiple major, program and concentration codes.
37. Easy mid-term grade reporting that includes more than just grade, but also class
attendance and participation information.
38. The ability to include students from more than one campus (including online
students) in a single class; the ability to represent this as one unified class; and the
ability to also distinguish which student came from which campus.
39. The ability to offer the same class on two campuses. How can one class be visible on
two different campuses (this came up in the context of UCDHSC).
40. Better integration of student and program data across campuses into a single record,
for students taking courses at multiple campuses.
41. The ability to track and enforce pre-requisites selectively: Some courses have no
flexibility, others require flexibility.
42. Support for flexible probation and suspension rules. Each school may have some
different needs, and there are also university-wide rules.

Page 75 of 91
43. The ability to handle co-requisite courses properly.

44. Management control (the ability to control registration dates/times by defined group)
45. Course wait-listing, including checking on waitlist position, wait list priorities and re-
sequencing.
46. Override capabilities for closed courses and restrictions (for faculty and staff).
47. The ability to set restrictions on courses and check for them in registration (by major,
class, predicted cumulative hours, and/or college).
48. Allowance of special grade types (p/f, no-credit, variable credit) and ability for
student to change these via the web without dropping the class through the deadline.
49. The ability to suppress call numbers from web registration for controlled enrollment
or other special courses.
50. Provide a registration audit trail (date/time of transaction, including grade type,
source of transaction, etc.).
51. Ability for students to enroll above the waitlist during orientations.
52. Ability to increase course limits for each orientation.
53. Degree audit
54. Linked activities
55. The ability to register across academic units.
56. Common transcript
57. The ability to “customize” the transcript, add fields to it or limit it to specific program
(Does this require CCHE approval?)
58. Batch scheduling for groups of new freshmen.
59. The ability to track student photos (uploaded from the Buffcard database?) and use
them for class rosters.
60. Allow students more choice related to what information can be released through
FERPA
 check off by item; (currently students are “private” or “semi-private”),
 let students decide who information can be released to using access profiles
61. The ability to track many minors.
62. The ability to track Human Subjects Compliance, going through the IRB process.
63. The ability to check off that a student has submitted his/her final thesis to the library.
64. Support for course-based reading lists or holds (for library interface).
65. The ability to place a hold on a student’s grade until the student completes the faculty
evaluation for the course. This process would have to protect the student’s
anonymity, but not release the grade until evaluations are complete.
66. The ability to log when an exception (re: withdrawals) was granted, and whether or
not it was approved (i.e.: Military Exceptions). The ability to track this individually
and also to be able to aggregate the information.
67. The ability to track Fast Track codes for high school students.
68. Easier data management and reporting. For example, CCHE asks for data aggregated
by City and County codes, but these codes don’t exist in SIS.
69. Support for more “richness of data”: A lot of the data departments need to report back
to various state or grant-making entities (first year admits, first-time admits, felony
admits) is not tracked in SIS.

Page 76 of 91
70. Curriculum modeling – the ability to take a cohort and plan 3-4 years of course
demand by, to lowest level, academic program cohort (function like induced course
load matrix, at various levels).
71. The ability to allow on-line pass/fail and no credit changes to a student’s schedule
during the drop/add period instead of having to manually change them.
72. Provide support for Rotation scheduling for 3rd and 4th year medical students without
excessive manual work.
73. Wait listing.
74. Support for tracking and degree verification of post-MS certificates (Nursing school).
75. Support for tracking clinical hours.
76. Support for class attendance tracking.
77. Admissions Event Planning.
78. Unique course ID for course inventory, course tables, and degree audit.
79. Withdrawal with different rebate codes.
80. Accept/Track enrollment deposit.
81. Assign group codes (during enrollment?)
82. Handle student opportunity fees.
83. Provide the ability via the web to take in several course requests and display back the
best possible option for enrollment in as many of the requested courses as possible.
84. Concurrent registration.
85. Ability to set up future term records manually (for TOP students, etc.)
86. Roll forward program.
87. Ability to set and override stops.
88. Tracking/coding of students in special programs (athletes, residential academic
programs, etc.)
89. Track more than two colleges and two majors per college.
90. Provide on-line transcript print availability. Allow user to view the transcript in its
print form on-line.
91. Provide online status checks for students (i.e.: status of application, any needed
paperwork).
92. Support for Recruitment Campaigns and Marketing.
93. Automated email response system (via template or knowledgebase).
94. Reservation system to handle/track/send confirmation notices to families for campus
visits/receptions/other recruitment programs.
95. Support the needs of international students, including international applications,
credentials, addresses, phones, etc.
96. Support for AARM- Auto Admit.
Advising, Degree Audit, Transfer Credit

1. Complete degree audit and transfer articulation.
2. 360 degree counselor summary in FA (i.e.: a better 1R2 screen).
3. “What if” degree audits across campuses and prior to enrollment, including transfer
credits.
4. Easy to understand relationships between admissions data and course inventory and
transfer tables and degree audit.

Page 77 of 91
5. A trigger such that when a student makes significant changes to his schedule (changes
that “conflict” with advisement), he is prompted to go back to see his advisor, and the
advisor is also notified.
6. Customer Relationship Management (CRM) for Advising functions, for example,
scheduling an appointment with advisor, calendar integration, e-mail notification to
the advisor of the event, and advisor notes integrated into the application.
7. Various summary pages and reports that show all advisement by individual, by
program, by group so that departmental administrators and chairs can see trends and
needs across a department or school.
8. Profiles of course enrollment and the ability to specify what requirements the students
have met. How many of the students really need the course, or have met the
requirement in another area? Overall how many students have met and not met a
requirement? This helps to determine course availability.
9. The ability to create degree audit forms that match advising sheets for a school.
10. Real-time pre-requisite checking that is tied to degree audit.
11. Schedule build based on degree audit results - in effect, on-line sectioning.
12. The ability to do course availability searches by college.
13. Staff need to be able to see the same, real-time information a student sees when
advising.
14. Ability to title a degree audit by individual audit.
15. Provide a ‘copy’ feature for audits/requirements.
16. Allow multiple “careers” (e.g. US, GS, GN).
17. Allow for multiple repeat course rules (by college).
18. Include options to either include or exclude printing of course lists for requirements.
19. Include options to either include or exclude printing a specific course on a course list.
20. Allow terms of applicability to be defined for each course.
21. Provide flexibility for including/excluding specific types of courses (e.g. major,
minor, core, MAPS).
22. Provide ‘reuse’ codes to include/exclude courses for requirements.
23. Provide ‘exclusion’ rules (e.g. exclude any course previously used).
24. The ability to report GPA by section (sections or blocks), and the ability to suppress
this.
25. Provide a ‘priority’ feature that can be managed by registrar’s staff.
26. Provide a feature to calculate different sets of requirements by different catalog years.
27. Provide a ‘residency’ feature (e.g.: identify resident courses).
28. Provide controls to manage:
 minimum required grade
 pass/fail
 no credit
 2-yr school transfer credit
 resident credit
 specific types of credit to a requirement (e.g. independent study, internship, credit
by exam)
 specific grading types (e.g. p/f, nc)
 courses taken in a degree program vs. those taking as non-degree

Page 78 of 91
What controls exist at the course level, and what controls exist at the requirement
level?
Billing and Receivables

1. Better automation of tuition calculation.
2. Tuition flexibility and tuition revenue recognition (especially in light of possible
enterprise status and related variability of tuition.)
3. The application must allow CU to charge tuition by course status (again referring to
D1, D2, etc.), student status or both.
4. The BRS application should be able to accept detail uploads from Parking and the
Library (current application requires that multiple fines and citations be summarized).
5. Flexible and integrated billing.
6. Support for billing over the internet.
7. Support for ACH and E-check.
8. Support for direct deposit.
9. Keep TRA processing.
10. Accounting feed/paid and applied.
11. Support for third-party billing, split billing like WICHE and parent billing - tracking
transactions with parents back to the correct student account (refunds).
12. The ability to “hide lines” on a bill (i.e.: accounting in/outs for offsetting charges –
we can currently do this, by summarizing subcode (current limit of 99,000 on # of
subcodes we can have in current system, with defined ranges by campus), but we
don’t always want to do this by subcode. CU needs flexibility to do this by
school/college.
13. Easier way to handle transactions between campuses (for example, moving Financial
Aid from one campus to another).
14. Easier money and account transfers between students with records on multiple
campuses.
15. Track short term loans separately from demand warrant processing. Currently they
are the same control screen (dates/terms), and the current process for short term loans
is driven by demand warrants.
16. Better integration with the financial system.
17. Integrated cashiering and collections modules.
18. Greater flexibility in defining stops, with more options in terms of the number of
stops available.
19. The ability to tie to offline source documents (like Promissory notes).
20. Payment plan capability - possible direct withdrawal of funds for students with
payment plan.
21. Support for billing from an ID file.
22. Tax Relief Act (TRA) processing
23. Delayed billing: CU should be able to create a bill in June, but not have it apply until
fall.
24. Better billing automation, including better billing support for non-traditional
programs like Study Abroad.
25. Cashiering function.

Page 79 of 91
Financial Aid
1. “Anticipated aid expiration date” for work study awards.
2. 360 degree counselor summary in financial aid.
3. On-line promissory notes.
4. Master promissory note tracking.
5. Refunds.
6. Parent borrower screen.
7. Origination, disbursement, credit check tracking.
8. NSLDS/award aggregation.
9. The ability to easily manage Financial Aid across academic units (B1, B2, D3, etc.)
without manual processes.
10. Complete support for Financial Aid Packaging (UCCS does this all offline).
11. Provide easy electronic communication with students relevant to the Financial Aid
process.
12. The system should be highly configurable and customizable, especially with regard to
packaging, disbursement and budget.
13. 24 x 7 accessibility for students.
14. Quick and efficient bulk e-mail.
15. Automatic calculation/hold of financial aid for withdrawn students.
16. Integration with document management and imaging for Financial Aid needs
specifically.
17. Robust document tracking (or CRM).
18. More efficient processing (batch and other) that would allow CU to run the
equivalent of weekend processes every night – this would allow us to notify students
sooner than is done currently.
19. “Intelligent integrated budget calculation” versus the current, very manual process.
Cost of attendance calculation – getting to level of specific students record courses
and fees. Business issue: should budget change each time a student drops/adds?
20. Pre-delivered self-service web functions for Financial Aid.
21. Automated report routing relevant to FA reports.
22. Timely delivery of Financial Aids regulation changes. Also, the process of applying,
reviewing and approving these shouldn’t be too cumbersome.
23. Tracking student employment.
Other
1. Better accommodation of faculty data.
2. The ability to get a list of faculty and check faculty load.
3. Easier reconciliation between the new SIS and other applications (such as PeopleSoft)
on campus. Right now, reconciliation is too cumbersome and manual. For example,
the School of Education at UCDHSC can’t reconcile projected to actual tuition
revenue. In addition to effort, this causes audit concerns.
4. The ability to track UUID in the system.
5. Support for NCAA rules, compliance, data and needs.

Page 80 of 91
Appendix 3 – Sample Issues Tracking Log

Issue Issue Reported Org. Assigned Date Date
No. Description By Impact- To Due Resolved
H-high, Resolution
M-Med.
L-Low

Page 81 of 91
Appendix 4 – Sample Deliverable Acceptance

Form
The University of Colorado
DELIVERABLES ACCEPTANCE: <deliverable name>
Submitted To: Request Log #

From: 000
Date: <date>
SCOPE OF SIGNOFF
<Deliverable name>
This document represents an acceptance agreement for the following deliverables: <deliverable name>.
<Description of deliverable.>
Any questions, concerns, or issues with regard to the submitted deliverable or documentation should be
brought to the attention of the Project Director prior to Deliverables Acceptance.
The undersigned individuals accept the deliverable.
ACCEPTED
<Functional Team> SIS Replacement Project
Signature Signature
Date Date
Functional Team Lead Project Director
REJECTED
<Functional Team>
Signature
Date
Functional Team Lead

Page 82 of 91
If Signoff is rejected, please give specific tasks and descriptions of deficiencies:

Task # Task Name Description of Deficiency
Other Comments:

Page 83 of 91
Appendix 5 – Sample Risk Management Log

The risk management Log provided below is a simple version that requires less maintenance, but that also may not track everything
CU wishes to track. CIBER offers more complex templates for this function.
# RISK PROB. IMPACT POSSIBLE EXPOSURE RISK MITIGATION STRATEGIES ACTION ITEMS RESP DEAD-
(L/M/H) (in weeks) LINE

Page 84 of 91
Appendix 6 – Vendor Evaluation Approaches

Example of a Scripted Demonstration
7.4.1 Application / Document Tracking

An applicant to CU has also applied for financial aid. The applicant has filed the FAFSA
and all documentation required by CU including CU’s Financial Aid Statement (FAS).
The applicant accesses CU’s on-line system to make sure his/her application is being
processed.
7.4.1.1 Demonstrate the ability to track required documents by student classification (e.g.
entering student, returning student, transfer, graduate, etc.) and demonstrate how
comments can be added and retrieved from a student’s record.
7.4.1.2 Demonstrate the ability to track summer session document requirements separate
from academic year document requirements
7.4.2 Packaging
All undergraduate applicants and returning student receive a preliminary financial aid
package. This preliminary financial aid package is based on year in school, EFC,
residency status and other variables. The student has received a Pell, SEOG,
institutional grant, maximum Perkins, and maximum subsidized direct loan.
7.4.2.1 Demonstrate how funding levels for individual federal, state and institutional
funds are entering into the system
The Admissions Office wants to offer Early Decision applicants an estimate of their
financial aid in order to help them make a decision about committing to CU. Each
student requesting an early estimate of financial aid must submit their parents’ tax return
for the previous year, and an FAS. The financial aid counselor reviews this information,
and determines their budget, need, and estimated package, and produces a letter to the
student.
7.4.2.2 Demonstrate the ability to track applicants requiring early estimates separate from
the general applicant pool
7.4.2.3 Demonstrate the ability to utilize estimating tools to determine budget, need and
aid packages.
7.4.2.4 Demonstrate the process the Admissions Office uses to produce a letter with the
relevant student and financial aid data inserted into the letter.

Page 85 of 91
Example Use Case: Register for courses
Billing
System Request Course
Register for Roster Professor
Courses
Student Select Courses to

Teach
Maintain
Professor Info Maintain Course
Info
Maintain Student
Info Registrar
Generate
Catalogue
1.1 Brief Description

This use case is initiated by a student. It provides the capability for the student to create,
delete, modify and/or review a course schedule for a given semester.
2.1 Pre-conditions
None

Page 86 of 91
2.2 Main Flow

This use case begins when the student enters the student id number. The system verifies
that the student id number is valid (E-1) and prompts the student to select the current
semester or a future semester (E-2). The student enters the desired semester. The system
prompts the student to select the desired activity: CREATE, REVIEW, MODIFY,
PRINT, DELETE, or QUIT.
If the activity selected is

CREATE, the A-1: Create a New Schedule subflow is performed.
REVIEW, the A-2: Review a Schedule subflow is performed.
MODIFY, the A-3: Modify a Schedule subflow is performed.
PRINT, the A-4: Print a Schedule subflow is performed .
DELETE, the A-5: Delete a Schedule subflow is performed.
QUIT, the use case ends.
2.3 Alternate Flows

A-1: Create a New Schedule
The system displays a blank schedule screen. The student enters 4 primary course
offering numbers and 2 alternate course offering numbers (E-3). The student then
submits the request for courses. For each primary course selected the system will check
that prerequisites are satisfied (E-4) and add the student to the course offering if the
course offering is open (E-5). The system prints the student schedule (E-6) and sends
billing information to the billing system for processing (E-7). The use case then begins
again.
A-2: Review a Schedule

The system retrieves (E-8) and displays the following information for all course offerings
for which the student is registered: course name, course number, course offering number,
days of the week, time, location, and number of credit hours. When the user indicates
that s/he’s through reviewing, the use case begins again.

Page 87 of 91
Example Fit Gap Result for Schedule of Classes

Fit/
# Topic / Functionality Implement? Description / Comments Solution
Gap
6 Print Class Schedule/Schedule Yes Gap Need to have paper copies to send to Deans and Recommended: Use delivered schedule report as
Worksheets faculty for schedule verification. They make is.
changes on these reports and send back to Office Hours Estimated: None
of Instruction for update in the system.
Alternative 1: Decentralize schedule processing.
<Vendor System> delivers a printed schedule but Allow Schedule of Classes to be reviewed and
it is lacking is a few of the data elements that the updated by individual departments through the
legacy schedule report produces. Does not <Vendor System> web pages.
provide the class description, class start and end Hours Estimated: None
dates for short-term classes or pre-requisite
information. Alternative 2: Design a custom report including
all necessary data elements
Hours Estimated: 20
7 Class Meeting Patterns Yes Fit <Client> may use multiple meeting patterns per
course. <Vendor System> supports this
functionality.
8 Auto enroll Yes Fit This function will automatically enroll students in
a dual-component course (lecture/lab).
9 Security Yes Fit <Client> needs to restrict offering of courses to
approved schools only.
Set up Academic Organization table (which

controls security) by college.
10 Inquiry view for all colleges to all Yes Fit Use Class Search functionality.
classes offered per term.

Page 88 of 91

Project Charter Document

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Charter Document

Uploaded by

Copyright:

Available Formats

University of Colorado

STUDENT INFORMATION SYSTEM

The University of Colorado and CIBER, Inc.

The University of Colorado and CIBER, Inc.

CHANGE HISTORY ....................................................................................................................................................II

The University of Colorado and CIBER, Inc.

The University of Colorado is one of 22 institutions of higher education that implemented a

The University of Colorado and CIBER, Inc.

SIS Replacement Options

The University of Colorado and CIBER, Inc.

Project Definition Process Overview

Project Definition Phase

The University of Colorado and CIBER, Inc.

 Academic departmental administrators (e.g.: daily users of SIS)

The University of Colorado and CIBER, Inc.

Strategic Business Drivers

The University of Colorado and CIBER, Inc.

The University of Colorado and CIBER, Inc.

Principle 3 – Transparent project decision making: CU will establish a decision-making process

Preliminary Project Timeline

The University of Colorado and CIBER, Inc.

 2003-2004: Preliminary research, initial vendor demos

 April-June 2005: Project definition interviews and charter

 October 2005-March 2006: Detailed requirements definition

 Summer-Fall 2006: Project planning phase

 2006 – 2010: Project implementation and roll-out phase

The University of Colorado and CIBER, Inc.

The University of Colorado and CIBER, Inc.

 Workflow and automation tools to enhance productivity

The University of Colorado and CIBER, Inc.

The University of Colorado and CIBER, Inc.

EXAMPLES OF PROJECT RISK POSSIBLE MITIGATION

The University of Colorado and CIBER, Inc.

The University of Colorado and CIBER, Inc.

The University of Colorado and CIBER, Inc.

The University of Colorado and CIBER, Inc.

Detailed Project Objectives

The University of Colorado and CIBER, Inc.

The University of Colorado and CIBER, Inc.

The University of Colorado and CIBER, Inc.

Detailed Project Principles

The University of Colorado and CIBER, Inc.

Principle 2: CU will establish a project governance structure that emphasizes collaboration,

The University of Colorado and CIBER, Inc.

Principle 3: CU will establish a decision-making process that is transparent, clearly documented

The University of Colorado and CIBER, Inc.

The University of Colorado and CIBER, Inc.

Significant External Dependencies

The University of Colorado and CIBER, Inc.

SIS Replacement Project

Project Teams (100% commitment)

Account Admissions Student Academic

The University of Colorado and CIBER, Inc.

Executive Steering Committee

Name Title and location

The University of Colorado and CIBER, Inc.

Governance/Stakeholder Advisory Groups

Policy/Procedure Advisory Group

SISG+ Advisory Group

Campus Project Liaisons

Project Implementation Team

The University of Colorado and CIBER, Inc.

Vendor Implementation Support