Angelo State University
Portico Project
Project Definition Document (PDD)
Prepared By: Brian Braden (ASU)
Implementation Team (ASU)
Patricia Zepeda (SCT)
Version: v 4.0
Create Date: 2003 December 10
Approval Date:
Last Revision Date: 2006 July 15
ASU Project Manager: Brian Braden
SCT Project Manager: Patricia Zepeda
Executive Sponsor: Sharon Meyer
March 13 2007
Project_Definition_Document_PDD_v4.0.doc
Angelo State University
Banner Implementation
Page 1 of 117
Table of Contents
PORTICO PROJECT DEFINITION EXECUTIVE SUMMARY .....................6
EXECUTIVE SUMMARY .............................................................................7
PORTICO PROJECT DEFINITION DETAIL ..............................................14
1
INTRODUCTION ..............................................................................15
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
2
PROJECT SCOPE............................................................................29
2.1
2.2
3
PROJECT VISION ........................................................................................ 16
PROJECT MISSION ...................................................................................... 16
OBJECTIVES .............................................................................................. 16
BENEFITS .................................................................................................. 26
HISTORY AND/OR BACKGROUND .................................................................. 27
FEASIBILITY RECOMMENDATIONS ................................................................. 29
RECOMMENDATIONS FOR A SUCCESSFUL IMPLEMENTATION ........................... 29
RELATED DOCUMENTS................................................................................ 29
EXCLUSIONS .............................................................................................. 30
PLANNED PROCESS IMPROVEMENTS ............................................................ 30
TIMELINE & MILESTONES..............................................................30
3.1
3.2
TIMELINE ................................................................................................... 30
MILESTONES .............................................................................................. 33
4
PROJECT BUDGET .........................................................................35
5
ASSUMPTIONS/DEPENDENCIES ..................................................35
5.1
5.2
6
ASSUMPTIONS............................................................................................ 35
DEPENDENCIES .......................................................................................... 38
5.2.1
Dependent Projects ................................................................. 38
5.2.2
Dependent Products ................................................................ 38
5.2.3
Dependent Resources ............................................................. 38
PROJECT CONSTRAINTS ..............................................................39
6.1
6.2
PROJECT DIMENSION GRID ......................................................................... 39
CONSTRAINT DETAILS ................................................................................. 40
7
RISKS ...............................................................................................40
8
PROJECT ORGANIZATION.............................................................46
8.1
8.2
March 13 2007
PROJECT TEAM .......................................................................................... 46
8.1.1
Qualifications for all Team Members ....................................... 47
8.1.2
Organizational Structure .......................................................... 48
ASU PERSONNEL ....................................................................................... 49
8.2.1
Executive Sponsor................................................................... 49
8.2.2
Steering Committee ................................................................. 49
8.2.3
Project Management Team...................................................... 49
Project_Definition_Document_PDD_v4.0.doc
Angelo State University
Banner Implementation
Page 2 of 117
8.2.4
8.2.5
8.2.6
8.2.7
8.2.8
8.2.9
8.3
9
Contract Administrator ............................................................. 50
Configuration Manager ............................................................ 50
Change Control Board ............................................................. 50
Change Management Team .................................................... 51
Implementation Team .............................................................. 51
Core Process Teams ............................................................... 52
8.2.9.1 Finance Team.......................................................... 52
8.2.9.2 Human Resources Team ......................................... 53
8.2.9.3 Student Team .......................................................... 54
8.2.9.4 Financial Aid Team .................................................. 54
8.2.9.5 Advancement Team................................................. 54
8.2.10
Work Teams ............................................................................ 54
8.2.10.1 Report Strategy Work Team .................................... 54
8.2.10.2 Data Standards........................................................ 54
8.2.10.3 Data Migration ......................................................... 55
8.2.10.4 Security.................................................................... 55
8.2.10.5 Degree Audit/Student Advising Team...................... 55
8.2.10.6 Interface Team......................................................... 55
8.2.11
Technical Team ....................................................................... 55
8.2.12
Luminis Team .......................................................................... 55
SCT PERSONNEL ....................................................................................... 55
PROJECT APPROACH ....................................................................57
9.1
9.2
9.3
9.4
9.5
March 13 2007
DEFINITION ................................................................................................ 57
PLANNING .................................................................................................. 58
IMPLEMENTATION ....................................................................................... 58
9.3.1
Document Current Business Processes .................................. 59
9.3.2
Define Data Standards............................................................. 60
9.3.3
Perform Reporting Analysis and Develop Reporting Strategy . 60
9.3.4
Install Software ........................................................................ 60
9.3.5
Conduct the Systems Education .............................................. 60
9.3.6
Design the Business Solution .................................................. 61
9.3.7
Configure the Business Solution.............................................. 62
9.3.8
Test and Refine the Solution.................................................... 62
9.3.9
Perform System, Integrated and Stress Testing ...................... 63
9.3.10
Execute Data Migration............................................................ 64
9.3.11
Train End Users....................................................................... 65
9.3.12
Deploy the Solution.................................................................. 66
9.3.13
Plan Continuous Improvement................................................. 66
9.3.14
Project Tracking and Control ................................................... 66
CLOSE-OUT ............................................................................................... 67
CONFIGURATION MANAGEMENT ................................................................... 68
9.5.1
Purpose ................................................................................... 68
9.5.2
Objectives ................................................................................ 68
9.5.3
Benefits.................................................................................... 68
9.5.4
Configuration Identification ...................................................... 68
Project_Definition_Document_PDD_v4.0.doc
Angelo State University
Banner Implementation
Page 3 of 117
9.6
9.7
9.8
9.9
9.10
9.11
10
SYSTEM REQUIREMENTS .............................................................91
10.1
10.2
10.3
11
9.5.4.1 General Information ................................................. 68
9.5.4.2 Document Identification Scheme ............................. 69
9.5.4.3 Folder Identification Scheme ................................... 70
9.5.4.4 Branding Scheme .................................................... 70
9.5.4.5 Portico Documentation Library................................. 71
9.5.5
Configuration Management Library.......................................... 72
9.5.6
Record and Manage Change Requests................................... 72
9.5.6.1 Initiate Change Request .......................................... 73
9.5.6.2 Review and Estimate Change Request ................... 74
9.5.6.3 Submit and Approve Change Request..................... 75
9.5.6.4 Track and Report Change Request ......................... 75
9.5.6.5 Control Work Product Changes (Baselining) ........... 75
9.5.6.6 Record and Manage Action Items............................ 75
9.5.6.7 Record and Manage Jeopardy Items ....................... 76
9.5.6.8 Record and Manage Issues ..................................... 76
9.5.6.9 Perform Configuration Management Reporting ....... 77
9.5.7
Configuration Management Team ........................................... 77
CHANGE MANAGEMENT .............................................................................. 77
9.6.1
Introduction .............................................................................. 77
9.6.2
Overview of Change Management .......................................... 78
9.6.2.1 What is change management? ................................ 78
9.6.2.2 A closer look ............................................................ 78
9.6.2.3 Another view ............................................................ 79
9.6.3
Critical Activities for Managing Change ................................... 80
9.6.3.1 Develop Organizational Readiness.......................... 80
9.6.3.2 Manage Communications ........................................ 81
9.6.3.2.1 Communication Plan ............................... 83
9.6.3.2.2 Meetings .................................................. 84
9.6.3.2.3 Communication Channels........................ 84
9.6.3.3 Manage Training...................................................... 85
9.6.3.4 Document Lessons Learned .................................... 85
DOCUMENTATION ....................................................................................... 85
MEASUREMENT .......................................................................................... 86
9.8.1
Defined Metrics........................................................................ 86
9.8.2
Collection and Analysis Methods ............................................. 87
QUALITY ASSURANCE ................................................................................. 87
TRACKING.................................................................................................. 88
RISK MANAGEMENT .................................................................................... 89
9.11.1
Escalation Plan ........................................................................ 91
DATABASE SERVER REQUIREMENTS ............................................................ 92
PC CLIENT REQUIREMENTS ........................................................................ 92
DEVELOPER REQUIREMENTS ....................................................................... 92
PROJECT DELIVERABLES .............................................................93
March 13 2007
Project_Definition_Document_PDD_v4.0.doc
Angelo State University
Banner Implementation
Page 4 of 117
12
PROJECT SUCCESS CRITERIA .....................................................93
13
APPROVAL TO PROCEED..............................................................95
14
DOCUMENT HISTORY ....................................................................95
15
ACRONYMS ...................................................................................100
16
DEFINITIONS .................................................................................100
APPENDIX A: PROJECT PARTICIPANTS FROM ASU ..........................101
March 13 2007
Project_Definition_Document_PDD_v4.0.doc
Angelo State University
Banner Implementation
Page 5 of 117
Portico Project Definition
Executive Summary
March 13 2007
Project_Definition_Document_PDD_v4.0.doc
Angelo State University
Banner Implementation
Page 6 of 117
EXECUTIVE SUMMARY
Introduction
Angelo State University has launched the Portico Project to create an environment in
which all stakeholders have ready-access to the information required for day-by-day
operations, reporting, and decision-making; one that enables the institution to better
communicate with both internal and external constituencies through both universitydirected and self-directed electronic/Internet information and resources, and respond
quickly to needs for change and adaptation. The purpose of this document is to provide
a complete definition of the Portico Project. As with any planning document, the PDD is
a living document and will be updated periodically as the project progresses.
Objectives
The primary objectives of this project are to:
•
•
•
•
•
Provide an information systems environment that enhances the collective
operation of all academic and administrative units.
Redesign existing processes to leverage the improved capability and best
practices and reduce redundant data entry and departmental shadow systems.
Increase significantly the flow of information and access to business operations
across the University.
Enhance access to information to support decision-making.
Increase user autonomy through web-based self-service products.
Scope
ASU has selected SCT’s Banner products to build this environment and will implement
the following:
• Finance and Self Service
• Advancement and Self Service
• Human Resources and Payroll and Self Service
• Student & Self Services for Student and Faculty
• Classroom Management
• Student Scheduling
• Financial Aid
• Student Data Mart
• Workflow
• Luminis Basic (Portal)
March 13 2007
Project_Definition_Document_PDD_v4.0.doc
Angelo State University
Banner Implementation
Page 7 of 117
The Portico Project will include the Texas Connection Consortium (TCC) modifications
for Student, Finance, and Human Resources. Only under exceptional circumstances
will any other significant customizations be made.
Benefits
The key benefits to the University in achieving the above objectives include:
• Improve recruitment and retention of qualified students by standardizing
processes and improving access to information.
• Increase efficiency and effectiveness of business processes which will enable
ASU to achieve the business objectives and reduce operating costs.
• Improve access to information for students, alumni, faculty, and staff by providing
self service tools that increase efficiency of communications and tailors
information for each individual’s specific needs.
• Improve alumni participation and increase private financial support for University
related activities and programs.
Budget
The project budget is provided in a separate document. The Executive Sponsor will
monitor the project budget and provide reports on the status of the budget through
established channels.
Timeline
The following timeline illustrates at a high level the various dates that each major
Banner product will be deployed and completed over the next 3 years.
The date a new system replaces its legacy counterpart is the “deployed” date. In some
instances, a functional system (e.g., Finance) may have components that are deployed
in phases throughout the year. A functional system is not considered “completed” until it
has gone through one business or academic cycle. The various “deployed” and
“completed” dates are shown on the following diagram.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc
Angelo State University
Banner Implementation
Page 8 of 117
Portico Project Timeline
Feb
Jan
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
2007
Mar
Feb
Jan
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
2006
Mar
Feb
Jan
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
2005
Mar
Dec
Jan
Feb
2004
Negotiate & sign contract (Dec ’03)
Project Organization & Planning (Sept ’04)
Phase I Finance Deployed - COA/AP (Sept ’04)
Finance Self Service Deployed (Feb ’06)
Finance Completed (Mar ’06)
Phase I Human Resources Deployed - HR/Payroll (Dec ’04)
HR Self Service Deployed (Feb ‘06)
Human Resources Completed (Mar ’06)
Advancement Deployed (Aug ’05)
Advance Self Service Deployed (July ’06)
Advancement Completed (Aug ’06)
Student Deployed (Oct ’06)
Student Completed (Dec ’06)
Fin. Aid Deployed (May ’06)
Financial Aid Completed (Dec ’06)
Luminis Installation and Test Phase (Dec ’04)
Luminis in Pilot Phase (May ‘05)
Luminis with HR and Finance Self Service (June ’05)
Luminis General Rollout (Aug ’05)
Luminis Phase II Deployed (Dec ‘06)
Project Completed (Jan ‘07)
March 13 2007
Project_Definition_Document_PDD_v4.0.doc
Angelo State University
Banner Implementation
Page 9 of 117
Assumptions
The key assumptions for this project are:
• ASU senior management is supportive and committed to the project and to the
business process redesign necessary to achieve its stated objectives.
• Necessary resources (e.g., budget, facilities, people, and supplies) will be
identified and provided to ensure project success.
• Dedicated staff on the project will have appropriate backfill and/or release time
during the project.
• ASU will adopt best practices as defined by Banner and TCC.
• There is no intention to reduce the current number of employees; however,
operational efficiencies and changes to job functions are expected.
• The project will take priority over other job responsibilities for the project staff and
the established schedule will be strictly adhered to (excluding emergencies).
• The Portico implementation will take priority over other projects that might impact
the project schedule and resources.
• Current legacy systems will remain in place and be supported for the entire
length of the appropriate phase of the project. Mandatory changes, regulatory
changes, routine maintenance, and troubleshooting will continue; however,
ongoing development efforts of the legacy systems will be minimized.
• ASU will modify current business processes to adopt standard functionality and
processes defined and supported by Banner.
• Issue resolution will occur in a timely manner in order to achieve the project
timeline within project budget.
• Training will be provided for all departments and programs in a manner
appropriate to job responsibilities. Separate training facilities will be made
available during the life of the project.
Risks
Throughout the project, the project staff will identify and respond to risks to the project
with respect to the environment, user expectations, competing projects, project
assumptions, resources, or any other relevant matter. Examples of risk include potential
loss of a critical resource, technology changes, regulatory changes, dependence on a
third party, scope changes, project sponsorship or management changes, and legal
issues. Approaches to responding to risks include:
Retention
Deflection
Preventive
Contingent
Avoidance
March 13 2007
the risk is acceptable; retain it and accept the
consequences
transfer the risk to another party
take action in advance of the risk event to reduce its
likelihood or its impact
specify action that will be taken in response to a risk
event, to mitigate its consequences
the risk is rejected; do nothing
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 10 of 117
Organization
The organizational structure of the project is depicted in the diagram below and
identifies ASU personnel that will be involved with the project.
Not shown are SCT
personnel who will assist with the project. Other ASU staff will be involved as the
project moves through its different phases.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 11 of 117
Project governance will be provided by the Steering Committee. The Implementation
Team is composed of the Project Management Team and the Team Leads for each of
the Core Process Teams and will oversee and expedite the implementation of all
systems. Work Teams are established as needed to perform specific activities for the
project and are frequently cross functional. The Change Management Team is
responsible for developing strategies for change for the University by formulating
communication, training, and organizational readiness plans.
Approach
For the project management approach, SCT's Common Service Methodology (CSM) will
be followed, as depicted below:
DEFINITION
PLANNING
IMPLEMENTATION
CLOSEOUT
During the Project Definition Phase, Angelo State University and SCT will meet to
review the documents generated throughout the sales cycle, agree on the approach to
deliver the services contracted and the work products to be completed, and discuss the
recommended project organization, approach and resources needed for the project.
During the planning phase the SCT Project Manager in conjunction with the Angelo
State University Project Manager will be responsible for:
• Completing the Project Definition Document.
• Completing the Configuration Management Plan.
• Completing the Organizational Readiness Plan and Change Management Plan.
• Completing the Quality Assurance Plan.
• Defining Business Process Analysis Requirements.
• Defining Data Migration Needs and develop the Data Migration Plan.
• Developing a Testing Plan.
• Determining hardware and software installation needs.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 12 of 117
Project Deliverables
Several procedures, tools, and techniques will be used to ensure that the project
deliverables are completed on time and within budget and that they meet or exceed the
expected standards of quality. Plans will be developed, executed, and assessed for
configuration management, change management, organizational readiness,
documentation, tracking and measurement, quality assurance and risk management.
The following is a list of selected key deliverables:
Item
Project Definition Plan
Project Schedule
Communication Plan
Business Practice Analysis Documents
System Education Plan
Banner Training Materials
End User Training Materials
Computer Operations Manual
Documentation Plan
Conversion Guides
Data Migration Plan
Disaster Recovery Plan
Quality Assurance Plan
Report Strategy Plan
Security Plan
Test Plan
Verification Plan
Responsibility of
SCT/ASU
SCT/ASU
ASU
ASU
SCT/ASU
SCT
ASU
ASU
ASU
SCT/ASU
SCT/ASU
ASU
SCT
ASU
ASU
SCT/ASU
ASU
Success Criteria
The project is considered successfully complete when the project objectives have been
met. Criteria include:
• All issues and action items have been completed and signed off.
• All required work products have been produced.
• Any deficiencies have been logged and signed off.
• Verification that the project has met ASU standards.
• Validation that the product meets the requirements.
• Successfully completed functional and physical configuration audits.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 13 of 117
Portico Project Definition
Detail
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 14 of 117
1
Introduction
The purpose of this document is to provide a complete definition of the Portico
Project. The Planning Definition Document (PDD) is one of several
documents that form the project’s plans, as shown in the diagram below. As
with any planning document, the PDD is a living document and will be
updated periodically as the project progresses.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 15 of 117
1.1
Project Vision
ASU envisions an environment in which all stakeholders have ready-access to
the information required for day-by-day operations, reporting, and decisionmaking; one that enables the institution to better communicate with both
internal and external constituencies through both university-directed and selfdirected electronic/Internet information and resources, and respond quickly to
needs for change and adaptation.
1.2
Project Mission
The mission of the ASU Portico Project is to replace the legacy financial,
human resource, student, development and alumni systems with an
integrated software vendor application, and implement a portal system that
serves the individual and collective informational needs of the university’s
constituencies.
1.3
Objectives
The success of the project is measured against the attainment of the project
objectives. As such, they must be measurable and have associated project
success criteria (see Section 11 Project Deliverables). The project must also
meet ASU business goals.
The driving forces behind the project are to:
Institutional Objectives:
1. Provide an information systems environment that enhances the
collective operation of all academic and administrative units.
Measurement of Success:
• Complete implementation of Banner Finance and Self Service by
March 2006.
• Complete implementation of Banner Advancement and
Advancement Self Service by July 2006.
• Complete implementation of Banner Human Resources, Payroll
and Employee Self Services by March 2006.
• Complete implementation of Banner Student, Student Self Service
and Faculty Self Service by December 2006.
• Complete implementation of Banner Financial Aid by December
2006.
• Complete implementation of the Luminis portal which will integrate
into all core Banner systems by December 2006.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 16 of 117
2. By December 2006, increase significantly the flow of information and
access to business operations across the University.
Measurement of Success:
• Provide departments with the ability to enter and process business
transactions and directly access financial, purchasing, budgeting,
human resources, and student data.
3.Enhance access to information to support decision-making.
Measurement of Success:
• Deploy Finance Self Service by February 2006.
4. By December 2006, increase user autonomy through web-based selfservice products (Business to Business, Finance, HR, Alumni, Student
self-service and decentralized transaction processing).
Measurement of Success:
• Allow departments to request personnel changes on-line.
• Provide individual employees access to a variety of self-service
capabilities via a web-enabled system.
• Allow departmental processes to be developed for entry of
appropriate information that updates financial & budget information
automatically.
• Allow on-line, real time budget, account balance and encumbrance
information to authorized users.
5. By December 2006, improve compliance across the University.
Measurement of Success:
• Implement consistent definitions across functional systems.
6. By December 2006, redesign existing processes to leverage the
improved capability and best practices and reduce redundant data
entry and departmental shadow systems.
Measurement of Success:
• Minimize the need for maintaining local and departmental systems
that are now used to supplement University systems.
• Provide a single system of record for each data element within the
institution.
• Integration of the core Human Resources/Payroll, Finance, Student,
Financial Aid, and Advancement systems will reduce redundant
data entry.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 17 of 117
7. By December 2006, develop a campus wide reporting strategy that will
accommodate the different needs of the users on campus.
Measurement of Success:
• A campus wide reporting tool will be selected and deployed.
• Power users and end users will be trained on how to develop
reports.
• A strategy will be defined in terms of what is “centralized” and what
is considered “ad-hoc” reporting.
• Processes for developing and disseminating campus wide reports
will be established.
Functional Objectives
Finance
1. The new Banner system will enhance current functionality of the
Finance business environment.
Measurement of Success:
• By June 2005, provide Web-based drill-down for queries.
• By September 2005, design and deliver training programs to
educate every level of user with the initial training focused toward
employees within the Finance area.
• By June 2005, reduce the number of “self service” type phone calls.
2. By December 2004, define standard reports that would be useful for
end users (departments), functional users (Finance and HR/Payroll
operating departments) and power users (Controllers, Directors, VP)
Measurement of Success:
• Comprehensive and simple reports.
• Authorized users are able to run ad-hoc reports as needed.
• Decision-makers have the ability to create analyses and projections
of Finance/Payroll/HR data.
3. Use best practices embedded in the Banner suite and, considering
users needs, reduce paper transaction wherever possible.
Human Resources
1. By February 2006, reduce turnaround time required for transaction
processing:
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 18 of 117
Measurement of Success:
• Reduce the number of approvals.
• Push decision-making to the lowest level.
2. By June 2005, gain improved reporting capabilities.
Measurement of Success:
• Provide individual online review of employment and payroll history.
• Provide online departmental access to personnel accruals and
balance.
• Improved interaction with the State of Texas HRIS.
3. Reduce data entry of time, labor, and other employee related
information by HR/Payroll Personnel.
Measurement of Success:
• By November 2005, implement Self Service for employees,
including biographical information and time entry.
Advancement
1. By July 2006, increase alumni involvement in the University.
Measurement of Success:
• Access to accurate and timely information on alumni, donors and
prospective donors.
• Easy to use end user reporting for research of potential
donors/alumni and varying segmentations through standardized
and ad hoc reports.
• Provide alumni online access to the University by July 2006.
2. By July 2006, create effective and efficient workflow for all fundraising
efforts by the University and private support organizations.
Measurement of Success:
• Utilize electronic workflow to coordinate fundraising efforts of the
University, ASU Foundation, ASU Alumni Association, ASU Ram
Club, Friends of the Library, and Friends of Art and Music.
• Merge letters and other correspondence directly from database
reports.
• Make online giving option available to donors.
3. By June 2006, improve stewardship of donors.
Measurement of Success:
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 19 of 117
•
•
•
Processes are in place with to insure that donor restrictions on
scholars’ awards are met.
Easy to use reports insure that proper acknowledgement and
reporting to donors.
Easy to use reports to create giving reports for donor recognition.
Student
1. Enhance current functionality and increase flexibility for the various
offices (i.e. Registrar, Graduate Admissions, and Undergraduate
Admissions) that deliver student related services.
Measurement of success:
• By November 2005, provide the transfer office a fool-proof method
of receiving all transcripts that need to be evaluated.
• Continued tracking of applications and missing document materials
- Ability to verify application status and missing document materials
by November 2005.
• Continued
registration
functionality
Ability
to
use
permits/authorizations for registering students by April 2006.
• Maintain or improve current level of ease for students to register
and look at course history - Ability of students to use self-service to
look at registration schedule and course history by April 2006.
• Increase audit capabilities in effect by April of 2006 to allow tracking
of changes to fields.
• By May 2006, classes can be set up between semesters without
causing errors in State reports that require manual edits.
• Maintain or improve current level of ease for students to check
application status - Ability of students to use self service to look at
status by November 2005.
• Provide immediate on-request official transcripts containing all
State-mandated information and have EDI capabilities by
September of 2006.
• Maintain or improve current level of ease for students to check
grades - Ability of students to use self-service to look at grades by
October 2006.
• Maintain or improve current level of ease for students to change
personal information on-line - Ability of students to use self-service
to change personal info by April 2006.
• Maintain or improve ease of checking a student out for graduation Ability to audit a student's file to see course requirements not yet
met, courses completed, courses registered for, completed courses
that apply or do not apply to the student's degree plan by December
2006.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 20 of 117
•
•
•
•
•
Seamless transition to Banner Web products with enhancements
for workflow that allow registration for Fall 2006 Semester.
Simplify advising hold process by registration for Fall 2006
Semester.
Tracking of theses - Ability to input thesis information into Banner
by June 2006.
Simplify processes for change of major, matriculations, and
academic actions by December of 2006.
Minimize use of paper forms by utilizing workflow capabilities by
December 2006.
2. Provide faculty access to more timely information for advising students.
Measurement of success:
• A degree audit system with improved readability and functionality
will be fully operational by December 2006.
3. Gain improved reporting capabilities and provide a mechanism for adhoc reporting for non-technical users that does not require the
assistance of Information Technology.
Measurement of success:
• Ability to provide departments with automated weekly applicant
reports by January 2006.
• Ability to provide Friday Report recipients with automated weekly
Friday Report reports by January 2006.
• Ability to provide departments with automated weekly enrolled
applicant reports by June 2006.
• Ability to provide the Graduate School with internal automated
Prospect/Applicant/Accepted/Enrolled reports by June 2006.
• Easy-to-use end user reporting will be available by August of 2006.
• By November 2006, provide up-to-the-minute information
concerning prospects, events, evaluation of transfer work,
international students, and applicants, as well as all other current
reports available.
• Reports and faculty workload reports require fewer manual
adjustments by May 2006.
• CBM reporting is accurate with minimal or no manual intervention
by October 2006.
4. Improve communications between student related departments, other
departments on campus, faculty, the current student population, and
prospective students.
Measurement of success:
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 21 of 117
•
•
•
•
•
•
Streamline the data entry portion of the undergraduate application
process with quick flow and create a work flow to move within the
"Admissions" area to Transfer and TSI Compliance areas by Nov
2005.
Implementation of the following Graduate Admissions quick flows
by January 2006: Application data entry flow, Prospect data entry
flow, and Acceptance application flow.
Provide a means to communicate with students and faculty via
Luminis by May of 2006.
Implementation of the following, Graduate Admissions quick task
process flows by June 2006: Degree checkout flow, Registration
problem process flow, Thesis flow, and Registration Authorization
flow.
Implement workflow by August of 2006 to allow automatic
notifications of faculty for permit requests and withdrawals.
Implement work flow for Graduate applicant departmental approval
process by December 2006.
5. Automate and streamline prospect and application processes into one
system.
Measurement of success:
• Integrate data from Recruitment Plus and SIS to have all
undergraduate and graduate prospective students and applicants in
Banner by August 2006.
• Application/recruitment letter generation up and running by August
2006.
• Provide ability through the communication flow to track letters sent
to prospects and students that have applied for admissions by
November 2005.
• All on-line Graduate Applications and Requests for Information
downloaded directly into Banner by February 2006.
6. Provide the ability to load applications received via the Texas Common
Application electronically into Banner.
Measurement of success:
• Eliminate the need of data entry of the Texas Common Applications
by November 2005.
7. Accept credit card payments.
Measurement of success:
• By March 2006, provide the ability for students to pay the
application fee by credit card method.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 22 of 117
8. Provide an efficient load of ACT/SAT and THEA scores and search
loads electronically.
Measurement of Success:
• By November 2005, provide the ability to enter scores into one
system.
9. Create, track and evaluate travel for Admissions Counselors and
Recruiting Team.
Measurement of Success:
• By November 2006, provide access to Admissions Counselors,
Dean of Enrollment Management, and the ASU community.
10. Improve planning and tracking of for College Days, Discover, Preview
ASU, Grad School & You, GRE Workshop, and Grad School Banquet.
Measurement of Success:
• By December 2006, have the ability to extract data to determine the
effectiveness of the program and provide the opportunity to
correspond with students from the initial invitation, to registration, to
the evaluation process.
11. Provide an efficient method to facilitate International student tracking.
Measurement of Success:
• By November 2005, create a best practice for international student
tracking.
12. Provide efficient and effective means of tracking and reporting students
for the Texas Success Initiative (TSI) and eliminate manual tracking.
Measurement of Success:
• By November 2006, set up procedures within Banner to prevent
students from registering for the wrong courses or not registering
for the correct courses based on test scores on file .
13. Determine the feasibility of selecting and integrating a third party
housing system.
Measurement of Success:
• By May 2006, identify and document all housing requirement
criteria for a new system.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 23 of 117
•
By December 2006, have the ability for end users to create ad-hoc
reports.
14. By August 2006, integrate housing central office and hall administration
processes.
Measurement of Success:
• Provide the ability to view rosters, occupancy reports, etc. on-line in
real time by multiple staff members at the same time.
15. By December 2006, deploy a web-based Student self service
component that supports housing.
Measurement of Success:
• Allow students to apply and submit deposits, choose roommates,
request on line information, perform "what if" scenarios, and check
waiting list status on-line.
Financial Aid
1. Better serve students and eliminate unnecessary manual processes in
the Financial Aid Office.
Measurement of Success:
• By May 2006, have the ability to electronically award financial aid to
new and recurring students.
• By May 2006, eliminate the majority of manual processes, such as
academic progress monitoring and streamline awarding process.
• By May 2006, communicate eligibility, program rules and
requirements to students.
2. Implement efficient and accurate reporting to external entities without
manual reconciliation with Finance, HR and Student records.
Measurement of Success:
• By October 2006, extract data from ASU system that reflects with
100% accuracy records and funds received.
• By October 2006, interface with outstanding systems to prevent
double data entry.
Luminis Portal
1. By May 2006, improve productivity throughout the university and the
ASU community.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 24 of 117
Measurement of Success
• Access from anywhere through a secure connection.
• Real-time synchronization of Banner systems.
• Single sign-on to other services (Library, e-mail, etc)
2. By May 2006, strengthen and personalize the university’s brand.
Measurement of Success
• Customization by each school, department, and institution for its
own unique environment.
• Graphic continuity with the external website
• Maintain compliancy with web standards.
3. By May 2006, extend the value of current technology and system
investments.
Measurement of Success
• Well-defined Portal content/channel configuration plan.
• Secure access to enterprise administrative and academic
applications.
• Authentication of Luminis portal login through ASU directory.
4. By December 2006, improve communication throughout the university
and the ASU community.
Measurement of Success
• Well-defined cross-university involvement in the definition of the
project services.
• Targeted announcements, campus news and external news
providers.
• Improved student recruitment
5. By December 2006, foster university community and enduring
relationships.
Measurement of Success
• Personalized and customized user interface.
• Automated provisioning of e-mail accounts for users.
• Consolidated calendar and community tools.
• Increased contact with prospective students, alumni and donors.
6. By December 2006, improve resources available to faculty for
instructional applications.
Measurement of Success
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 25 of 117
•
•
•
Successful integration of classroom management software such as
Blackboard into Luminis.
Adoption of Luminis as the primary communication tool between
faculty and students for out-of-classroom needs.
Successful integration of university support services (library, IT
Help Desk)
7. By December 2006, improve Student Services.
Measurement of Success
• Expanded capabilities for students to handle various financial
transactions on-line.
• Adoption of Luminis as the primary communication tool among
student organizations.
• Provide easier and faster procedures for students to secure needed
services.
• Improve notification to students regarding deadlines.
• Successful integration of university support services (library, IT
Help Desk, etc.)
8. By December 2006, improve staff services.
Measurement of Success
• Expanded capabilities for staff to handle various business
processes.
• Adoption of Luminis as the primary communication tool among
university units.
• Improve notification to staff regarding deadlines.
• Successful integration of university support services (library, IT
Help Desk, etc.)
1.4
Benefits
The value to the University in achieving the above business objectives
includes:
• Standardize data and improve access to common timely
information to facilitate decision making, leading to improved
recruitment and retention of qualified students.
• Improve ASU’s image from a student perspective.
• Enhance processes from a student point of view.
• Increase efficiency in communication with students.
• Provide 24 hour by 7 days a week access to information for all end
users.
• Provide a personalized portal for students.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 26 of 117
•
•
•
•
•
•
1.5
Increase satisfaction of the ASU community.
Increase capacity to recruit and retain quality employees.
Increase private financial support and alumni participation in the
University.
Take advantage of the features of current and future technology
and improve ASU’s technology image.
Increase efficiency and effectiveness of business processes which
will enable ASU to achieve the business objectives and reduce
operating costs.
Reduce mailing costs through an increase in web-based self
services.
History and/or Background
The following section gives basic background information about the current
administrative systems (i.e. Human Resources, Finance, Student, Financial
Aid, and Advancement) at Angelo State University. This section also identifies
the reasons for considering a new integrated system and the process for
selecting a new software application suite for the campus.
ASU’s current administrative systems are between 15 and 20 years old with
most of them close to the end of their life cycle. The software vendors who
support these applications have indicated that they will be phasing out the
support for ASU’s current versions in the next few years. The complexity of
transitioning to a new system requires a lot of detailed planning and a fairly
long implementation life cycle (i.e., years).
Angelo State University purchased its first administrative system (HR/Payroll)
in 1984 followed by the purchase of a Student system in 1988 and a Finance
system in 1989. At the time of purchase, these systems were considered to
be 'Best of Breed' for their particular functional area, meaning that ASU had
the best Finance system, the best Human Resource system, and the best
Student system. The benefit of this approach was that each application
functioned very well for its core users. The primary drawback was that each
system had no way of talking to the other system. Data was not synchronized
automatically between systems but had to be processed during “off hours”
which impacted the availability of services to students, faculty, and staff.
The current systems run on various IBM mainframe platforms utilizing VM and
VSE operating systems. Their independent nature requires them to operate
in separate environments using their own VSAM files to store data. These
“separate systems” resulted in duplicate data entry and inconsistent data. For
example, an individual employed at the University and also a student might
have one personal address listed in the Human Resource system and another
personal address in the Student system.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 27 of 117
As time went on, these 'legacy' systems were enhanced to allow for telephone
registration (1994), web registration (1999), and faculty advising/grading
(2002). Processes were also developed to allow for departments to print
many of their reports on their own office printers instead of going to the data
center to pick them up. Even with these continual enhancements, these
systems were “pushed” beyond their designed capabilities.
Newer generation technologies incorporating “web technologies” with a
centralized data repository provide more flexibility and efficiency for
universities and their daily operations. These new technologies, which have
become the new “standard,” also allow universities the ability to deliver new
services that are available 24 hours a day, 7 days a week.
In 2001, Angelo State University began the process of investigating a new
administrative system. This comprehensive investigation involved a variety of
research venues that included analyzing industry trends, best practices, and
visits to other universities. The industry term for the suite of administrative
systems is ERP which stands for Enterprise Resource Planning. The
definition of ERP describes how an organization should view its administrative
systems at an enterprise level instead of individually.
To understand the process for deploying a new ERP system, ASU researched
in detail the various factors that caused an ERP project to succeed or to fail.
From these lessons learned, ASU adopted a set of "best practices" to be
followed to ensure success of the ASU ERP project.
In 2002, the University decided to purchase the Oracle database as a first
step in preparing for the new ERP system since all the market leaders within
the ERP segment used Oracle database as their foundation.
A software assessment task force was created in 2003 to evaluate available
ERP systems to determine the best fit for Angelo State University. Based on
Gartner information, visits with other universities, and vendor demonstrations,
ASU decided that only two vendors met ASU's requirements, SCT and
Oracle. The task force conducted further research by visiting universities that
were involved in an SCT or Oracle implementation.
Part of the software selection process also included bringing the vendors on
campus to present product demos to a variety of functional and end users.
These demo visits provided valuable information to the task force to assist
them in making their decision.
As a result of the investigation, SCT's Banner and Luminis software were
selected in November of 2003 as ASU’s new ERP system. ASU’s ERP
project, which officially “kicked off” in December of 2003, has been named the
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 28 of 117
Portico project which means “gateway” or “entrance”. Think of the Portico
project as “ASU’s Gateway to the Future”.
The Portico project is estimated to take 3 to 5 years and include the
implementation of the following systems: Finance, Human Resources,
Advancement, Student, Financial Aid, and the Luminis portal.
SCT's Banner and Luminis systems will bring new opportunities for
streamlining existing business processes, forming new business processes,
and offering new services not previously available to the ASU community.
1.6
Feasibility Recommendations
After carefully reviewing the project documents that have been generated
during the selection and sales/purchase cycle, the feasibility of this project is
one that is obtainable; and while there are risks, they are manageable. It is
recommended, therefore, to proceed with the project as planned.
1.7
Recommendations for a Successful Implementation
The following should happen to make a successful implementation possible:
• A total commitment of resources.
• Facilitate acceptable levels of "buy in" through appropriate training.
• Maintain current level of services during implementation.
• Manage resources for adequate backfill and temporary staffing.
• Manage and control "scope creep".
• The project teams as well as affected departments have made a
commitment to the success of this project. There is also total
commitment from top management.
• In view of the internal reorganization now underway at the
University, opportunities for effective integration of processes
should be explored and implemented as appropriate.
• An effective communication plan to the ASU community on the
purpose, scope, and timeline as well as periodic updates on project
progress will be utilized.
1.8
Related Documents
See Section 9.8 – Documentation.
2
Project Scope
By January 2007, ASU will implement Banner Finance and Self Service,
Banner Advancement and Self Service, Banner Human Resources and
Payroll and Self Service, Banner Student & Self Services for Student and
Faculty, Classroom Management, Student Scheduling, Banner Financial Aid,
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 29 of 117
SCT Workflow, Luminis Basic, and SCT Student Datamart, as well as TCC
Modifications for Student, Finance, and Human Resources.
SCT will deliver training and implementation support services, additional
miscellaneous consulting services, and project management services for the
above components.
Angelo State University understands and agrees to the benefits of minimal (if
any) customizations. This is a key assumption to meeting the aggressive
timetable identified later in this document.
Only under exceptional
circumstances and with approval of the Steering Committee will any
significant customization be done.
2.1
Exclusions
•
2.2
There are no exclusions identified at this time.
Planned Process Improvements
All current and future business process will be documented and reviewed.
The Implementation Teams will be focused on outcomes rather than current
inputs or existing processes. The goal will be to implement the “Best
Practices” contained in Banner without modification. ASU will adjust business
processes as reasonably required to conform to best practices of SCT
Banner. Any exceptions will require the approval of the Project Manager and
the Steering Committee. Once a process is defined and documented within
Banner, each respective Vice President needs to signoff on the new business
processes within their area.
The term “Best Practices” refers to the processes that are built into the SCT
Banner software. By selecting the SCT Banner software system we are
adopting these “Best Practice” processes to replace our existing processes.
Although some changes to the SCT Banner process may be required in
unique circumstances, failure to limit these changes could impact the overall
success of the project. .
3
Timeline & Milestones
3.1
Timeline
The following timeline illustrates at a high level the various dates that each
Banner product will be deployed and completed over the next 3 years. A brief
discussion is in order to explain the difference between a “deployed” date and
a “completed” date.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 30 of 117
The day a new system replaces its legacy counterpart is the “deployed” date.
In some instances, a functional system (e.g., Finance) may have components
that are being deployed in phases throughout the year. A functional system is
not considered “complete” until after it has gone through one business or
academic cycle. The various deployed and completed dates are shown in the
following timeline diagram.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 31 of 117
Portico Project Timeline
Feb
Jan
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
2007
Mar
Feb
Jan
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
2006
Mar
Feb
Jan
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
2005
Mar
Dec
Jan
Feb
2004
Negotiate & sign contract (Dec ’03)
Project Organization & Planning (Sept ’04)
Phase I Finance Deployed - COA/AP (Sept ’04)
Finance Self Service Deployed (Feb ’06)
Finance Completed (Mar ’06)
Phase I Human Resources Deployed - HR/Payroll (Dec ’04)
HR Self Service Deployed (Feb ‘06)
Human Resources Completed (Mar ’06)
Advancement Deployed (Aug ’05)
Advance Self Service Deployed (July ’06)
Advancement Completed (Aug ’06)
Student Deployed (Oct ’06)
Student Completed (Dec ’06)
Fin. Aid Deployed (May ’06)
Financial Aid Completed (Dec ’06)
Luminis Installation and Test Phase (Dec ’04)
Luminis in Pilot Phase (May ‘05)
Luminis with HR and Finance Self Service (June ’05)
Luminis General Rollout (Aug ’05)
Luminis Phase II Deployed (Dec ‘06)
Project Completed (Jan ‘07)
March 13 2007
Project_Definition_Document_PDD_v4.0.doc
Angelo State University
Banner Implementation
Page 32 of 117
3.2
Milestones
The following Major Milestones are outlined for each module.
Portico Project
Project Started
Banner & Oracle Installed
Approve Prioritized Service Requirement Document
Data Standards Document Baselined
Project Schedule Completed
QA Plan Completed
Project Definition Approved
QA Assessment for Planning Phase Completed
Finance Module
Finance TCC Beta Test Started
Finance TCC Modifications Completed
Banner Finance Deployed
General Ledger
Accounts Payable
Purchasing
Non-Student AR
Budget Development
Self Service Budget Queries
Self Service Budget Development
Banner Finance Implementation Completed
Human Resources Module
HR TCC Modifications Beta Test Started
HR TCC Modifications Completed
Banner Human Resources Deployed
Human Resources
Payroll
Applicant Tracking
Self Service Employee Look-up
Banner Human Resources Implementation Completed
Advancement Module
Banner Advancement Deployed
Constituent & Organization
Designation, Campaign, Pledge
Gifts
Prospect Management
Solicitor Organization & Membership
Self Services
Banner Advancement Implementation Completed
March 13 2007
Project_Definition_Document_PDD_v4.0.doc
Angelo State University
Implementation Banner
Date
12/01/03
01/30/04
02/10/04
03/02/04
03/09/04
03/09/04
03/09/04
03/26/04
07/01/04
09/01/04
Sept. 2004
09/13/04
09/13/04
09/13/04
09/13/04
02/01/05
06/01/05
02/01/06
Mar. 2006
10/01/04
12/10/04
Dec 2004
12/10/04
12/10/04
05/01/05
06/01/05
Mar. 2006
Aug. 2005
08/22/05
08/22/05
08/22/05
08/22/05
08/22/05
07/10/06
July 2006
Page 33 of 117
Portico Project
Financial Aid Module
General Student First Load Complete
New Applicant Tracking
Tracking Documents
Start Loading Records for 06-07 Year
Needs Analysis
Conversion of Loan History Data
Award History
Packaging
Award Letters
Loan Processing
Academic Progress
Authorizing
Disbursing
COD Updates
Student Employment
Student Module
Banner Student Deployed
General Person Information Complete
Graduate Recruitment Go-Live
Transfer Articulation Complete
Catalog Complete
Building & Rooms Complete
Faculty Load Complete (Demographic Information for
Schedule)
Accounts Receivable (Course Fee and Financial Aid
Detail Codes) Complete
General Student First Load Complete
Schedule Complete
TSI New Student Go-Live
Housing Applications
TSI Current Student Go-Live
Registration Go-Live
Student Self Service Go-Live
Conversion & Validated Academic History Through Fall
2005 Complete
Faculty Self-Service Go-Live – Look up of Students and
Courses
General Person Second Load Complete
General Student Second Load Complete
Conversion & Validated Academic History For Spring
Remaining Accounts Receivable Complete
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Date
01/02/06
01/15/06
01/15/06
01/15/06
03/01/06
03/01/06
04/01/06
05/28/06
05/28/06
05/28/06
06/01/06
08/01/06
08/18/06
09/01/06
09/01/06
Oct 2005
10/03/05
10/03/05
12/15/05
12/15/05
12/15/05
12/15/05
12/15/05
01//02/06
02/15/06
02/28/06
03/27/06
03/31/06
04/03/06
04/03/06
04/03/06
04/03/06
06/01/06
06/01/06
06/15/06
08/07/06
Page 34 of 117
Portico Project
Undergraduate Recruitment Go-Live
General Person Third Load Complete
General Student Third Load Complete
Student Recruiting/Admissions Self-Service Go-Live
Advising (CAPP) – New Students
Conversion & Validated Academic History For Summer
2006 Complete
Transcripts
Faculty Load Calculations Complete
Fall ‘06 CBM Due
Fall ’06 End of Term Processing
Faculty Self-Service Go-Live – Grading Fall 2006 Term
Degree Audit (CAPP)
Student Implementation Complete
Workflow Implementation Complete
Luminis Portal Module
Luminis Installation
Luminis Test Phase
Luminis Pilot Phase
Human Resources and Self Service Integration into Luminis
Finance and Self Service Integration into Luminis
Luminis General Rollout to Faculty, Students, and Employees
Advancement and Self Service Integration into Luminis
Luminis Rollout to Alumni
Financial Aid and Self Service Integration into Luminis
Course Studio Deployment
Student and Self Service Integration into Luminis
Luminis Implementation Phase II Complete
Project Ended
4
Date
08/15/06
08/25/06
08/25/06
08/31/06
09/01/06
09/15/06
09/15/06
09/15/06
10/01/06
10/01/06
10/01/06
TBD after
training
Dec 2006
TBD
07/01/04
12/01/04
05/01/05
06/01/05
06/01/05
08/01/05
12/01/05
12/15/05
01/01/06
01/01/06
05/01/06
12/31/06
01/01/07
Project Budget
An overall project budget is provided in a separate document. ASU’s
Executive Sponsor will monitor the project budget and provide reports on the
status of the budget through established channels. Billing questions related to
SCT invoices will be communicated to the SCT Account Manager for
response.
5
Assumptions/Dependencies
5.1
Assumptions
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 35 of 117
Resources
• Dedicated staff on the project will have appropriate backfill and/or
release time during the project.
• There is no spirit, budget, or intention to reduce the current number
of employees; however, operational efficiencies and changes to job
functions are expected.
• Necessary resources (e.g., budget, facilities, people, and supplies)
will be identified and provided to ensure project success.
Priority
•
•
The Portico implementation will take priority over other job
responsibilities for the Project Team and the established schedule
will be strictly adhered to (excluding emergencies).
The Portico implementation will take priority over other projects that
might impact the project schedule and resources.
Legacy Systems
• Current legacy systems will remain in place and be supported for
the entire length of the appropriate phase of the project. Mandatory
changes, regulatory changes, routine maintenance, and
troubleshooting will continue; however, development efforts (e.g.,
new ad hoc report formats) of the legacy systems will be minimized.
• Clean up of legacy data will be completed before conversion of data
into Banner. Appropriate resources will be allocated and prioritized.
Governance:
• ASU senior management is supportive and committed to
deployment and implementation of Banner and Luminis and to the
business process redesign necessary to achieve its stated
objectives.
• Project scope will be closely monitored and controlled. A formal
change process will govern changes to scope and will require
Steering Committee approval before proceeding with the
implementation of any changes. This process will be created and
administered by the Project Management Team.
• ASU will adopt best practices as defined by Banner and TCC.
• ASU will modify current business processes to adopt standard
functionality and processes defined and supported by Banner.
• This Project Definition Document will be reviewed and approved by
the Steering Committee and supported by the institution as the
project governance document.
• Issue resolution will occur in a timely manner in order to achieve the
project timeline within project budget.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 36 of 117
•
Decision-making will be delegated to the lowest level possible with
due consultation. It is expected that mistakes will be made and
these will be accepted as part of the learning process.
Access:
• Access to SCT Banner and training will be provided for all
departments and programs in a manner appropriate to job
responsibilities.
• The SCT Banner implementation process will be performed in an
open and participatory manner.
Training:
• Appropriate and timely skill set development and training facilities
will be provided and sustained.
• Staff will be granted the necessary time to participate in training and
perform follow-up implementation activities.
• Training will be provided for the most recent major release of the
SCT Banner software. The current major release of SCT Banner is
6.x; the minor release number varies for each Component System.
SCT Banner 6.x requires Oracle 9i and Oracle Forms 6.0.
• Three separate training facilities will be made available during the
life of the project.
• ASU will provide end user training.
Modifications:
• With the exception of the Texas Modifications, ASU will minimize
modifications to the Banner system. All proposed modifications will
be individually approved by the Steering Committee.
• A commitment will be made to change institutional processes to
match processes expected by the software. Only under extreme
circumstances and with explicit Steering Committee approval will
customizations be made.
Other:
•
•
•
March 13 2007
Dedicated workspace will be provided for the Project Team.
Protocols will be followed for meetings, communications, and
change control. All participants will use the agreed communication
channels with sufficient frequency to meet project commitments
(e.g., check email frequently).
A standard reporting tool for SCT Banner will be selected. Access
to the tool will be provided to the project team members.
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 37 of 117
5.2
Dependencies
5.2.1
Dependent Projects
The following table outlines the ongoing projects whose deliverables will be
required to enable this project to meet its objectives:
Project Name
Student – OneCard
Upgrade/Implementation
HR - OneCard Upgrade/Implementation
Campus Master Plan
Housing System
Degree Audit
Data Warehousing
5.2.2
Expected
Completion
Date
9/1/04
Resources
3/1/05
12/1/05
12/1/05
12/1/05
12/1/05
Resources
Resources
Resources
Resources
Resources
Reason for
Dependency
Dependent Products
The following table itemizes the dependent products for this project:
Product Name
Microsoft Excel
Microsoft Word
Optika
Library System
One Card
Blackboard
Cashnet
Reporting tool
Housing System
Lab Accounts
5.2.3
Release
Number
2002
2002
Release
Dependency
is Higher
No
No
No
No
Reason for
Dependency
Uploads/downloads
Correspondence
Imaging
Student/Faculty/Em
ployee Information
TBD
TBD
No
Reporting
Dependent Resources
The following table identifies people and material resources upon which the
project is dependent:
Person or Role
SCT staff
Subject Matter Experts
March 13 2007
Reason for Dependency
Knowledge and direction
Short term assignment to project in addition to
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 38 of 117
Tech Resources
6
regular duties
Support interfaces
Project Constraints
Project Constraints are aspects about the project that cannot be changed and
are limiting in nature. Constraints generally surround four major areas: Scope,
Cost, Schedule (Time), and Quality.
6.1
Project Dimension Grid
The grid below prioritizes the critical project dimensions and is used to
negotiate changes during the course of the project. The first step is to specify
the constraining dimension. Is the critical project driver scope, cost, quality, or
time? The second step is to specify the accept dimension. If change is
required, in which area are the key stakeholders most willing to accept
change: scope, cost, schedule, or quality? Change must be accepted in at
least one dimension. This is specified in the Vary column below. Remaining
dimensions are then minimized or maximized. These dimensions will be
utilized for all aspects of the project, unless explicitly stated in a sub-project
definition.
A balance exists between the four project dimensions and a change in one
will impact the other dimensions. For example, if the scope dimension
increases then the schedule and cost dimensions will also increase to
maintain the quality dimension. If the scope dimension increases, but
schedule and cost stay the same then the quality dimension may decrease.
The project dimensions are specified below, with Constrain in at least one
dimension and vary in at least one dimension:
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 39 of 117
Project
Dimension
Scope
Cost
Schedule
Quality
6.2
Minimize/Maximize
Constrain
Vary
X
Minimize
Minimize
X
X
X
Constraint Details
No constraint details are described at this time.
7
Risks
This section identifies the risks to the project with respect to the environment,
user expectations, competing projects, project assumptions, resources, or any
other relevant matter. Examples of risk include potential loss of a critical
resource, technology changes, regulatory changes, dependence on a third
party, scope changes, project sponsorship or management changes, and
legal issues. Approaches to responding to risks include:
Retention
Deflection
Preventive
Contingent
Avoidance
The risk is acceptable; retain it and accept the consequences.
Transfer the risk to another party.
Take action in advance of the risk event to reduce its
likelihood or its impact.
Specify action that will be taken in response to a risk event, to
mitigate its consequences.
The risk is rejected; do nothing
Risks identified at the beginning of the project are logged in the table below.
A risk can be escalated to a Project Issue or Jeopardy after the project is
initiated. (See Record and Manage Jeopardy Items, Section 9.5.6.7, and
Record and Manage Issues, Section 9.5.6.8).
One purpose of risk
identification is to prevent a risk from escalating to an issue or jeopardy.
This table will be used to track risks identified during the project. If a risk
becomes an issue or jeopardy, it must be designated as such below. In this
table, Probability of Occurrence, Estimated Project Impact, and Weight are
used to classify risks.
Risk Table
Probability guidelines:
3
Very Likely
2
Probable
1
Unlikely
March 13 2007
70-100%
40-70%
0-40%
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 40 of 117
Impact guidelines for scope, cost, schedule, or quality
3
Catastrophic
2
Critical
1
Marginal
Issue or
Jeopardy
Control
No.
Risk
(If...)
Budget and Funding
Unanticipated
costs
Software Functionality
The SCT
Banner software
may not be able
to fully
accommodate
institutional
policies,
procedures or
current
functionality
without
modification.
Delivered
reports may not
meet ASU’s
needs.
March 13 2007
Consequences
(Then...)
Probability
Impact
Weight
Weight = Probability + Impact - 1
Response
Costs may be
overlooked,
leading to
insufficient
funds when
project is
already in
progress.
1 2 2 Preventive/
Contingent.
Built
contingency
dollars
Monitor ongoing
project activities
SCT Banner
modifications
are required,
leading to cost
& maintenance
issues; or,
overwhelming
process
changes.
2 2 3 Retention. ASU
will first attempt
to modify
policies and
procedures,
rather than
modify SCT
Banner.
Modifications
are subject to
approval by the
Steering
Committee.
1 2 2 Preventive.
Understand
delivered
reports, ASU’s
reporting needs
and reporting
options early.
Delayed
implementation
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 41 of 117
Risk
(If...)
Data migration
tools do not do
what is
necessary.
TCC
Modifications
may negatively
impact Banner
functionality.
Culture and Morale
Empowerment
of teams may
not be
respected or
accepted.
March 13 2007
Consequences
(Then...)
Probability
Impact
Weight
Issue or
Jeopardy
Control
No.
Response
Ensure staff
members have
necessary
training in use of
query and
reporting tools.
Delayed
2 2 3 Preventive.
implementation
Begin migration
planning and
testing early in
the project.
ASU may not be 2 3 4 Retention. Allow
able to meet
enough time for
state
testing.
requirements.
Project delayed
due to slow
decision
making; team
decisions
secondguessed,
criticized,
harming morale.
Lack of senior
management
commitment.
Resources may
not be allocated
and could delay
the project.
Ineffective
communications
leading to lack
Delayed project
or diminish
quality of the
2 2 3 Contingent.
Communicate
the authority
and
responsibility of
the empowered
team members.
Revise the
schedule if the
risk
materializes.
1 2 2 Contingent.
Develop a
communication
plan to keep
them informed
to obtain their
commitment.
2 2 3 Preventive.
Develop a
Banner
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 42 of 117
Risk
(If...)
Consequences
(Then...)
of acceptance of work products.
solution and
significant
productivity
and/or rework
costs.
During
implementation,
decline in
service level of
the existing
systems.
Resources and Skills
Loss of staff
critical to the
project.
Necessary
March 13 2007
Unhappy
customers.
Probability
Impact
Weight
Issue or
Jeopardy
Control
No.
Response
“marketing/publi
city” plan
Develop Enduser training
plan
Develop an
Organizational
Readiness plan
3 2 4 Preventive.
Provide
necessary
resources and
manage
expectations.
Keep the
community
informed of
project
objectives and
progress.
System or
module
implementation
delayed.
2 3 4 Contingent.
Critical positions
will be filled as a
priority.
Preventive.
Have back-ups
available.
Provide cross
training &
document
processes.
Staff must
document their
project-related
activities.
System or
2 3 4 Preventive.
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 43 of 117
Risk
(If...)
Consequences
(Then...)
resources are
not committed
to properly staff
the project.
module
implementation
delayed. Quality
of services will
decrease.
Assigned
Project
Members may
not have time to
perform project
related
activities, may
not be directed
to do so by their
supervisors, or
may not accept
project as their
job priority.
Project delayed
Appropriately
qualified backfill
is not available.
Project delayed
Inability of ASU
to accept and
manage the
business and
process
changes
required for the
ERP project
Unhappy users.
Low employee
morale. High
employee
turnover
Probability
Impact
Weight
Issue or
Jeopardy
Control
No.
Response
Have backfills
available.
Develop training
programs to
rapidly educate
replacement.
2 2 3 Preventive.
Monitor
progress of all
project team.
Communicate
with team
members and
their supervisors
throughout the
project
concerning
workload and
ability to meet
deadlines.
Allocate
resources if
necessary.
2 2 3 Preventive.
Hire backfill
early enough to
train. Assess
what staff will be
needed for
backfill early.
2 3 4 Preventive.
Keep
community
informed and
involved.
Provide training.
Schedule and Priorities
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 44 of 117
March 13 2007
Probability
Impact
Weight
Issue or
Jeopardy
Control
No.
Risk
(If...)
Consequences
(Then...)
Timeline may be
unrealistic if
ASU is forced to
have other
responsibilities
take top priority.
Portico project
MUST be a top
priority for the
campus.
State
requirements
may change
while the project
is in progress
Late
implementation
and cost
overruns
2 2 3 Deflection.
Steering
Committee must
enforce
institutional
priorities.
Late
implementation
and cost
overruns
Training
facilities may
not be available
as needed.
Late
implementation
and cost
overruns
Product
requirement is
needed to
signoff on Fit
Gap Analysis
and Functional
Requirements
for TCC
Modifications
Delayed
delivery of TCC
Modifications
and
implementation
of Finance.
Manually feed
information into
State system
2 2 3 Preventive/
Contingent.
Stay connected
with State
agencies. Build
time for selected
contingencies
into the project
schedule.
2 2 3 Preventive.
Develop training
plan early and
schedule
required
facilities as soon
as possible.
Plan a work
around should
unexpected
problems arise.
3 3 5 Contingent.
Design an
implementation
team-training
plan to help
team gain
expertise as
needed. Assign
additional
resources.
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Response
Page 45 of 117
Risk
(If...)
Technology Infrastructure
Hardware not
delivered in a
timely manner
8
Consequences
(Then...)
Delayed
implementation
Hardware
and/or software
does not
perform as
expected
Delayed
implementation
Network
bandwidth may
be insufficient
Unsatisfactory
system
performance
Lack of data
quality when
converting data
from existing
systems
Delayed
implementation
or impaired
quality
Probability
Impact
Weight
Issue or
Jeopardy
Control
No.
Response
1 2 2 Preventative.
Coordinate
decisionmaking and
scheduling of
resources.
1 3 3 Preventative.
Sufficiently
research
specifications
and hardware
and software
compatibility.
1 1 1 Preventative.
Ensure systems
requirements
are understood
and network
capacity is
sufficient.
2 2 3 Preventative.
Allow adequate
staffing for data
clean-up before
migration.
Project Organization
This section describes the organizational structure of the project and identifies
the ASU and SCT personnel that will be involved with the project. Other
personnel may be involved as the project moves through its different phases.
8.1
Project Team
The ASU Banner Project Team will be composed of members of the ASU
community and SCT technical experts and consultants, who are all
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 46 of 117
responsible for the success of the SCT information systems at Angelo State
University. They will all work from a constituent-centered view to ensure that
the system is implemented in a timely and cost-effective manner, integrated
with other software applications, and well-trained users are able to use the
system effectively.
8.1.1
Qualifications for all Team Members
Team members are selected for, and must abide by, the following
qualifications:
•
•
•
•
•
•
March 13 2007
Ability to make decisions by consensus.
Ability to work well under pressure and in a professional manner.
Detailed knowledge of their functional area.
Ability to listen and value input from all participants.
Committed to clear, shared goals.
Ability to work as a team and to interact on a regular basis to
accomplish specific tasks.
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 47 of 117
8.1.2
Organizational Structure
The organizational structure of the project is shown in the following diagram:
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 48 of 117
8.2
ASU Personnel
Each currently identified ASU resource on the project is listed here or in the
Project Schedule, and contact information for each is provided in the
Appendix A.
8.2.1
Executive Sponsor
The Executive Sponsor is Sharon Meyer, Vice President of Finance and
Administration. She will work with the ASU Associate VP for Information
Technology and CIO, SCT and third parties to expedite and resolve issues
that require the highest executive level involvement, such as contract
amendments. The Executive Sponsor will participate on the Steering
Committee and promote the visibility and credibility of the project.
8.2.2
Steering Committee
The Steering Committee will be responsible for guiding the implementation
from an institutional point of view. This will include making appropriate policy
decisions when needed, and expediting decisions. Members of the Steering
Committee are:
Provost and Vice President for
Academic & Student Affairs
Vice President for Finance &
Administration
Administrative Assistant &
Coordinator of Special Activities
Associate VP for Information
Technology and CIO
8.2.3
Dr. Don Coers
Sharon Meyer
Shirley Morton
Doug Fox
Project Management Team
The Project Management Team will manage all project related activities and
tasks and is responsible, along with the Implementation Team (described
below), for the successful implementation of Banner and Luminis. The Project
Management Team is responsible for getting the work “done” – on time, within
budget, and according to specifications.
In addition the Project Management Team is responsible for:
•
•
•
•
•
•
March 13 2007
Maintaining the project budget.
Developing and maintaining project plans.
Managing project scope.
Coordinating activities for area teams.
Ensuring adherence to project plans.
Establishing the training schedule and monitoring the training
library.
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 49 of 117
•
•
•
•
•
•
•
•
Ensuring documentation is started and completed.
Ensuring training is scheduled and available for project team
members and end users.
Ensuring that the Communication Plan is followed.
Facilitating and negotiating resolution of critical communication and
business processes.
Ensuring the resolution of problems, issues and change requests.
Leading the Project Team.
Working cooperatively with area team leaders and all teams
members.
Developing long term budgets and training plans.
Members of the Project Management Team are:
Project Manager
Training/Communications Specialist
Project Assistant
Academic Services Project Manager
Coordinator of Process Integration
Project Technical Lead
8.2.4
Brian Braden
Patrick Dierschke
Paula Dowler
Jackie Droll
Charles McCamant
Jeff Sefcik
Contract Administrator
The Contract Administrator administers the contractual relationship between
SCT and ASU. This function is the responsibility of the Associate VP for
Information Technology and CIO
and the Vice President of Finance and
Administration.
8.2.5
Configuration Manager
Responsibilities of the Configuration Manager are:
•
•
•
Preparation of the Configuration Management Plan.
Executing and tracking all activities specified in the Configuration
Management Plan.
Tracking all documents under Configuration Management.
This function is the responsibility of the Project Management Team.
8.2.6
Change Control Board
The Change Control Board will be responsible for managing changes to the
project deliverables as specified in the Configuration Management Plan, as
follows:
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 50 of 117
•
•
•
•
Authorizes the establishment of project baselines and identification
of configuration items.
Represents the interests of all persons and groups who may be
affected by changes to the project baselines.
Reviews and authorizes changes to the project baselines and
communicates these changes to project team members.
Manage changes affecting project dimensions (scope, quality,
schedule, and cost).
This activity is a function of the Project Management Team pursuant to
approval by the Steering Committee.
8.2.7
Change Management Team
The Change Management Team will be responsible for the following primary
activities:
•
•
•
•
Develop change management strategies
Manage communications
Manage training
Document lessons learned
This activity reports to the Project Management Team.
8.2.8
Implementation Team
The Implementation Team will oversee and expedite the implementation of all
systems. The Implementation Team will meet on a weekly basis and will
submit a written status report to the Project Management Team as described
in the Communication section below.
Additionally the Implementation Team will:
•
•
•
•
•
•
•
•
•
March 13 2007
Oversee the implementation of Banner.
Monitor the interaction of Banner among the departments.
Define data fields that will be used campus wide.
Set rules on the design/construction/inputting of data fields.
Set standards for the communication and business processes to be
used campus wide.
Monitor data, communication, and business processes standards
within a department to ensure compliance with campus wide
standards.
Support proper communication of the project.
Build and support proper foundation for short and long term
documentation library and training programs.
Set priorities for allocation of resources.
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 51 of 117
•
•
•
Expedite decision-making.
Make recommendations for policy decisions.
Recommend acceptance or rejection of baseline documents and
changes to those documents under CM.
The Implementation Team is composed of members of the Project
Management Team and the Core Process Team Leads.
8.2.9
Core Process Teams
Core Process Teams correspond to SCT Banner functional systems, except
as specifically noted below. Each Core Process Team is the primary liaison
among all groups involved in the particular process area and ensures
representation of non-implementation personnel where appropriate. The Core
Process Teams make process and procedural decisions related to the
implementation in their functional areas.
Each Core Process Team has a designated Process Team Leader which is
responsible for facilitating communication among team members and
monitoring progress towards completion of tasks and deliverables assigned.
During its implementation cycle, each Core Process Team will meet on a
weekly basis and will submit a status report in writing on a weekly basis to the
Project Management Team. The Core Process Team members will attend the
appropriate training sessions provided by SCT.
In addition, Core Process Teams will perform specific tasks related to the
implementation, including:
• Perform Business Practice Analysis.
• Ensure that Best Practice processes are implemented.
• Define and test user procedures for their area.
• Develop Policy and Procedures Manuals and end-user training
documents.
• Validate converted data in their area.
• Attend SCT training.
• Make decisions by consensus.
• Recommend policy changes or system changes to Project
Management Team.
• Ensure completion of major tasks.
• Form functional work teams as needed and assign tasks and
responsibilities.
• Provide status reports to Project Management Team.
8.2.9.1
Finance Team
The Finance Team is organized as follows:
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 52 of 117
Process Team Lead
Texas Connection Consortium
Lead
Candy Woodul
Lead
Team member
Assistance
Candy Woodul
Identified as Needed
Janet Coleman
Denise Brodnax
Accounts Payable
General Ledger
Lead
Team member
Denise Brodnax
Janet Coleman
Lead
Team member
Assistance
Margaret Mata
Identified as Needed
Janet Coleman
Denise Brodnax
Purchasing
Budget
Lead
Angie Wright
Lead
Team member
Scott Prindes
Denise Brodnax
Lead
Team member
Maggie Pepper
Denise Brodnax
Lead
Team member
Janet Coleman
Martha Cox
Fixed Assets
Endowment
Non-Student Accounts Receivables
8.2.9.2
Denise Brodnax
Human Resources Team
The Human Resources Team is organized as follows:
Process Team Lead
Felix Marquez
Lead
Team Member
Felix Marquez
Lead
Team Member
Dana Evans
Lead
Team Member
Felix Marquez
Lead
Team Member
Angie Wright
Dana Evans
Texas Connection Consortium
Payroll/Deduction
Benefits
Position Control/Budget
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 53 of 117
Team Member
8.2.9.3
Student Team
The Student Team is not yet active. Expected participants are presented in
Appendix A.
8.2.9.4
Financial Aid Team
The Financial Aid Team is not yet active. Expected participants are presented
in Appendix A.
8.2.9.5
Advancement Team
The Advancement Team is not yet active.
presented in Appendix A.
8.2.10
Expected participants are
Work Teams
Work Teams are established as needed to perform specific activities in the
project plan. Work Teams are frequently cross functional, and are a valuable
means to test new business models with constituents across the organization
and obtain feedback that will help build the enterprise-wide solution.
Interaction within the Work Teams is the first mechanism to introduce and
manage incremental change within the organization. The Work Teams are
responsible for providing information to the Core Process Teams, assisting
them in making decisions and recommending overall solutions. The leader of
each Work Team is typically a member of and accountable to the Process
Team. Work Team members are accountable to the leader of their team.
Some Work Teams are created, perform their responsibilities, and then are
disbanded; while others may be present throughout the project. The following
Work Teams have already been identified as necessary for this project.
8.2.10.1 Report Strategy Work Team
The Report Strategy Work Team will develop a report strategy for the
institution. The team will identify the key requirements and match them to a
reporting solution. Team members will review existing reports for their
corresponding areas or interview the appropriate individuals to determine if a
report still satisfies the reporting needs. The Report Strategy Work Team will
coordinate the effort of identifying future reporting needs (wish lists) after the
analysis is concluded. The team will also determine what will be the best
reporting tool(s) for the University needs. Expected members of this team are
presented in Appendix A.
8.2.10.2 Data Standards
The Data Standards Team ensures correct, accurate, and consistent data,
standardized for use in all departments. Expected members of this team are
presented in Appendix A.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 54 of 117
8.2.10.3 Data Migration
The Data Migration Team is responsible for the data migration efforts.
Expected members of this team are presented in Appendix A.
8.2.10.4 Security
The Security Team is responsible for defining Banner Security. Expected
members of this team are presented in Appendix A.
8.2.10.5 Degree Audit/Student Advising Team
The Degree Audit/Student Advising Team is responsible for evaluating the
CAPP module portion of SCT Banner to make sure it meets their needs.
Expected members of this team are presented in Appendix A.
8.2.10.6 Interface Team
The Interface Team will tie the current system data feeds to the new Banner
system. Expected members of this team are presented in Appendix A.
8.2.11
Technical Team
The Technical Team oversees the core technology issues of the project, such
as hardware platform, operating system, and database system issues.
Expected members of this team are presented in Appendix A.
8.2.12
Luminis Team
The Luminis Team will oversee the implementation of the Luminis portal and
content management system. The Luminis portal is currently planned to be
phased in throughout the project. Jason Hord will be leading the
implementation of the Luminis Portal. Additional Luminis team members will
be identified as progress is made.
8.3
SCT Personnel
General Manager (Tony Weis): The SCT General Manager has overall
responsibility for the Angelo State University account. Project related issues
concerning SCT resources or activities should be forwarded to the General
Manager for resolution. The standard level of contact between the SCT
General Manager and Angelo State University will be at the Executive Team
level.
Account Manager (Walt Glass): The SCT Account Manager will serve as the
primary contact point to SCT. This person will be responsible for scheduling
and monitoring the SCT resources assigned to the project. The standard level
of contact between the SCT Account Manager and Angelo State University
will be at the Project Manager and Project Team level.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 55 of 117
SCT Project Manager (Patricia Zepeda): The SCT Project Manager will be
responsible for the development, delivery and monitoring of the project plan
and all associated communication. The standard level of contact between the
CT Project Manager and Angelo State University will be at the Project
Manager and Project Team level. The SCT Project Manager will provide
status reports in writing to the Angelo State University Project Manager after
each onsite visit.
SCT Quality Assurance Analyst : The SCT Quality Assurance Analyst will
assist in the development of the Quality Assurance Plan and performing
Quality Assurance Assessments and produce a Quality Assurance Status
after each assessment. The standard level of contact between the SCT
Quality Assurance Analyst and Angelo State University will be at the Project
Manager and Project Team level. The SCT Quality Assurance will provide
status reports in writing to the Angelo State University Project Manager after
each Quality Assurance Evaluation.
SCT Application and Technical Specialists: Technical and Application
specialists will be assigned as needed to the Angelo State University project.
Each will have specific application knowledge and be responsible for specific
tasks identified by the SCT Account Manager or SCT Project Manager. Such
tasks to include:
•
•
•
Installation review
System education
General consulting
Trip agendas and post trip reports will be produced by these specialists and
submitted to the SCT Project Manager, the Angelo State University Project
Manager, and the appropriate Angelo State University Core Process Team
Leader. The standard level of contact between the SCT Specialist and Angelo
State University will be at the Core Process Team Leader level.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 56 of 117
9
Project Approach
The project approach section deals with how the project will be completed.
DEFINITION
PLANNING
IMPLEMENTATION
CLOSEOUT
9.1
Definition
For the project management approach, the Definition Phase activities of
SCT's Common Service Methodology (CSM) will be followed. For the
software implementation approach, the Definition Phase activities of SCT's
Enterprise Process Model will be followed.
During the Project Definition Phase, Angelo State University and SCT will
meet to review the documents generated throughout the sales cycle, agree on
the approach to deliver the services contracted and the work products to be
completed, and discuss the recommended project organization, approach and
resources needed for the project.
At end of the Project Definition Phase the following activities will be
completed:
•
•
•
•
•
•
•
March 13 2007
Hardware and software purchase
Definition and prioritization of project requirements
Formation of teams
Definition of project milestones
Development of a communication plan
Identification of the project team training needs
Initial definition of the Project Definition Document (PDD) including
the identification of project deliverables and the definition of project
success criteria
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 57 of 117
9.2
Planning
For the project management approach, the Planning Phase activities of SCT's
Common Service Methodology (CSM) will be followed. This Project Definition
Document, the project schedule, and all the supporting plans are key
deliverables of this phase.
For the software implementation approach, the Planning Phase activities of
SCT's Enterprise Process Model will be followed. Responsibilities will be
assigned according to the Banner Implementation model.
Planning is the most crucial phase of the project life cycle. Planning sets the
expectations and framework from which the project is implemented. It will
organize the work by responsible persons, sequence and schedule the
deliverables, and identify plans for contingencies.
During the planning phase the SCT Project Manager in conjunction with the
Angelo State University Project Manager will be responsible for:
•
•
•
•
•
•
•
•
9.3
Completing the Project Definition Document.
Completing the Configuration Management Plan.
Completing the Organizational Readiness Plan and Change
Management Plan.
Completing the Quality Assurance Plan.
Defining Business Process Analysis Requirements.
Defining Data Migration Needs and develop Data Migration Plan.
Developing a Testing Plan.
Determining hardware and software installation needs.
Implementation
This section provides details regarding how the project is going to be
implemented for each phase.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 58 of 117
9.3
Implementation
9.3.1
9.3.1.
Document Current Business Processes
9.3.2.
Define Data Standards
9.3.3.
Perform Reporting Analysis
and Develop a Reporting Strategy
9.3.4.
Install Software
9.3.5.
Conduct System Education
9.3.6.
Design Business Solution
9.3.7.
Configure Business Solution
8.
Test & Refine Solution
9.3.9
Perform System, Integrated and Stress Testing
9.3.10.
Execute Data Migration
9.3.11
9.3.11 Train End Users
9.3.12
Deploy the Solution
9.3.13
Plan Continuous Improvement
9.3.14
Project Tracking and Control
Document Current Business Processes
After attending the Business Process Analysis (BPA) seminar, each Core
Process Team identifies and documents major business processes. The
documentation prepared includes a list of what works well and improvement
needed. This documentation will be made available to the SCT functional
consultant prior to the initial visit for review and environment familiarization.
At completion of the BPA seminar the Implementation Team will:
•
•
•
March 13 2007
Document the primary current business practices
Provide additional descriptions of current business processes as
needed
Document non-value added steps in each primary current business
practice.
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 59 of 117
9.3.2
Define Data Standards
The Data Standards Work team will prepare Data Standard guidelines to
provide recommendations for establishing measures for the protection,
access, and use of University data that is electronically maintained on the
Banner system. The guidelines define the responsibilities of users who input
and access that data. Divisions/departments may have individual guidelines
that supplement, but do not replace or supersede these guidelines.
9.3.3
Perform Reporting Analysis and Develop Reporting Strategy
The Reporting Strategy Work team will develop a report strategy for the
institution. The team will identify the key requirements and match them to a
reporting solution. The team will review all existing reports, determine if the
reports still satisfy the end-user reporting needs, and identify future reporting
needs (wish lists) after the analysis is concluded. The team will also
determine what will be the best reporting tool for the University’s needs.
9.3.4
Install Software
SCT and ASU will jointly develop an installation plan and identify the
resources required to execute the operational requirements. SCT staff will
first install Banner followed by the installation of corresponding self-service
products.
Before installation, a conference call will be scheduled to plan software and
hardware installation activities. After all the installation activities are
completed, SCT consultants will run a test to ensure that the application
software is operational and ready to support the project's activities.
At completion of this activity, SCT will:
•
•
9.3.5
Install and test the software
Create a “Seed” Instance
Conduct the Systems Education
Systems education is not synonymous with end-user training. The objective of
SCT Systems Education/Training is to provide the necessary training to
enable implementation teams and workgroup participants to understand
Banner features, functions, business rules, processes and setups so that
these individuals can design the future business process solution.
At completion of the System Education activity SCT will have:
•
•
•
March 13 2007
Prepared a System Education Plan
Delivered training materials
Prepared a training schedule
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 60 of 117
•
•
Prepared Trip Reports
Trained the project teams
At completion of the System Education activity, Core Process Team members
will have:
• Attended training classes
• Completed Assignments
• Learned how to operate Banner
9.3.6
Design the Business Solution
During the design activity, all aspects of the business process are considered,
including:
•
•
•
•
•
•
•
•
Process assumptions and goals
Inputs and outputs (including interfaces)
Work steps and flows
Automated and manual processes
Organizational responsibilities
Security requirements
Reporting requirements
Estimated transaction volumes and performance benchmarks
At this time, the Core Process Teams establish foundational data definitions,
business rules, and determine if software modifications are needed.
Functional and technical specifications for software modifications, baseline
enhancements, interfaces, conversions, and the reporting environment are
also developed during the design phase. Concurrently, the project team is
working with IT to design the technical infrastructure, including hardware,
network, and desktop requirements and other aspects of the future technical
environment (including IT organizational responsibilities).
Angelo State’s Deliverables:
•
•
•
•
•
•
•
•
•
•
March 13 2007
Future business process solution design documents
Flowcharts of processes and sub processes
Description of the processes
Reporting recommendations
Security recommendations
List of necessary interfaces
Data conversion requirements and mappings
Data standards
Justification for software modifications as outlined in the Project
Administration document
Preliminary training schedule
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 61 of 117
•
•
•
•
•
•
•
9.3.7
Training materials
Cut over strategies and schedule
Technical infrastructure design document
Printing solutions recommendations
Third party software recommendations
IT roles and responsibilities
Final Scope description
Configure the Business Solution
During the configuration or build stage, the solution is implemented in the
testing instance in accordance with the solution design documents. Baseline
applications are set up, business rules are established, workflows are defined,
security and user accounts required for testing are established, the master
test data set is defined, data mapping rules are defined, and test data is
converted and entered. In the development instance, coding for software
modifications, automated conversion routines, reporting, and other features
are performed, unit tests are conducted, and the software is migrated into the
testing. Owners of the legacy systems and IT are developing code to provide
output files in accordance with the interface specifications. The system
configuration phase also includes the beginning development of draft policies,
procedures, and user guides since testing will assess the reliability and
functionality of the entire business process (not just the applications) in a
production-like mode.
Angelo State’s Deliverables:
•
•
•
•
•
•
•
•
9.3.8
Applications set up and configured
Prototype business rules and workflows defined
Preliminary security and user accounts established
Master data sets established
Required test data converted
Initial interface specs developed and communicated
Demonstration of system functionality for business process owners
and Process Team members conducted
Preliminary drafts of policies and procedures and user manuals
started
Test and Refine the Solution
Testing of the individual processes begins after the prototypes have been
configured in the system with sufficient data to support transaction testing for
each process. This will include processing a defined set of transactions for
each process to examine the outcome and to enable the procedures and
steps to be fully understood.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 62 of 117
As the testing proceeds, the processes will be refined, the procedures
identified, refined and documented, individual issues resolved, and
modifications tested and installed as available. Users of the systems including
all personnel from the functional office will participate in the test to provide an
opportunity for their input into the procedures and processes.
Data mapping for transfer of legacy data will continue to be tested and refined
as well as the resolution of the institution’s reporting solution and location of
historical data and volumes of historical data to be brought forward. The
actual outcomes are documented and updated as testing is completed and
processes refined throughout the testing phase. The outcomes will be
compared to the expected outcomes for the processes. Refined processes or
expectations will be developed as needed based on the results of testing.
During this phase, demonstrations of the processes may be developed for a
variety of groups including the individual Process Teams, the steering
committee, and other groups. This testing is designed to test the individual
processes. It may include testing against other modules as required. Full
integrated testing is accommodated in the next phase.
Angelo State University Deliverables:
•
•
•
•
•
•
9.3.9
Completed test results
Refined processes, testing plans, scenarios, scripts and
expectations
Draft of data mapping of legacy data, reporting solutions, location of
historical data and volume of legacy data determined
Draft policies and procedures
Draft user materials
Draft training materials
Perform System, Integrated and Stress Testing
Once all solutions, modifications, and extensions have been delivered and
tested, system testing can commence to verify that Banner performs as
designed with live data.
Integrated testing follows to prove the full interoperability of the system as a
whole. All components of the go-live production environment need to be
integrated into this testing cycle, as they become available. Toward the end of
this cycle performance testing under load (stress and availability testing) will
be conducted to produce metrics to aid in tuning the software and hardware
for production.
Integrated testing will test all the functionality of each module in an emulated
live environment. During this stage of testing, a representative subset of
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 63 of 117
directly-entered transactions and feeds from external systems using job
scheduling routines emulating production will be processed to verify system
functionality. Final testing of legacy data mapping and reporting solutions will
be conducted throughout this step. Scripts, refined in the prior phase, will be
used to determine results in a fully integrated environment and provide for any
final refining necessary using data mapped from the legacy systems as much
as possible. Interfaces, production schedules and reporting requirements are
also tested and final refinements made.
Modifications are fully tested, installed, and final testing performed in this
segment.
Deployment solutions are finalized and fully tested as well as stress tests to
determine likely system performance. Final documentation is prepared and
end user training scheduled and communicated.
Any parallel testing required will be completed during the integrated testing
mode.
Presentations of final processes are developed and submitted to the
appropriate groups.
Final sign-off by each of the Process Teams and the Steering Committee and
any other pertinent parties is obtained on the final processes.
Angelo State University Deliverables:
•
•
•
•
•
•
•
•
•
•
•
9.3.10
Individual system check list
Interoperability check list
Summary of areas requiring refinement/adjustment
Systems performance metrics
Completed systems performance test results
Completed integrated test results, including tests of external
interfaces
Completed parallel test results, as appropriate
Final polices and procedures
Final user materials
Final training materials
Documented acceptance by ASU management, business process
owners, and other pertinent parties
Execute Data Migration
The data migration process is one of the most complex implementation tasks
and it is a critical step to the success of the implementation. To successfully
execute the migration activities the institution will:
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 64 of 117
•
•
•
•
•
•
•
•
•
Determine conversion method. Manual, automatic or a combination
of both
Determine the scope of the conversion
Plan conversion activities
Gather conversion requirements
Finalize detailed mapping rules including historical data
Define Data Standards
Populate institution-specific values in validation tables
Extract data from legacy systems and populating appropriate tables
Perform quality assurance on the converted values and resolve
exceptions to the conversion rules
SCT Technical consultants will meet with ASU Data Migration Work Team to:
•
•
•
•
Plan Conversion Activities
Install and provide Data Migration Tool Kit Training
Onsite Data Mapping for each product
Remote or Onsite follow-up support
The ASU Data Migration Work Team is responsible for:
•
•
•
•
•
•
9.3.11
Detailed Conversion Plans
Final mapping rules
Automated conversion facilities
Legacy data converted
Production enterprise server systems on-line
Banner production environment constructed and on-line
Train End Users
The objective for developing an end-user training program is to enable the
institution to deliver information about the new system in a manner that is
easily understood and quickly assimilated by the target groups.
It is critical that a training plan is developed to set the common expectations
around which the training will be completed. The training plan also identifies
the various groups that need to be trained, the training curriculum for each
group, the mode of training for each piece of the curriculum and the
approximate time frame and locations for the training sessions.
The project team or a group of selected project team members will develop
training materials and will be responsible for conducting the training.
Angelo State University Deliverables:
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 65 of 117
•
•
•
•
9.3.12
Completed end-user training plan
Final end-user training materials/curriculum completed and logistics
determined and communicated
Security, connectivity and desktop configured
User community trained
Deploy the Solution
During the deployment stage, the applications are set up and configured in
the production mode, software modifications and enhancements are migrated
into production, and full converted data sets are loaded. In summary, the
institution is ready to begin daily operations using the new system.
Angelo State University Deliverables:
• Implement final cut-over plan
• User support structures in place
• Fully functional system exists
9.3.13
Plan Continuous Improvement
The Plan Continuous Improvement stage is preamble for the project close-out
activities. At this time each process team evaluates system effectiveness,
tunes the system to enhance performance, modifies procedures as required,
and conducts ongoing training and consulting programs to support the new
information technology.
Angelo State University Deliverables:
•
•
9.3.14
Plans for the introduction of additional reporting features, modules,
upgrades, performance standards and monitoring completed
Assess human resource requirements associated with post
implementation maintenance
Project Tracking and Control
During the Implementation Phase the Project Manager is responsible for
tracking and controlling the project implementation activities. Among the
activities performed by the project manager is tracking project team training
progress, tracking organizational readiness, project tracking and reporting.
Angelo State University Deliverables:
•
•
•
•
•
March 13 2007
Project Status Report (monthly)
Project Training Status Report (after each training session)
Issue and Jeopardy Report and Action Plans (as needed)
Project Meetings Agenda/Minutes (after all meetings)
Manage Project Team
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 66 of 117
•
•
Schedule (as needed)
Project Records (as needed)
SCT Deliverables:
•
•
•
•
•
•
9.4
Project Status Report after each Project Management visit
Issue and Jeopardy Report and Action Plans (as needed)
Project Tracking & Control (as needed)
Resource Allocation (as needed)
Updated Training Schedule (as needed)
Project Records (as needed)
Close-Out
Closing out a project involves both product verification (was all work
completed correctly and satisfactorily?) and administrative closure (verifying
and documenting project results to formalize acceptance of the product of the
project by ASU, plus collection of project records, ensuring that they reflect
final specifications, analysis of project success and effectiveness, and
archiving such information for future use).
For the software implementation approach, the Close-Out Phase activities of
SCT's Enterprise Process Model will be followed.
For the project
management approach, the Close-Out Phase activities of SCT Common
Service Methodology will be followed. Responsibilities will be assigned
according to the Standard Implementation model.
Evaluation of the
implementation, recommendations, and final approvals are key activities.
SCT Close-Out Deliverables:
•
•
•
•
•
•
Final Project Status Report
All documentation is in place
All outstanding issues have been resolved
Close out project and identify next steps
Obtain formal acceptance from Steering Committee
Document lessons learned with recommendations
Angelo State Closeout Deliverables:
•
•
•
•
•
March 13 2007
All Banner upgrades issued during the implementation timeline are
tested and implemented
Close out project and identify next steps
Evaluate implementation
Obtain formal acceptance from Steering Committee
Document lessons learned with recommendations
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 67 of 117
•
9.5
Develop plan for on-going end-user training
Configuration Management
This section describes the approach for Configuration Management.
9.5.1
Purpose
The Configuration Management Plan describes the responsibilities,
procedures, tools, and techniques that will be used to manage the
deliverables produced by the Portico Project at Angelo State University.
9.5.2
Objectives
The objectives of the Configuration Management Plan are:
•
•
•
•
9.5.3
To ensure that the agreed upon SCT Common Service
Methodology practices for Configuration Management are in place
for the Angelo State University implementation.
To identify which deliverables’ configurations will be managed.
To define the physical location where deliverables will be stored.
To identify the naming conventions to be used for documents
Benefits
The benefits of adhering to the Configuration Management (i.e. CM) Plan
include:
•
•
•
•
•
•
The integrity of configuration units/items is maintained throughout
the project life cycle.
Changes are effectively controlled and managed throughout the
project life cycle.
Conflicts are reduced by coordinated access to configuration
units/items throughout the project life cycle.
Communication is improved via change control and Configuration
Management status reporting.
Historical information for configuration units/items is maintained
over time.
Quality is improved due to more effective configuration
management.
9.5.4
Configuration Identification
9.5.4.1
General Information
In parallel with the development of the CM Plan, configuration units/items will
be identified. An identification scheme and state transition model will be
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 68 of 117
defined for configuration units/items. Standard naming conventions will be
followed.
The following list identifies the configuration items and/or units to be placed
under configuration management.
•
•
•
•
•
•
•
•
•
•
•
•
•
9.5.4.2
Communication Plan
Data Migration Plan
Project Definition Document
Project Schedule
Quality Assurance Plan
Service Requirement
System Education Plan
Testing Plan
Training Plan
Report Strategy Plan
Risk, Issue, and Jeopardy Reports
Lessons Learned Reports
Final Project Evaluation
Document Identification Scheme
The following identification scheme will be followed for all documents:
<name>_<short name>_<unique ID>_v<version>.<revision>_<date>.<ext>
Example: Project Definition Document_PDD_v1.3_2-02-04.doc
<name>
Is the name of the document, the
following are some sample names, which
may contain letters, numbers and spaces:
<short name>
March 13 2007
Data Standards
Project Definition Document
Education Plan
Configuration Management
This optional field is the abbreviation for
the document name. It may contain
letters and numbers but no spaces. The
following are examples of short names:
DS
PDD
EDPlan
CM
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 69 of 117
<Unique ID>
v<version>.<revision>
<date>
<ext>
9.5.4.3
When needed, this is used to identify
uniqueness of the document when other
documents have the same name. It may
indicate a working group that has the
same document name as another group,
or perhaps an identifier to uniquely
identify a series of interview documents.
If not needed, may be omitted.
FI = Finance
ST = Student
HR = Human Resource
FA = Financial Aid
AD = Advancement
TC = Technical
Refers to the version of the document
(baseline is v1.0) and the revision number
of the document.
May optionally include a date associated
with the version of the document. In the
format mm-dd-yy. Two digit month and
day are required.
Refers to the type of document (doc is an
MS Word document, xls is an MS Excel
document, mpp is an MS Project
document, etc.)
Folder Identification Scheme
The following identification scheme will be followed for all documents:
<order>_<name>
Example: 10_Planning Documents
<order >
<name>
9.5.4.4
A two digit number that is used to force
the folders to appear in a specific
sequence.
Is the name of the document, the
following are some sample names, which
may contain letters, numbers and spaces:
Branding Scheme
To enhance the continuity of the documents associated with the Portico
Project, will be developed using Microsoft Office Products, including Word,
Excel, PowerPoint and Visio. We will be standardizing on fonts, document
templates and style guidelines for these documents.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 70 of 117
Fonts
Headers
Footers
Margins
All documents will use Microsoft Sans Serif as the font set.
You may use Bold and Italic as needed. Refrain from
underlining as this typically indicates a hyperlink to some
other location. In all documents that are printed, strive to
use fonts of 12 points or higher.
Cover sheets will contain the PORTICO Project banner
graphic, and optional may contain a line of text beneath it.
Additional pages will contain the PORTICO text banner as
depicted on this page
Footers on all documents will contain three lines of text as
depicted on this page. The first line, centered will be the
document name using the previously described Identification
Scheme. It should be from the menu bar, insert, field,
filename. Do not type in the file name to the document. The
second line will contain “Angelo State University” centered
on the page. The third line will contain the current date
(insert, field, date) in “mmmm, dd, yyyy” format left aligned
on the left margin, the text “Banner Implementation”
centered and the page number as “Page <page> of <total
pages>” right aligned on the right margin
All margins should be set to 1”, top bottom, left and right.
Templates with predefined styles may be found in the Portico Documentation
Library located on the J: Drive.
9.5.4.5
Portico Documentation Library
The Portico library which can be found on the J: Drive under the “Portico
Project” folder is composed of three primary directories, “Receiving”,
“Working”, and “Baseline”. Underneath all three will be similar subdirectory
directory structures. The following describes the work flow of documents and
materials entering into the system.
Materials Received from SCT
• New documents received from SCT will be placed in the
appropriate subdirectory in the “Receiving” directory.
• A document is reviewed, branded, and name qualified, it is moved
to the “Working” directory.
• In the “Working” directory, it is typically open for all project members
to work on with one exception.
• If a document is set to read-only, you will need to examine the last
page of the file. This will tell you if it is in use by someone off site.
A circulation card will appear at the back of all documents that will
identify the date it was checked out, the person checking out the
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 71 of 117
•
•
document with contact information that includes phone number and
email address at a minimum and the date the item is due back in.
Once a document is approved, it will be moved to the “Baseline”
directory. In this process, the raw office documents will be
converted to a PDF document which will appear in the “Baseline”
directories. All original documents will be stored in archives should
it become necessary to revise the document.
Further revision of documents in the “Baseline” library is possible
when authorized by the Project Manager and/or Steering
Committee. In similar fashion to the procedure used to checkout
documents from the “Working” directory, all persons performing
revision will be required to check out the document. Project
manager delegate the checking out of materials to the Configuration
Manager who will facilitate the function.
Materials Developed on site
New documents developed on site using the Portico templates should be
stored in the “Working” directory until such time that they become baseline
documents. At that time, the procedure is the same as if the document came
from SCT.
9.5.5
Configuration Management Library
The SCT Project Manager will be responsible for storing all deliverables under
Configuration Management for the Angelo State Banner Implementation
Project in the SCT Professional Services Project Tracking Database. The
SCT Professional Services Project Tracking Database is an Intranet-based
SCT repository used to store and maintain all project work products and
deliverables.
The Angelo State Project Manager will be responsible for storing all
deliverables under Configuration Management for the Angelo State Banner
Implementation Project in the Angelo State University project directory.
9.5.6
Record and Manage Change Requests
The appropriate work product database will be utilized to initiate, record,
review, approve, and track change requests. Once configuration units for the
project have been approved and baselined, all future changes (not related to
a defect) will require an approved Change Request in the database. This
includes any client and/or third party changes incorporated into the project.
The following diagram gives a high-level view of the change request process.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 72 of 117
The detailed process for initiating, documenting, estimating, and approving
Change Requests is delineated as follows:
9.5.6.1
Initiate Change Request
• Team Member or Office staff desiring a change will submit the initial
request to the Team Leader
• The Team Leader will review the request with the requestor to
determine whether or not a Change Request should be initiated.
• If a Change Request is to be initiated, The Team Leader will work
with the initiator, the Angelo State Project Managers, SCT and any
other appropriate parties to complete the Change Request form.
The forms will include the following information:
•
•
•
•
•
March 13 2007
Tracking Number
Requestor
Date of Request
Implementation Area
Module and Form
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 73 of 117
•
•
•
•
•
•
9.5.6.2
Description of current process, screen, report, database element, or
rule
Description of changes to process, screen, report, database
element, or rule
Justification for changes, i.e. reduction in keying, more efficient
screen navigation, data not currently retained, more accurate
reporting
Dependencies, i.e. other areas that will be impacted by the change
and must be consulted
Priority of the change, i.e. business critical; efficiency improvement –
not business critical; process related – not business critical; nice to
have; etc.
Team Leader approval
Review and Estimate Change Request
After the Team Leader completes and approves the Change Request, it will
be submitted to ASU Project Managers for review. The ASU Project Manager
will review the following:
•
•
•
•
•
•
Appropriateness of the Request, including justification and priority.
If the Change Request should be incorporated to the
implementation or into a later enhancement phase.
Completeness of technical information on forms, reports, database,
rules, etc.
Clarity of Request.
Do other areas need to be involved in the review and approval
process?
Identify potential impacts on Area Project and dependent Project
Plans.
After the Project Management Team reviews and approves the request, the
ASU technical staff will be responsible for estimating:
•
•
•
•
Level of effort required to implement the change.
Number of resources needed for such an effort.
Cost
Impact on schedule, costs and resources.
The ASU Project Manager will return the request to the initiator for clarification
of rework if needed. The ASU Project Manager will also prepare comments
and suggested disposition of the Request for review by Change Control Board
and update the Project Library. If the request impacts ASU policy or the
project budget, the Executive Sponsor or Steering Committee will review the
request to make the final decision.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 74 of 117
9.5.6.3
Submit and Approve Change Request
The ASU Project Manager will:
•
•
•
•
•
9.5.6.4
Present requests to the Steering Committee for final disposition.
If the request is approved, the project manager will incorporate the
change into the appropriate planning documents and identify impact
on the overall plan.
If the request is approved as a future enhancement, identify a time
frame when the request will be completed.
Update the Project Library.
Inform all concerned of the final disposition.
Track and Report Change Request
The following steps will be followed to track and report changes.
•
•
•
All Change Requests will be entered into the tracking database.
The status of all Change Requests will be included on the monthly
Project Status Reports.
A tracking number will be assigned and used as a reference.
Final disposition and status will be tracked into tracking database.
9.5.6.5
Control Work Product Changes (Baselining)
For the purpose of this project, once SCT and ASU accept a plan or a work
product, it will be baselined (Refer to section 9.5.4.1 for a list of documents
under Configuration Management). Once a project or a work product has its
initial baseline set, that baseline will NOT be modified unless an authorized
change request or work product request has been issued. The Report History
section will be used to document changes against baseline.
Any Change Request or other authorized Work Product Request must be
incorporated in the Plan. The tracking number assigned will be used to
identify this new task in the plan. Plans will be updated periodically on an as
needed basis with any request, modifications to scope, or other items.
Reports will be generated from the project plan to clearly identify any impacts
on schedule, resource allocation, and/or cost and reviewed with the Team
Leaders. The revisions will also be included in the regular status reports. In
addition to the project plan update, the status report should reflect a brief
narrative statement of the impact on the plan of any requests that have been
incorporated during the reporting period.
9.5.6.6
Record and Manage Action Items
Action Items are generated from formal and informal meetings,
videoconferences, conference calls, etc. Action Items from formal meetings
will be documented in the Meeting Agenda and Minutes. Action Items from
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 75 of 117
informal meetings will be documented on a Meeting Minutes form. All Action
Items will be tracked. Action Items will contain the following information:
•
•
•
•
Description of the Action Item
Owner/Assigned To
Due Date
Completion Date/Status
Action Items will be entered, updated, tracked and reported through the
project Library.
9.5.6.7
Record and Manage Jeopardy Items
Jeopardy Items must be tied to an identified Risk. If the Risk/Jeopardy is not
in the Risk Matrix, the Matrix must be updated. The Jeopardy Item must be
documented and include the following information:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Tracking Number
Reference to Project Definition information
Priority
Description
Owner/Assigned To
Origination Date
Due Date
Completion Date/Status
Impact Assessment
Action Plan & Assessment
Other Alternatives
Resolution
Individuals Responsible for Execution/Completion
Stakeholders/Other Interested Parties
Approvals
Comments
Depending on the priority level, Jeopardy Items may require review and
approval by the Steering Committee. Jeopardy Items will be entered,
updated, tracked and reported through the tracking database. Jeopardy Item
reports will be included in the regularly scheduled status reports and
individual task lists generated as needed.
9.5.6.8
Record and Manage Issues
Issues are items that are not covered under any of the other categories. The
Issue must be documented and include the following information:
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 76 of 117
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Tracking Number
Reference to Project Definition information
Priority
Description
Owner/Assigned To
Origination Date
Due Date
Completion Date/Status
Impact Assessment
Action Plan & Assessment
Other Alternatives
Resolution
Individuals Responsible for Execution/Completion
Stakeholders/Other Interested Parties
Approvals
Comments
Depending on the priority level, Issues may require review and approval by
the Steering Committee. Issues will be entered, updated, tracked and
reported through the tracking repository. Issue reports will be included in the
regularly scheduled status reports and individual task lists generated as
needed.
9.5.6.9
Perform Configuration Management Reporting
The Project Managers will be responsible for performing CM Reporting in
conjunction with Project Status reporting.
No separate CM Reports will be developed and distributed.
9.5.7
Configuration Management Team
The ASU Project Manager will be responsible for creating and executing plans
to meet the scope and objectives noted above.
9.6
Change Management
9.6.1
Introduction
The Portico Project will bring about significant business change at Angelo
State University and the success of this project will depend, in part, upon the
effectiveness with which this change is managed. The purpose of this section
is to present an overview of change management, identify major change
management activities, and describe the major tasks for each of these
activities.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 77 of 117
9.6.2
Overview of Change Management
Change projects fail more often from lack of effective change management
than any other single reason. Project teams that ignore change management
cite this as one of the “most important lessons learned” during their project.
Teams that use change management techniques have:
•
•
•
Reduced turnover and the loss of valued employees.
Accelerated the implementation of the change.
Reduced productivity loss and employee resistance.
What many teams lack, however, is a solid understanding of what change
management is and how to implement change management tactics. The
following provides an overview of change management that can help a team
manage change effectively.
9.6.2.1
What is change management?
Change management can be viewed from two perspectives – from those
implementing the change and from the recipients of change. Your view of
change management varies dramatically if you are the executive demanding
the change versus the front line employee who may be unsure why a change
is even needed.
In many cases at the onset of a new change, neither the executive nor the
front-line employee is knowledgeable about managing change.
The
executives want the change to happen now; the employees are simply doing
their job. It is the project managers, consultants, or members of the project
team that first learn about the necessity for change management. They are
the first to realize the two dimensions of change management: the top-down
managers’ perspective and the bottom- up employees' perspective.
9.6.2.2
A closer look
The managers’ perspective on change is results oriented. They are very
aware of the business issues facing the organization and are accountable for
the financial performance and business operation of the organization. When
a change is needed, they require action quickly.
In many cases, executives must weigh the return on investment of this
change as compared to other strategic initiatives in the institution. Their
primary concerns are:
•
•
•
•
March 13 2007
When can the change be completed?
How much improvement will be realized?
How will this change impact our financial performance?
What is the required investment?
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 78 of 117
•
How will this change impact our customers?
If the answers to these questions are favorable to the executives, then the
directive to a project manager or project team is typically “let’s get it done.”
9.6.2.3
Another view
Now consider the perspective of front-line employees (and in many cases
their supervisors and managers within the organization). They generally
focus on day-to-day operations. Serving customers, processing transactions,
getting the job done – these are the primary areas of interest; these tasks are
combined with a number of personal issues that we all face every day.
When changes are made, many employees lack the broader context or
knowledge base of why the change is being made. They also do not share
the same accountabilities as managers. They question, therefore, how the
change will impact them personally.
To complete the picture, consider the consultant or project team who is
responsible to design and implement the change. They have their own
agenda acting on behalf of the business leaders who charted the change.
The result is a potentially dangerous mix of different priorities, different
knowledge sets, and different driving forces. If the change is not managed
properly, these different values and driving forces clash resulting in
unfortunate outcomes for the business.
•
•
•
•
•
Employees resist the change.
Valued personnel leave the organization.
Critical projects are delayed.
Customers feel the impact indirectly through upset employees.
Productivity declines.
Many organizations learned the hard way through failed projects. They
learned that change management is not something addressed after the fact.
Change management must start at the beginning of the project and be
integrated into all facets.
The two perspectives of change management can be referred to as
organizational change management, and individual change management.
Organizational change management is the management of change from the
perspective of the executive of project manager. The focus is around broad
change management practices and skills that will help the organization
understand, accept, and support the needed business change. The primary
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 79 of 117
activities are change management strategies, communication plans, and
training programs.
Individual change management is the management of change from the
perspective of the employees. They are the ones who ultimately must
implement the change. The focus here is around the tools and techniques to
help an employee transition through the change process. The primary
concerns involve the coaching required to help individuals understand their
role and the decisions they make in the change process.
So what is change management? Change management is the effective
management of a business change such that executives, managers, and front
line employees work in concert to successfully implement the needed
process, technology, or organizational changes.
The goal of change management is to implement these business changes
quickly to:
•
•
•
•
Minimize the impact on productivity.
Avoid unnecessary turnover or loss of valued employees.
Eliminate any adverse impact on customers.
Achieve the desired business outcomes as soon as possible.
9.6.3
Critical Activities for Managing Change
9.6.3.1
Develop Organizational Readiness
The purpose of Organizational Readiness is to ensure that those outside of
the Project Team are ready to support the project's deliverables.
Organizational readiness is defined as having:
•
•
•
The necessary resources to support the deliverables of the project.
The personnel with the required knowledge to support the
deliverables of the project.
The appropriate work products to support the deliverables of the
project.
The main objectives of Organizational Readiness are:
•
•
•
March 13 2007
Identify and execute the activities required to prepare ASU for the
project “start-up.”
Develop plans to prepare all departments for Banner and Luminis
training.
Identify and develop the work products needed by those outside of
the project team to support the deliverables of the project.
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 80 of 117
9.6.3.2
Manage Communications
The communication plan explains how project status and other information
will be communicated for what audience using what medium and content and
in what frequency. Representative communications strategies include: a
formal communications plan, pro-active informal communications, specific
attention to barriers and resistance to change, open forum and focus group
meetings with the ASU community, the availability of current project
information via the Web, periodic review of similar projects at other similar
institutions, utilization of feedback to improve project communications and
training, and the development of lesson learned at the end of each major
phase of the project.
During this activity, various project communications will be initiated, including
communications within the project team and between the project and
stakeholders. When structuring project communications, the following things
should be considered:
•
•
•
•
•
Communication planning
Information distribution
Performance reporting
Administrative closure
Managing effective meetings
The following diagram illustrates the typical processes:
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 81 of 117
Tasks and subtasks include:
•
•
•
•
•
•
•
•
•
•
•
March 13 2007
Identify appropriate communications channels for the various
audiences.
Determine types of information and frequency of sharing.
Create formats for status report and other communiqués.
Determine tools for obtaining feedback for the project team.
Identify measures of communication effectiveness.
Develop schedule for formal communication events.
Hold formal communication events according to schedule.
Schedule informal events as needed (just-in-time).
Solicit feedback from communication events.
Route to appropriate working team.
Use to improve communication plan.
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 82 of 117
9.6.3.2.1 Communication Plan
The following presents a sample outcome of the communications plan. Some
of the events displayed in this table may change as the project evolves and
different communications needs emerge.
Event
Project kickoff
Project
Awareness
Steering
Committee
meetings
Project
Management
team meetings
Implementation
Team meetings
Process Team
meetings
Internal project
communications
Project status
reports (oral
presentation)
Project status
reports (written)
Campus forum
Project
announcements
Project reports
Individual queries
Individual
coaching
Small group
coaching
March 13 2007
Audience
Channel
Key stakeholders Meeting
Project team
ASU community E-mail
Campus news
media
Steering
Meeting
Committee
Frequency
As Required
As Required
Twice a Month
Project
Management
Team
Implementation
Team
Core Process
Teams (currently
active)
Project Team
Meeting
Weekly
Meeting
Meeting
Weekly (initially),
then Monthly
Monthly
E-mail
As needed
Steering
Committee
Meeting
Monthly
Project Team
ASU Community
ASU Community
ASU Community
E-mail
Web site
Meeting
E-mail
Web site
Campus news
media
Meeting
Monthly
Existing campus
committees,
department
meetings
Individuals and
small groups
E-mail
Individual
meetings
Small group
meetings
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Quarterly
As needed
As needed
As needed
Page 83 of 117
9.6.3.2.2 Meetings
This section describes type and frequency of project meetings at ASU.
Team
Executive Team/
Steering Committee
Frequency
Meet as needed, but
not less than monthly
Implementation Team
Weekly, initially
Monthly, as the project
progress Monthly
Monthly
Core Process Team
Purpose
Discuss project
progress
Resolve Issues and
Jeopardies
Discuss project
progress
Write Status Report
Attend Training as
required
Complete Training
Assignments
Execute
Implementation
Activities
Prepare Status Report.
9.6.3.2.3 Communication Channels
The official channel for communications between Project Team Members will
be email. Meeting invitations, status reports, etc. will be communicated by
email.
All members will access email with sufficient frequency to
acknowledge invitations in a timely way.
Primary communications channel between ASU and SCT teams will be email.
For urgent issues, ASU will send a voice mail to the SCT Project Manager
and any other affected SCT parties. For urgent issues, SCT will call at the
office or cell phone to the ASU Project Manager.
The SCT Project Manager will deliver a written status report after each onsite
visit to the ASU Project Manager. The SCT Project Manager will also be
available in person to present status and otherwise participate in Team
meetings, to the extent reasonably possible and in accordance with the
contractual provision for Level 2 SCT Project Management. All significant
documents created during the project will be made available to ASU
employees via Intranet; documents will also be distributed via email when
necessary. Documents include this project definition, project plans, etc.
Documents will be shared unless explicitly designated as confidential.
Definitive copies of project documents will be stored as noted in the Library
clause of the Change Management section above.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 84 of 117
9.6.3.3
Manage Training
The purpose of the Training Plan is to enable ASU to deliver information
about the new system in a manner that is easily understood and quickly
assimilated by the target groups. It is critical that this plan sets common
expectations among the stakeholders about the training. The Training Plan
identifies the various groups that need to be trained, the training curriculum for
each group, the mode of training for each piece of the curriculum, the
approximate time frame and locations for the scheduled training sessions, and
accommodations for just-in-time training. The Change Management Team
will determine how each training session will be delivered (e.g., internal staff,
external trainers) and will coordinate the delivery. A separate Training Plan
document can be found in the “Planning” section of the Portico Library.
9.6.3.4
Document Lessons Learned
This activity evaluates ASU's level of success in adapting to and absorbing
the changes imposed by the Portico Project. This activity consists of three
tasks; conduct project review interviews, document results, and deliver a
“lessons learned” presentation to the project team and key stakeholders. The
purposes of this activity are to preclude "reinventing the wheel" on future
initiatives and to determine:
•
•
•
•
•
•
•
•
•
•
•
•
9.7
How successful was the overall project approach?
Were we able to implement “Best Practices” as planned? What
were the challenges?
What were the enablers and/or obstacles encountered by the
project?
How well was the organization prepared?
How well was the project accepted by the organization?
How effective was the decision making and problem solving
strategy?
How effective was the employee involvement strategy?
How well did people work together on the project?
How well did the project team function as a team?
How effective was communication with stakeholders throughout the
project?
How could the project have been improved?
What actions should be taken in the future to help ensure
successful implementation?
Documentation
The ASU Project Manager is responsible for overseeing the documentation
efforts at ASU. The implementation Team will be responsible for defining the
scope of the documentation efforts for the Banner and Luminis
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 85 of 117
Implementation Project as well as the development of a standard format to be
used.
Each Team Lead will be responsible for coordinating the
documentation needs of their corresponding areas.
Each Team Lead will be responsible for creating an End User Manual for
each Banner Application. Such manuals are necessary to assist the
functional areas in the use of the system. The Banner documentation as
supplied by SCT is generic and broad. It will not reflect the specific
configuration choices made by ASU, and it contains material not relevant to
end-users.
To supplement each manual, ASU will create an end user Quick Reference
Card for each Banner application. These manuals and quick reference cards
must be in place in time to train end users.
ASU will create Data Standards Guidelines to which each component system
and module must adhere to ensure data integrity and consistency of results
across systems. All affected users will be trained in the use of the Data
Standards Guidelines and will be given online access to it. The Data
Standards Team will consider a mechanism for monitoring and enforcing
adherence to the Data Standard Guidelines.
9.8
Measurement
This section describes the metrics that will be captured for the project, and the
approach for collecting and analyzing each metric. An example of a metric is
actual effort. An example of a collection approach is time sheets with specific
project and task codes.
9.8.1
Defined Metrics
The metrics to be captured for the project include:
• Project Schedule
• Project milestone dates are met
• Project milestone dates not met
• Budget
• Hours are within budget as defined in contract, project schedule, or
Project Definition
• Functionality - will be measured by the number of issues and
incidents open on a project deliverable and accepted by the Client.
• Project deliverables met or not met
• Project objectives met or not met
• Training
• # of people trained
• Satisfaction of trainees
• End User Acceptance
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 86 of 117
•
•
•
9.8.2
Collection and Analysis Methods
•
•
•
•
•
•
•
9.9
Usage level of Web access
User satisfaction surveys (student, faculty, staff, community)
“Best Practices” followed and adopted
Project Schedule - From the milestones denoted in the Project
Definition Document (PDD), determine the appropriate part of the
Project Schedule that corresponds to the milestone. Determine
whether the finish date in the Project Schedule matches the
scheduled milestone completion date in the PDD.
The project will be considered on schedule if the milestones are
met, and the date of the completion of the project does not change.
Approved change requests will be taken into consideration.
Budget - From the hours denoted in the Project Schedule,
determine the appropriate total hours that correspond to the
deliverable. Determine whether the completed actual hours in the
Project Schedule match the scheduled planned hours.
The project will be considered within budget if the total actual hours
are equal to or less than the planned hours. Approved change
requests will be taken into consideration.
Deliverables – From the number and list of deliverables identified in
the PDD.
Deliverables will be considered completed if the approved, certified
or accepted by the user. Approved change requests will be taken
into consideration.
Objectives - From the number and list of project objectives
identified in the PDD. Objectives will be considered completed if
approved, certified or accepted by the user. Approved change
requests will be taken into consideration.
Quality Assurance
Quality is important in every aspect of the Portico project. It is an outcome
that must be planned, and controls must be in place to ensure that quality is
woven into each task to ensure that deliverables are:
•
•
•
•
On time
Within budget
Produced accurately and according to specifications and standards
that meet project needs and expectations
In a manner that is perceived by the University as successful
Quality involves the achievement of a critical balance among various project
variables because it is impossible to simultaneously maximize the project’s
quality, budget, and schedule. A project can be completed very quickly and at
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 87 of 117
low cost, but quality will undoubtedly suffer. Similarly, a high-quality project
can be completed with a tight budget, but the project schedule will be
elongated as factors such as overtime and extra high cost resources are kept
to a minimum.
The purpose of a quality assurance process is to maintain an appropriate
balance between these factors through pre-designated review points
performed by senior professionals and through on-going project activities
such as informal reviews and team reviews. It is designed to help ensure that:
all project work is done in accordance with stringent standards of quality,
reviews and input are incorporated into both functional and technical project
work, and project work is performed to the satisfaction of the University.
A detailed quality assurance (QA) plan is not included in this document, but
has been developed as two separate plans that complement each other in
managing the quality of the project. The first QA plan focuses on SCT’s
project management responsibilities. The second QA plan focuses on ASU’s
approach and perspective for implementing and managing the project. ASU’s
QA plan will be conducted by ASU personnel (including Internal Audit) and
external resources. These two quality assurance documents can be found in
the “Planning” section of the Portico Library.
9.10
Tracking
This section describes the timing of periodic review meetings and scope
reassessment events that will trigger review meetings.
The schedule compliance and project controls process is initiated through a
planned effort to create a project plan and a project schedule baseline against
which all projects performance is measured.
The project plan will contain a hierarchical Work Breakdown Structure (WBS)
that clearly identifies and describes all activities and tasks required performing
necessary work. The WBS hierarchy supports the development of the project
schedule baseline.
Using the WBS as the base of information, the team performing the project
work creates internal plans and schedules to clearly identify detailed tasks
that must be accomplished to complete key project activities and milestones.
Expenditure Controls
The project managers will monitor and control the costs, schedule, and
performance of the project. Team members will report progress to their team
lead and he/she in turn will report a summary status to the Project
Management Team. The activities defined below support this process:
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 88 of 117
•
•
•
•
•
•
•
9.11
Track detailed progress against each activity and task, re-assess
personal commitment, and re-forecast the remaining effort to
completion and the expected completion date, on a regular weekly
basis.
Summarize on a weekly basis and communicate the
accomplishments for the reporting period, the objectives for the
coming period, problems (if any), the status of outstanding risk
items, and suggestions for dealing with issues and problems.
Assess the project's status and keep this visible to senior
management in the customer and delivery organization on a
monthly basis.
Analyze cost and schedule variances from plan and implement
corrective action.
Report summarizing cost and schedule status and analyzing
variances in accordance with the earned value technique.
Maintain a current and reliable version of the project work plans,
based on approved changes and current estimates to completion.
Up-to-date versions of the project work breakdown structure,
schedules, and financial plan that define how the project is to be
delivered.
Risk Management
Risks are identified at the beginning of the project and throughout the project.
When a Risk is identified, Mitigation Actions and Contingency Plans are
developed and recorded in the Work Product’s database. The Project
Manager manages the Risks by executing Mitigation Actions, which may
include how the contingency plans will be implemented and how the reserves
will be allocated. If a Risk materializes, it is escalated to a Project Issue or
Jeopardy by executing the Identify and Resolve Issues or Identify and
Resolve Jeopardies activities. Risk Contingency Plans may become the
Project Issue or Jeopardy Action Plan. The following diagram identifies the
items that will be managed and tracked throughout the duration of the project.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 89 of 117
Risk Management will follow the approach spelled out in SCT's CSM. CSM
process documentation will be made available in the form of Web pages by
SCT upon request of any ASU team member. Highlights of the approach are
documented below.
In Section 7 above, risks are identified and prioritized, and response
strategies are outlined.
A separate Risk Management Plan will be prepared to document the
responsible party for all risk responses, completion dates for preventive
responses, and plans for ongoing risk management. The ASU and SCT
Project Managers will initially draft this plan, which will then be fleshed out by
the Project Team.
The general approach to risk management will be as follows:
•
•
March 13 2007
Risks are identified at the beginning of the project and throughout
the project. When a Risk is identified, it is documented in the project
repository. Preventive and/or contingent responses are identified in
the Risk Management Plan.
Risks are identified at the beginning of the project and throughout
the project. When a Risk is identified, it is documented in the project
repository. Preventive and/or contingent responses are identified in
the Risk Management Plan.
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 90 of 117
•
•
The Project Manager manages the Risks by executing Mitigation
Actions, which may include how the contingency plans will be
implemented and how the reserves will be allocated.
If a Risk materializes, it is escalated to a Project Issue or Jeopardy
according to CSM protocol. The Issue or Jeopardy is then
accepted or resolved according to the Risk Management Plan.
Risk, Issue, and Jeopardy reports will follow the CSM template, which can be
found in the CSM process documentation mentioned above
9.11.1
Escalation Plan
The escalation plan includes provisions to handle risks, issues, problems, and
jeopardizes.
Type of Activity
Project level issue requiring internal
closure, low impact on deliverables
Project level issue that will impact
project deliverables if not resolved in
a timely fashion
Project level issues as above that
are not resolved expeditiously
Issues that require management
involvement
All issues that present significant
client pain, exposure or performance
issues
All Jeopardies that indicated that the
project may not be able to achieve
its scope, schedule, cost or quality
objectives
10
Escalation Level
Process Team Leaders, Project
Team
Process Team Leaders, Project
Team, Project Management Team
Process Team Leaders, Project
Team, Project Management Team,
Steering Committee
Process Team Leaders, Project
Team, Project Management Team,
Steering Committee
Process Team Leaders, Project
Team, Project Management Team,
Steering Committee
Process Team Leaders, Project
Team, Project Management Team,
Steering Committee
System Requirements
System Requirements are items that are necessary in order to run any related
software required for project. This includes hardware and software needs. The
following are examples.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 91 of 117
10.1
Database Server Requirements
6 Sun Fire V240 Servers
1 Database server
2 App Web server
3 Self Service server
4 Work flow server
5 Test database server
6 Test app/self service server
10.2
2 1-GHz UltraSPARC IIIi Cu Processor w/
1-MB L2 Cache Each, 2-GB Memory
2 36-GB 10000 RPM Ultra 3 SCSI Drives
4 10/100/1000-Mbps Ethernet Ports,
Internal DVD-ROM Drive
Solaris 8 Pre-Installed
2CPU, 4GB RAM, 2 mirrored internal
drives, access to external disk array
(beginning with 200GB).
2 GB of RAM and Fibre HBAs to connect
to the external storage.
2CPU, 4GB RAM, 2 mirrored internal
drives.
2 GB of RAM and Fibre HBAs to connect
to the external storage.
2CPU, 2GB RAM, 2 mirrored internal
drives.
2CPU, 4GB RAM, 2 mirrored internal
drives.
2 GB of RAM and Fibre HBAs to connect
to the external storage.
1-2 CPU, 2GB RAM, 2 mirrored internal
drives, access to external disk array
(beginning with 100GB).
1-2 CPU, 2GB RAM, 2 mirrored internal
drives.
PC Client Requirements
All PC client requirements will be evaluated prior to deployment within each
functional area. At this point, we expect all client computers on campus to
adequately support the Banner system.
10.3
Developer Requirements
A “developer” is defined as the person who is going to create the project’s
product. The “developer requirements” are defined to be those requirements
of the developer’s desktop PC in order to complete the work.
Banner 6.0 will require a minimum of Oracle 9i, Release 2 database.
It will be utilizing Oracle Developer 6i (Forms and Reports 6i)
and also will use Oracle 9iAS Release 1. It will require a minimum of Oracle
Developer 6i Patch 13.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 92 of 117
11
Project Deliverables
The following list contains deliverables that are contractually required to be
delivered as well as the internal materials created by the project that will be
turned over to ASU.
Item
Agendas For Training Classes
Banner Training Materials
Business Practice Analysis Documents
Communication Plan
Computer Operations Manual
Conversion Guides
Data Entry Standards
Data Migration Mapping Documents
Data Migration Plan
Security Plan
Defining Rules And Validations
Disaster Recovery Plan
Documentation Plan
End User Training Materials
End User Training Plan
Prioritized Service Requirements
Project Definition Document
Project Management Status Reports
Project Schedule
Quality Assurance Plan
Report Design
Report Strategy Plan
Reports
System Education Plan
Test Plan
Testing Cases
Trip Reports
Verification Plan
12
Responsibility of
SCT
SCT
ASU
ASU
ASU
SCT/ASU
ASU
SCT/ASU
SCT/ASU
ASU
ASU
ASU
ASU
ASU
ASU
SCT/ASU
SCT/ASU
SCT/ASU
SCT/ASU
SCT
ASU
ASU
ASU
SCT/ASU
SCT/ASU
ASU
SCT
ASU
Project Success Criteria
The project is considered successfully complete when the project objectives
have been met. Criteria include:
• All issues and action items have been completed and signed off.
• All required work products have been produced.
• All deficiencies have been logged and signed off.
• Verification that the project has met project and ASU standards.
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 93 of 117
•
•
•
March 13 2007
Validation that the product meets the requirements.
Successfully completed functional and physical configuration
audits.
A project termination statement exists.
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 94 of 117
13
14
Approval to Proceed
Don Coers
Provost and Vice President For
Academic & Student Affairs
7/05/2006
Sharon Meyer
Vice President For Finance and
Administration
7/05/2006
Shirley Morton
Administrative Assistant &
Coordinator of Special Activities
7/05/2006
Doug Fox
Associate Vice President for
Information Technology & CIO
7/05/2006
Patricia Zepeda
SCT Project Manager
7/05/2006
Walt Glass
SCT Account Manager
7/05/2006
Document History
Revision Record
Date and
Number
Sections
0.1
12/4/0312/19/03
0.1
1/8/04
0.2
0.2
1.0
1.0
March 13 2007
2/13/04
2/27/04
3/1/04
3/4/04
Author
Notes
P. Zepeda
Initial Draft
P. Zepeda
Incorporate RPM and AM
recommendations
Draft
Draft
Proposed Baseline
Adjustments made to the Proposed
Baseline. QA Section Refined,
Process Improvement Section
Refined, Changed Student Milestone
for Faculty Self Serve from 5/1/06 to
4/1/06, updated Finance
Measurement under Objective #1 and
#3, updated HR Measurement under
Objective #2 and #3, changed
milestone date for HR self service,
B. Braden
B. Braden
B. Braden
B. Braden
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 95 of 117
2.0
8/2/04
3.0
5/17/05
March 13 2007
and applied minor formatting changes.
P. Dowler & o Changed reference of Portico
Share Drive to J: from R:
Brian Braden
o Extended Planning to 9/1/04;
o Changed Finance Go-Live Dates
from 9/1/04 to 9/13/04;
o Changed HR Time Entry Self
Service Milestone from 3/1/05 to
6/1/05;
o Changed Finance Self Service
Milestone from 8/1/05 to 6/1/05;
o Luminis Timeline and Approach
Adjusted;
o Updated Timeline and
Organizational Chart
Graphics;
o Added Patrick Dierschke to lead
Training & Communications as
well as be a part of Project
Management and Implementation
Teams;
o Added Paula Dowler to be part of
the Project Management and
Implementation Teams;
o Added Doug Fox to lead
Reporting Strategy Work Team;
o Added Charles McCamant to lead
Degree Audit/Student Advising
Work Team;
o Added Degree Audit/Student
Advising Work Team members;
Annette Roberts, Andrew Ruiz,
John Miazga, Gayla Trotter, and
Susan Neste;
o Added Martin Mills to be part of
the Technical Team;
o Added Colegate Spinks to lead
Interface Work Team;
o Replaced Mary Ragland
assignments with Cam Stone;
o Replaced Nancy Montano
assignments with Felix Marquez
and Jody Casares;
o Added Change Request Process
Diagram.
P. Dowler
o Changed Luminis Deployment
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 96 of 117
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
March 13 2007
Dates;
Changed Portico Vision and
Mission to incorporate Luminis;
Added Objectives and
Measurements of Success for
Luminis;
Changed HR Self Service Go-Live
Milestones;
Changed Finance Self Service
Go-Live Milestones;
Changed Advancement Go Live
Date from 8/1/05 to 8/22/05 due to
graduation date;
Revised Financial Aid milestone
dates to reflect SCT
recommendations for
implementation;
Revised Student milestone dates
to reflect SCT recommendations
for implementation;
Added Jackie Droll to Data
Standards team and changed
team lead from Cam Stone to
Jackie Droll and Sarah Logan;
Changed Jackie Droll’s title from
Coordinator of Graduate
Admissions to Academic Services
Project Manager;
Added Jackie Droll and Charles
McCamant to Project
Management Team;
Deleted Martin Mills from
Technical Team;
Changed Advancement Technical
Lead to Ryan Webb and added
him to the Data Migration Team;
Technical Team, Security Work
Team and Interface Team
Deleted Don McCollum from
project areas;
Replaced Jody Casares with
Dana Evans in the HR area;
Changed Doug Fox’s title from
Director of Technology to
Associate VP for Information
Technology and CIO;
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 97 of 117
o
o
o
o
o
o
4.0
7/05/06
P. Dowler
o
o
o
o
o
o
o
o
o
o
o
o
March 13 2007
Changed Student Registrar Team
Lead to Cindy Weeaks;
Added Cindy Weeaks and Charles
McCamant to Implementation
Team;
Added Cindy Weeaks to Data
Standards Team;
Replaced Cam Stone with Cindy
Weeaks on the Report Strategy
and Security Work Teams;
Replaced Annette Roberts on the
Degree Audit Team with Meghan
Pace;
Added Jana Sparks to the Degree
Audit Team.
Changed Undergraduate
Recruitment Go-Live from
October, 2005 to August, 2006;
Changed Transfer Articulation GoLive from October 25 to December
15, 2005;
Shifted HR Self Service
management to Vice President for
Finance and Administration;
Changed Advancement Self
Service Go-Live Date from
12/5/05 to 5/5/06;
Changed Luminis Phase II GoLive from December 2005 to
December 2006;
Shifted Finance Self Service
management to Vice President for
Finance and Administration;
Postponed implementation of
Workflow until 2007;
Changed TSI New Student GoLive Date from October, 2005 to
2/28/06;
Set TSI Current Student Go-Live
date to 3/31/06;
Changed CAPP Go-Live Date
from 4/3/06 to 9/1/06;
Deleted Sheryl Kanaga from
Project Committees;
Deleted Laura Billings from
Project Committees;
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 98 of 117
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
March 13 2007
Replaced Sande Harrison with
Lynsey Flage on Alumni Relations
related committees;
Changed Tech Support for
Advancement to Christine Burrell;
Changed Ryan Webb’s title to
Database Administrator;
Added Angela Balch to the
Implementation Team;
Deleted Paula Baxter from the
Financial Aid Team;
Removed Vicki Harris, SCT from
the Organizational Structure;
Changed Housing Applications
Go-Live to 3/27/06;
Replaced Bonnie Stennett with
Amanda Taylor on the Student
Team;
Replaced Nancy Adams with June
Moore on the Advancement
Team;
Changed Student Accounts
Receivable Go-Live date from
6/30/06 to 08/07/06;
Changed Financial Aid
milestones: Packaging from
4/1/06 to 5/28/06, Award Letters
from 4/1/06 to 5/25/06, Loan
Processing from 4/15/06 to
5/28/06, COD Updates from
4/15/06 to 9/01/06;
Added Financial Aid module
Student Employment Go-Live
Date of 9/1/06;
Changed Advancement Self
Service Go-Live Date from 5/5/06
to 7/10/06;
Changed and removed objectives
to match milestones approved by
change requests;
Replaced Mike Ryan with Shirley
Morton on the Steering
Committee;
Replaced Priscilla Jones with
Carol Diminnie on the
Implementation & Student Teams.
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 99 of 117
15
Acronyms
Acronym
TCC
ASU
OR
PDD
CM
QA
16
Description
Texas Connection
Angelo State University
Organizational Readiness
Project Definition Document
Configuration Management
Quality Assurance
Definitions
Term
BPA
Best Practices
ERP
Portico Project
SCT
TCC
March 13 2007
Definition
Business Process Analysis. The methodology for
analyzing and documenting current and future
business processes in such a way that they can be
used as a communication and planning tool.
The term “Best Practices” refers to the processes that
are built into the SCT Banner software. By selecting
the SCT Banner software system we are adopting
these “Best Practice” processes to replace our
existing processes.
The industry term for the suite of administrative
systems is ERP which stands for Enterprise Resource
Planning. The definition of ERP describes how an
organization should view its administrative systems at
an enterprise level instead of individually.
This is the name of ASU’s ERP project which means
“gateway” or “entrance”. Think of the Portico project
as “ASU’s Gateway to the Future”.
SCT is the company that ASU selected to provide the
new ERP software for the campus.
The Texas Connection Consortium was setup by
Texas universities and SCT to satisfy reporting needs
for the state level. The new Finance and Human
Resource systems are scheduled to have the TCC
modifications developed for Banner during the Portico
Project.
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 100 of 117
APPENDIX A: Project Participants from ASU
Executive Sponsor
Role or Area of Representation
Vice President for Finance &
Administration
Member Name
Phone/FAX Number
Email Address
Sharon Meyer
(325) 942-2017 x258
(325) 942-2271
Sharon.Meyer@angelo.edu
Steering Committee
Role or Area of Representation
Provost and Vice President for
Academic and Student Affairs
(Steering Committee Member)
Vice President for Finance &
Administration (Steering
Committee Member)
Administrative Assistant &
Coordinator of Special Activities
(Steering Committee Member)
Associate VP for Information
Technology & CIO (Steering
Committee Member)
March 13 2007
Member Name
Phone/FAX Number
Email Address
Dr. Don Coers
(325) 942-2165 x286
(325) 942-2128
Don.Coers@angelo.edu
Sharon Meyer
(325) 942-2017 x258
(325) 942-2271
Sharon.Meyer@angelo.edu
Shirley Morton
(325) 942-2116 x265
(325) 942-2218
Mike.Ryan@angelo.edu
Doug Fox
(325) 942-2333 x222
(325) 942-2109
Doug.Fox@angelo.edu
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 101 of 117
Project Management Team
Role or Area of Representation
Project Manager
Project Technical Lead
Project Assistant
Technical Training/Communications
Specialist
Coordinator of Process Integration
Academic Services Project Manager
Member Name
Phone/FAX Number
Email Address
Brian Braden
(325) 942-2333 x238
(325) 942-2109
Brian.Braden@angelo.edu
Jeff Sefcik
(325) 942-2333 x224
(325) 942-2109
Jeff.sefcik@angelo.edu
Paula Dowler
(325) 942-2385 x 28
(325) 942-2382
Paula.Dowler@angelo.edu
Patrick Dierschke
(325) 942-2385 x33
(325) 942-2382
Patrick.Dierschke@angelo.edu
Charles McCamant
(325) 942-2385 x32
(325) 942-2382
Charles.McCamant@angelo.edu
Jackie Droll
(325) 942-2385x31
(325) 942-2382
Jackie.Droll@angelo.edu
Implementation Team
Role or Area of Representation
Project Manager
Controller
March 13 2007
Member Name
Phone/FAX Number
Email Address
Brian Braden
(325) 942-2385 x30
(325) 942-2382
Brian.Braden@angelo.edu
Denise Brodnax
Controller
(325) 942-2014 x263
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 102 of 117
Role or Area of Representation
Admissions – Graduate
Admissions - Undergraduate
Records
Records
Records
Housing
Housing/Accounts
Director for HR
March 13 2007
Member Name
Phone/FAX Number
Email Address
(325) 942-2701
denise.brodnax@angelo.edu
Carol Diminnie
Dean
(325) 942-2169
(325) 942-2194
Carol.diminnie@angelo.edu
Elisa Hernandez
Office Coordinator
(325) 942-2185 x239
(325) 942-2078
lisa.hernandez@angelo.edu
Cam Stone
Associate Registrar
(325) 942-2043 x246
(325) 942-2553
cam.stone@angelo.edu
Cindy Weeaks
Report Coordinator
(325) 942-2043 x244
(325) 942-2553
Cindy.weeaks@angelo.edu
Angela Balch
Registrar
(325) 942-2043 x222
(325) 942-2553
Angelo.balch@angelo.edu
Connie Frazier
Director of Residence Life
(325) 942-2035 x226
(325) 942-2078
connie.frazier@angelo.edu
Martha Hicks
Accountant - Residence Life
(325) 942-2035
(325) 942-2239
Martha.hicks@angelo.edu
Felix Marquez
Director
(325) 942-2168 x270
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 103 of 117
Role or Area of Representation
Director of Development
Project Technical Lead
Director of Financial Aid
SCT Project Manager
Project Assistant
Technical Training/Communications
Specialist
Member Name
Phone/FAX Number
Email Address
(325) 942-2271
felix.marquez@angelo.edu
Rhonda McClung
Director of Development
(325) 942-2116 x234
(325) 942-2218
rhonda.mcclung@angelo.edu
Jeff Sefcik
(325) 942-2333 x224
(325) 942-2109
Jeff.sefcik@angelo.edu
Lyn Wheeler
Director of Financial Aid
(325) 942-2246 x247
(325) 942-2082
lyn.wheeler@angelo.edu
Patricia Zepeda
(817)490-5144
(469) 223-4662
pzepeda@sct.com
Paula Dowler
(325) 942-2385 x 28
(325) 942-2382
Paula.Dowler@angelo.edu
Patrick Dierschke
(325) 942-2385 x33
(325) 942-2382
Patrick.Dierschke@angelo.edu
Student Team
Role or Area of Representation
Admissions – Graduate
March 13 2007
Member Name
Phone/FAX Number
Email Address
Carol Diminnie
Dean
(325) 942-2169 x239
(325) 942-2194
Carol.Diminnie@angelo.edu
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 104 of 117
Role or Area of Representation
Admissions - Undergraduate
Undergraduate Transfer and
International Students
Undergraduate Recruiting Travel
Records
Records
Provost and Vice President for
Academic and Student Affairs
Academic Affairs
Instruction
March 13 2007
Member Name
Phone/FAX Number
Email Address
Elisa Hernandez
Office Coordinator
(325) 942-2185 x239
(325) 942-2078
lisa.hernandez@angelo.edu
Meghan Pace
Coordinator of Transfer Service/Intl
Student
(325)942-2041 x242
(325)942-2078
meghan.pace@angelo.edu
Amanda Taylor
Coordinator of Recruiting
(325)942-2041 x233
(325)942-2078
Amanda.taylor@angelo.edu
Angela Balch
Registrar
(325)942-2043 x222
(325) 942-2553
Angela.Balch@angelo.edu
Cindy Weeaks
Report Coordinator
(325) 942-2043 x244
(325) 942-2553
cindy.weeaks@angelo.edu
Dr. Don Coers
Provost
(325) 942-2165 x286
(325) 942-2271
don.coers@angelo.edu
Sam Hinojosa
Administrative Assistant
(325) 942-2165 x286
(325) 942-2271
sam.hinojosa@angelo.edu
Dr. John Miazga
Dean/Professor
(325) 942-2052 x255
john.miazga@angelo.ed
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 105 of 117
Role or Area of Representation
Housing
Bursar
Financial Aid
Advisement
Degree Audit
Schedule & Rooms
Graduation Clearance/Degree Audit
Graduation Clearance/Degree Audit
Finance
March 13 2007
Member Name
Phone/FAX Number
Email Address
Connie Frazier
Director of Residence Life
(325) 942-2035 x226
(325) 942-2078
connie.frazier@angelo.edu
Martha Cox
Manager of Student
Accounts/Bursar
(325) 942-2008 x260
(325) 942-2082
martha.cox@angelo.edu
Lyn Wheeler
Director Student Financial Services
(325) 942-2246 x247
(325) 942-2082
lyn.wheeler@angelo.edu
Dr. Susan Neste
Director of Advising
(325) 942-2710
susan.neste@angelo.edu
Brenda Stewart
Academic Advisor
(325) 942-2710 x239
brenda.stewart@angelo.edu
Judy O'Rear
Registration Assistant
(325) 942-2043 x221
(325) 942-2553
judy.orear@angelo.edu
Gayla Trotter
Administrative Secretary to the Dean
(325) 942-2024x241
gayla.trotter@angelo.edu
Jana Sparks
Administrative Secretary to the
Graduate Dean
(325) 942-2169x241
jana.sparks@angelo.edu
Denise Brodnax
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 106 of 117
Role or Area of Representation
Human Resources
Placement/ Testing
Technical Support for Student
Records
Member Name
Phone/FAX Number
Email Address
Controller
(325) 942-2014 x263
(325) 942-2271
denise.brodnax@angelo.edu
Felix Marquez
Human Resources
(325) 942-2168
(325) 942-2271
felix.marquez@angelo.edu;
Lorri Moore
Associate Director of Admissions
(325) 942-2041 x240
(325) 942-2078
lorri.morris@angelo.edu
Mark Hirt
Analyst
(325) 942-2334 x233
(325) 942-2109
mark.hirt@angelo.edu
Financial Aid Team
Role or Area of Representation
Director of Financial Aid
Disbursement Officer
Loan Processing
March 13 2007
Member Name
Phone/FAX Number
Email Address
Lyn Wheeler
Director of Financial Aid
(325) 942-2246 x247
(325) 942-2082
lyn.wheeler@angelo.edu
Martha Cox
Manager of Student
Accounts/Bursar
(325) 942-2008 x260
(325) 942-2082
martha.cox@angelo.edu
Marsha Halfmann
Assistant Director of Financial Aid
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 107 of 117
Role or Area of Representation
Technical Support for Financial Aid
Member Name
Phone/FAX Number
Email Address
(325) 942-2246 x250 phone
(325) 942-2082 fax
marsha.halfmann@angelo.edu
Cliff Taylor
Analyst
(325) 942-2334 x236
(325) 942-2109
cliff.taylor@angelo.edu
Advancement Team
Role or Area of Representation
Director of Development
Director of Alumni Relations
Director of Special Programs
Database Coordinator
Vice President for Finance and
Administration
March 13 2007
Member Name
Phone/FAX Number
Email Address
Rhonda McClung
Director of Development
(325) 942-2116 x234
(325) 942-2218
rhonda.mcclung@angelo.edu
Lynsey Flage
Director of Alumni Relations
(325) 942-2122
(325) 942-2373
lynsey.flage@angelo.edu
Shirley Morton
Administrative Assistant &
Coordinator of Special Activities
(325) 942-2116 x233
(325) 942-2218
shirley.morton@angelo.edu
June Moore
Administrative Secretary & ADS
Specialist
(325) 942-2116 x232
(325) 942-2218
June.moore@angelo.edu
Sharon Meyer
Vice President for Finance and
Administration
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 108 of 117
Role or Area of Representation
Technical Support for Advancement
Member Name
Phone/FAX Number
Email Address
(325) 942-2017 x258
(325) 942-2271
Sharon.Meyer@angelo.edu
Christine Burrell
Programmer
(325) 942-2334 x255
(325) 942-2109
Christine.burrell@angelo.edu
Report Strategy Work Team
Role or Area of Representation
Associate VP for Information
Technology and CIO
Technical Faculty Specialist
Grant & Project Accounting
Specialist
Admissions – Graduate
Undergraduate Transfer and
International Students
Records
March 13 2007
Member Name
Phone/FAX Number
Email Address
Doug Fox
(325) 942-2333 x222
(325) 942-2109
Doug.Fox@angelo.edu
Charles McCamant
(325) 942-2385
Charles.McCamant@angelo.edu
Janet Coleman
Director of Accounting
(325) 942-2014 x268
(325) 942-2071
janet.coleman@angelo.edu
Jackie Droll
Academic Services Project Manager
(325) 942-2169 x239
(325) 942-2194
jackie.droll@angelo.edu
Meghan Pace
Coordinator of Transfer Service/Intl
Student
(325) 942-2041 x242
(325) 942-2078
meghan.pace@angelo.edu
Cindy Weeaks
Report Coordinator
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 109 of 117
Role or Area of Representation
Housing (location management)
Placement/ Testing
Technical Support for Student
Records
Payroll Director
Member Name
Phone/FAX Number
Email Address
(325) 942-2043 x244
(325) 942-2553
cindy.weeaks@angelo.edu
Connie Frazier
Director of Residence Life
(325) 942-2035 x226
(325) 942-2078
connie.frazier@angelo.edu
Lorri Moore
Associate Director of Admissions
(325) 942-2041 x240
(325) 942-2078
lorri.morris@angelo.edu
Mark Hirt
Analyst
(325) 942-2334 x233
(325) 942-2109
mark.hirt@angelo.edu
Dana Evans
Payroll
(325) 942-2168 x272
(325) 942-2271
dana.evans@angelo.edu
Benefits and Compensation
Specialist
Director of Development
Director of Alumni Relations
March 13 2007
Rhonda McClung
Director of Development
(325) 942-2116 x234
(325) 942-2218
rhonda.mcclung@angelo.edu
Lynsey Flage
Director of Alumni Relations
(325) 942-2122
(325) 942-2373
lynsey.flage@angelo.edu
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 110 of 117
Data Standards Work Team
Role or Area of Representation
Director of Development
Member Name
Phone/FAX Number
Email Address
Rhonda McClung
Director of Development
(325) 942-2116 x234
(325) 942-2218
rhonda.mcclung@angelo.edu
Benefits and Compensation
Specialist
Undergraduate Transfer and
International Students
Records
Technical Support for Student
Records
Graduate Admissions
(Data Standards Co-Leader)
Purchasing Director
Institutional Planning and Research
(Data Standards Co-Leader)
March 13 2007
Meghan Pace
Coor of Transfer Service/Intl Student
(325)942-2041 x242
(325)942-2078
meghan.pace@angelo.edu
Cam Stone
Associate Registrar
(325) 942-2043 x246
(325) 942-2553
cam.stone@angelo.edu
Mark Hirt
Analyst
(325) 942-2334 x233
(325) 942-2109
mark.hirt@angelo.edu
Jackie Droll
Academic Services Project Manager
(325) 942-2385x31
(325) 942-2382
jackie.droll@angelo.edu
Margaret Mata
Purchasing Agent and HUB
Coordinator
(325) 942-2012 x249
(325) 942-2010
margaret.mata@angelo.edu
Sarah Logan
Dir. Of Inst. Planning
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 111 of 117
(325) 942-2259
sarah.logan@angelo.edu
Marsha Halfmann
Assistant Director of Financial Aid
(325) 942-2246 x250 phone
(325) 942-2082 fax
marsha.halfmann@angelo.edu
Financial Aid
Data Migration Work Team
Role or Area of Representation
Administrative Apps Manager
Technical Support for Finance
Technical Support for Financial Aid
Technical Support for Student
Records
Technical Support for Advancement
Member Name
Phone/FAX Number
Email Address
Jeff Sefcik
Manager
(325) 942-2333 x224
(325) 942-2109
jeff.sefcik@angelo.edu
Frosty Aguilar
Analyst
(325) 942-2334 x229
(325) 942-2109
frosty.aguilar@angelo.edu
Cliff Taylor
Analyst
(325) 942-2334 x236
(325) 942-2109
cliff.taylor@angelo.edu
Mark Hirt
Analyst
(325) 942-2334 x233
(325) 942-2109
mark.hirt@angelo.edu
Christine Burrell
Programmer
(325) 942-2334 x255
(325) 942-2109
Christine.burrell@angelo.edu
Security Work Team
March 13 2007
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 112 of 117
Role or Area of Representation
Information Technology Security
Officer
Technical Support for Finance
Technical Support for Financial Aid
Technical Support for Student
Records
Technical Support for Advancement
Database Administrator
Director of Alumni Relations
Human Resources and Payroll
Director of Financial Aid
March 13 2007
Member Name
Phone/FAX Number
Email Address
Jason Brake
Security Officer
(325) 942-2334 x249
Frosty Aguilar
Analyst
(325) 942-2334 x229
(325) 942-2109
frosty.aguilar@angelo.edu
Cliff Taylor
Analyst
(325) 942-2334 x236
(325) 942-2109
cliff.taylor@angelo.edu
Mark Hirt
Analyst
(325) 942-2334 x233
(325) 942-2109
mark.hirt@angelo.edu
Christine Burrell
Programmer
(325) 942-2334 x255
(325) 942-2109
Christine.burrell@angelo.edu
Jeff Riels
Senior Computer Systems
Technician
(325) 942-2334 x228
(325) 942-2109
jeff.riels@angelo.edu
Lynsey Flage
Director of Alumni Relations
(325) 942-2122
(325) 942-2373
lynsey.flage@angelo.edu
Dana Evans
Payroll
(325) 942-2727
(325) 942-2271
dana.evans@angelo.edu
Lyn Wheeler
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 113 of 117
Role or Area of Representation
Records
Development
Controller
Member Name
Phone/FAX Number
Email Address
Director of Financial Aid
(325) 942-2246 x247
(325) 942-2082
lyn.wheeler@angelo.edu
Cindy Weeaks
Report Coordinator
(325) 942-2043 x244
(325) 942-2553
cindy.weeaks@angelo.edu
Rhonda McClung
Director of Development
(325) 942-2116
(325) 942-2218
rhonda.mcclung@angelo.edu
Denise Brodnax
Controller
(325) 942-2014 x263
(325) 942-2701
denise.brodnax@angelo.edu
Degree Audit/Student Advising Work Team
Role or Area of Representation
Team Lead
Technical Member
Team Member
March 13 2007
Member Name
Phone/FAX Number
Email Address
Charles McCamant
Technical Faculty Specialist
(325) 942-2385
(325) 942-2382
Charles.McCamant@angelo.edu
John Miazga
Dean – School of Education
(325) 942-2052 x255
(325) 942-2039
John.Miazga@angelo.edu
Susan Neste
Center for Academic Excellence
(325) 942-2710 x238
(325) 942-2293
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 114 of 117
Team Member
Team Member
Team Member
Team Member
Susan.Neste@angelo.edu
Meghan Pace
Office of Admissions
(325) 942-2041 x242
(325) 942-2078
Meghan.Pace@angelo.edu
Andrew Ruiz
Registrar’s Office
(325) 942-2043 x225
(325) 942-2553
Andrew.Ruiz@angelo.edu
Jana Sparks
Graduate School
(325) 942-2169 x 241
(325) 942-2194
Jana.Sparks@angelo.edu
Gayla Trotter
College of Sciences
(325) 942-2024 x241
(325) 942-2557
Gayla.Trotter@angelo.edu
Interface Team
Role or Area of Representation
Team Lead
Team Member
Team Member
March 13 2007
Member Name
Phone/FAX Number
Email Address
Colegate Spinks
Analyst/Networking Specialist
(325) 942-2334 x 225
(325) 942-2109
Colegate.Spinks@angelo.edu
Frosty Aquilar
Analyst
(325) 942-2334 x220
(325) 942-2109
Frosty.Aguilar @angelo.edu
Denise Brodnax
Controller
(325) 942-2014 x263
(325) 942-2701
Denise.Brodnax@angelo.edu
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 115 of 117
Team Member
Team Member
Team Member
Team Member
Felix.Marquez
HR Director
(325) 942-2168 x270
(325) 942-2271
Felix.Marquez@angelo.edu
Ryan Webb
Database Administrator
(325) 942-2334 x260
(325) 942-2109
Ryan.webb@angelo.edu
Jeff Sefcik
Manager
(325) 942-2334x224
(325) 942-2109
Jeff.Sefcik@angelo.edu
Candy Woodhul
Accounts Payable Manager
(325) 942-2014 x280
(325) 942-2701
Candy.Woodhul@angelo.edu
Technical Team
Role or Area of Representation
Team Lead
Technical Support for Finance
Technical Support for Financial Aid
March 13 2007
Member Name
Phone/FAX Number
Email Address
Jeff Sefcik
Manager
(325) 942-2334x224
(325) 942-2109
jeff.sefcik@angelo.edu
Frosty Aguilar
Analyst
(325) 942-2334 x229
(325) 942-2109
frosty.aguilar@angelo.edu
Cliff Taylor
Analyst
(325) 942-2334 x236
(325) 942-2109
cliff.taylor@angelo.edu
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 116 of 117
Technical Support for Student
Records
Technical Support Advancement
Database Administrator
Admissions and Reporting
Portal Integration Analyst
Network Specialist
March 13 2007
Mark Hirt
Analyst
(325) 942-2334 x233
(325) 942-2109
mark.hirt@angelo.edu
Christine.Burrell
Programmer
(325) 942-2334 x255
(325) 942-2109
christine.burrell@angelo.edu
Jeff Riels
Senior Computer Systems
Technician
(325) 942-2334 x228
(325) 942-2109
jeff.riels@angelo.edu
Larry Schmiedekamp
Student Records Analyst
(325) 942-2333 x237
(325) 942-2109
larry.schmiedekamp@angelo.edu
Jason Hord
Portal Integration Analyst
(325) 942-2334
(325) 942-2109
jason.hord@angelo.edu
Jason Brake
Network Services Specialist
(325) 942-2333 x249
(325) 942-2109
jason.brake@angelo.edu
Project_Definition_Document_PDD_v4.0.doc1
Angelo State University
Banner Implementation
Page 117 of 117