Oasis Charter

Arizona State University Oracle/PeopleSoft Implementation OASIS Project Charter
April 19, 2006
PROJECT CHARTER
Version Control
Document Title: Authors:

Arizona State University OASIS Project Charter Max Davis-Johnson, Project Director Michael Dickson, SA Functional Director Katherine Ranes, SA Functional Director Tina Thorstenson, HCM Functional Director Sue Bishop, HCM Functional Director Todd McElroy, CedarCrestone Director Tasleema Director
Tarmeen
Lallmamode,
Technical
Barry Brummund, Technical Director
Revision History
DATE 03/07/2006 04/23/2006 04/26/2006 4/27/2006 6/20/2006 6/20/2006 6/21/2006 REVISION Draft Executive Summary Final Draft for Review Functional Council Approval Copy provided to ABOR Project Budget Added ABOR Review Adjustments HCM Updates BY Management Team Management Team Functional Council ABOR Management Team Management Team Management Team
PAGE(S)
All All All All All All All
Arizona State University
Last revised 04/24/2006 Page i
PROJECT CHARTER
Last revised 04/24/2006 Page ii
PROJECT CHARTER
Table of Contents
Executive Summary.........................................................................................................1 Purpose ....................................................................................................................1 Vision........................................................................................................................1 Project Goals ............................................................................................................1 Scope .......................................................................................................................1 Timeline ...................................................................................................................2 Summary of Key Milestones......................................................................................2 Project Approach.......................................................................................................3 1.1 Problem Statement ................................................................................................5 Vision ...........................................................................................................................6 1.3 Mission ..................................................................................................................7 1.4 Project Goals .........................................................................................................7 1.5 Critical Success Factors ........................................................................................8 1.6 Assumptions.........................................................................................................10 2.0 Project Scope...........................................................................................................11 3.0 Project Facilities and Technical Environment ..........................................................12 3.1 Technical Environment.........................................................................................12 3.2 Project Facilities....................................................................................................12 4.0 Project Management and Control.............................................................................13 4.1 Project Plan Maintenance.....................................................................................13 4.1.1 Project Plan Availability..................................................................................13 4.2 Meeting Management...........................................................................................13 4.2.1 Project Meetings.............................................................................................13 4.3 Project Reporting .................................................................................................14 4.3.1 Weekly Status Reports ..................................................................................14 4.3.2 Monthly Status Reports..................................................................................14 4.4 Project Budget Management ...............................................................................14 4.4.1 Budget/Expense Approval .............................................................................15 Budget Status Reports and Review.........................................................................15 5.0 Project Structure ......................................................................................................16 5.1 Teams, Roles, and Responsibilities......................................................................17 5.2 Project Team Training Requirements...................................................................22 Arizona State University Last revised 04/24/2006 Page iii
PROJECT CHARTER
6.0 Project Processes....................................................................................................23 6.1 Standard Procedures............................................................................................23 6.1.1 Phase I: Project Planning and Preview..........................................................23 6.1.2 Phase 2: Analysis and Design........................................................................25 6.1.3 Phase 3: Configure and Development............................................................26 6.1.4 Phase 4: Testing and Training........................................................................30 6.1.5 Phase 5: Deploy and Optimize.......................................................................31 6.2 Issue and Risk Resolution and Change Control Processes..................................32 6.2.1 Capturing, Monitoring, and Communicating Issues........................................32 6.2.2 Escalating Issues ..........................................................................................32 6.3 Documentation Management................................................................................32 6.3.1 Naming Conventions......................................................................................35 6.3.2 Documentation Lifecycle................................................................................36 7.0 Communication Strategy .........................................................................................38 7.1 Communication Goal and Objectives....................................................................38 7.2 Approach to University-wide Communication........................................................38 7.2.1 Critical Communication Success Factors.......................................................38 7.3 Roles and Responsibilities....................................................................................39 7.3.1 Leadership Involvement.................................................................................39 7.3.2 Communication Team Roles and Responsibilities..........................................39 7.5 Communication Processes ..................................................................................39 7.5.1 Leveraging Communication Efforts................................................................39 8.0 Data Conversion Strategy........................................................................................40 8.1. Conversion Scope...............................................................................................40 8.1.1 What Data will be converted?.........................................................................40 8.1.2 When will the data be converted?..................................................................40 9.0 Testing Strategy ......................................................................................................41 9.1 Testing Processes................................................................................................41 9.1.1 Unit Testing....................................................................................................41 9.1.2 System Integration Testing.............................................................................41 9.1.3 Customization Testing....................................................................................41 9.1.4 Performance Testing......................................................................................41 9.1.5 Acceptance Testing........................................................................................42 9.2 Participants...........................................................................................................42 Arizona State University Last revised 04/24/2006 Page iv
PROJECT CHARTER
10.0 End User Assistance Strategy ...............................................................................43 10.1 End User Documentation Services ....................................................................44 10.1.1 Documentation Objectives............................................................................44 10.1.2 Documentation Approach.............................................................................44 10.1.3 End Users Documentation Needs................................................................44 10.1.4 Documentation Development.......................................................................44 10.1.5 Maintenance and Distribution.......................................................................45 10.2 Training Services ...............................................................................................46 10.2.1 Training Objectives.......................................................................................46 10.2.2 Training Approach........................................................................................46 10.2.3 Training Processes.......................................................................................47 10.3 Support Services ...............................................................................................49 10.3.1 Help Desk and Support Service Objectives..................................................49 10.3.2 Approach......................................................................................................49 11.0 Post-implementation Strategy................................................................................50
Last revised 04/24/2006 Page v
PROJECT CHARTER
EXECUTIVE SUMMARY
Purpose
The Project Charter provides the major goals and objectives, strategies, and standards for the OASIS (Online Administrative and Student Information System) project. This project will implement the PeopleSoft Student Administration (SA) and Human Capital Management (HCM) software at Arizona State University. The charter defines the following standards and operating procedures for the project:

Organizational structure Project team roles and responsibilities Project management tools and standards Issue resolution and decision approval processes Communication, documentation and training strategies
Vision
Improve service to students and employees, improve recruitment of students and employees, minimize costs, and begin to coordinate across universities to simplify student access to university resources. Install a modern infrastructure to respond to the needs of the New American University.
Project Goals
To consider this software implementation project a success, the Functional Council and Management Team have set the following goals: 1. Complete the project on time and within budget. 2. Position ASUs administrative applications to support significant growth and expansion. 3. Optimize the delivered capabilities of the software to adapt business processes, improve productivity, personalize service, enable self-service, and provide access to services. 4. Implement the most upgrade-compatible system feasible and minimize total cost of ownership. 5. Implement a reliable, secure, and scalable technical infrastructure.
Scope
The scope of the OASIS project includes the implementation of selected modules of PeopleSoft Student Administration and Human Capital Management. This also includes several pilot projects using Customer Relationship Management. A complete list of modules is included in Section 2.0 and is reflected in the project timeline below. OASIS will implement version 8.9 which includes significant self-service capabilities, flexible configuration settings and reporting capabilities, eliminating the need to implement customizations and shadow systems. Interfaces to third-party and ASU software that Arizona State University Last revised Page 1
04/23/2006.
PROJECT CHARTER
will have to share data with Student Administration and Human Capital Management will be identified and prioritized for implementation.
Timeline
The project was approved by the Arizona Board of Regents at their meeting on February 3, 2006. The functionality of the systems identified above will go into production in phases through 2007, as illustrated in the diagram below:
SA-HCM Implementation Timeline

12/15/2005 Project Kickoff
3/15/2006 Campus Community Defined
6/9/2006 Bio Demo Conversion
12/20/2006 Enrollment History Converted
1/1/2006 12/1/2005 1/31/2006 Academic Structure Defined
4/1/2006
7/1/2006 8/8/2006 Course Catlog/Schedule Fall 2007 Conversion
10/1/2006 12/31/2006
5/20/2006 HCM Milestones Defined (timeline available )
10/2/2006 Fall 2007 Applications Converted Fall 2007 Admissions go-live/Transfer articulations 8/16/2007 Student Records Completed
3/15/2007 Student Financials Balances Converted 2/9/2007 ISIR's Loaded for Fall 2007 6/2/2007 Tuition Calculated Student Payments Posted
4/1/2007 1/1/2007
7/1/2007 7/15/2007 Disburse Financial Aid 5/18/2007 Post Grades
10/1/2007 12/31/2007
3/15/2007 Fall 2007 Registration

4/22/2007 FA Awarded & Packaged
10/1/2007 Post-Implementation Support Completed
Summary of Key Milestones

MILESTONE Start SA Implementation Project Academic Structure Defined Campus Community Defined HCM Milestones Determined Student Bio/Demo Data Converted Course Catalog/Schedule Converted TARGET DATE January 2006 February 2006 March 2006 May 2006 June 2006 August 2006 October 2006 (goal) February 2007 (deadline)
Applicant Data Converted/Applications Loaded / Transfer Articulation/Admission
04/23/2006.
Arizona State University Last revised Page 2
PROJECT CHARTER
MILESTONE Processed ISIRs Loaded Enrollment History Converted Holds Converted (Service Indicators) Ready for Live Student Pre-Registration Student Financials Balances Converted Financial Aid Awarded/Packaged Ready to Post Grades Calculate Tuition/Accept Payments
TARGET DATE February 2007 February 2007 March 2007 March 2007 March 2007 March 2007 May 2007 June 2007
Project Approach
NAU recently completed a successful migration from an SIS based on the current ASU system to PeopleSoft. In this project, ASU will implement a simple, minimally modified, vanilla implementation based on NAUs PeopleSoft based Student Administration and Human Capital Management System (SA/HCM). ASU will adapt to the new system through configuring the software and changing business processes. As the New American University grows, the new SA/HCM system will grow to respond to this growth and changing needs. This approach to implementing the PeopleSoft SA and HCM systems will leverage NAU PeopleSoft expertise in project planning, configuration, data conversion, and training. Future upgrades and modifications will be able to draw upon expertise at both NAU and ASU. The project will be fast-tracked with the project team empowered to make the decisions necessary to meet project goals. We will implement the PeopleSoft software with minimal customizations/modifications relying on the flexibility and configurability of the software along with re-engineering of business processes. To ensure that the project stays on track, this project will use proven methodology and processes, and best project practices. ASU will use a third party to act as an outside auditor to report to ABOR on project status. The independent party will do quarterly site visits and interviews with project staff to assess progress and status of the project. Key points adopted from the NAU approach are: Undertake a phased implementation of core modules Regents Vanilla approach is endorsed at ALL levels All levels of the project are empowered to make decisions quickly Functional Council evaluates and endorses new policy as needed Leverage NAU configuration and expertise Immerse users in prototyping and testing Engage functional users in all stages of the project Arizona State University Last revised Page 3
04/23/2006.
PROJECT CHARTER
Leverage existing data conversion Leverage existing training materials Use vendor hosting of applications to speed implementation, reduce costs and risks Best Practice 1 - Executive management endorses and supports the OASIS Project by providing adequate funding and prioritization. Best Practice 2 Executive Management will remain actively involved throughout the implementation. Best Practice 3 The OASIS Project implementation responsibilities should be shared between the University Technology Office and functional areas where the software is being implemented. This is a University Project. Best Practice 4 Executive management should be cognizant about the ASUs ability to adapt the organizational changes that occur when the new software is implemented. Best Practice 5 A project manager will be assigned full-time to the implementation. Best Practice 6 The project team composition will represent all functional areas where the software will be implemented. Best Practice 7 Project team members are full time on the project and normal job responsibilities should be reassigned to other employees for the project duration. Backfill budget will be provided for departments providing staff to the project. Best Practice 8 Project team members will receive training on how to work as a team on a project before implementation begins. Best Practice 9 Support when modules come live will be proactive. Support staff will be on site with key offices during go-live. The project team will hold hands with new SA & HCM users during go-live. Best Practice 10 A separate dedicated work environment specifically created for the project team is required. Both functional and technical project staff will be co-located. Best Practice 11 All employees who will implement and use OASIS will receive training. Best Practice 12 Executive management should help employees network with peers at other institutions undergoing similar implementation initiatives. Best Practice 13 It is often necessary for an institution to change its administrative processes to fit the software. ASU will adapt a philosophy of using the software out of the box or re-engineering a business process before changing the PeopleSoft software.
ASU will also follow The Sweet Sixteen - best practices for the OASIS Project:
04/23/2006.
PROJECT CHARTER
Best Practice 14 Outside consultants will be used to facilitate implementation efforts and perform knowledge transfer. ASU will retain ownership and control of the implementation process. Best Practice 15 Implementation information should be continuously communicated to the campus community. Multiple communication modalities will be used. Project team members will have regular meetings with their functional offices to report back and share what is happening in the project office. Best Practice 16 - Conversion of data from the old software system to the new and identifying and implementing reporting needs will begin early in the implementation process.
ASU is partnering with external consultants in a collaborative approach that will combine the external consultants implementation methodology and expertise in PeopleSoft with the knowledge and expertise of key technical and functional staff in ASUs current information systems and business processes.
Apply local knowledge

By identifying key stakeholders in all service areas and involving them in the analysis and design of software and business processes that will affect their respective areas, we will be able to develop a system and revise our processes in ways that meet our business needs.
Accelerate decision making

Key stakeholders who collaborate on analysis and design work in areas of the system in which they have a common interest will be empowered to make decisions about routine transactions and processes, so that decisions do not get bogged down in layers of bureaucracy and only those issues involving multiple service areas, potential changes to policy, or other complexities, will need to be elevated to the Functional Council. The Functional Council consists of directors from ASUs various campuses that have a vested interested in the new system. They will help make the decisions that will have a direct impact on the University.
Knowledge Transfer
Core teams at ASU will be paired with consultants, so that key technical and functional personnel from ASU will be learning the PeopleSoft system and operating procedures as they go. This knowledge transfer will be supplemented by formal PeopleSoft training, so that by the end of the project these ASU personnel can assume a lead role in training their co-workers and operating the system without the aid of consultants. Foundation The purpose of this section is to clearly identify ASUs vision and strategic direction that are driving this project, as well as the problems or obstacles the project will help solve. This section will answer these fundamental questions: Why are we doing this project? What effects do we want it to have on University operations and customer service?
1.1
Problem Statement
The current ASU Student Information System (SIS) was implemented in 1980. Over the last 20+ years, it has become a patchwork of logic changes and new services that still address office specific requirements. The old SIS, while it continues to Arizona State University Last revised Page 5
04/23/2006.
PROJECT CHARTER
serve the university, has reached the point of diminishing returns in terms of the personnel and capital investments required to maintain the system. In addition, the current system is structurally unable to address changes and new services required to meet current needs, and to keep pace with participation in the Arizona University Network (AZUN), or support the evolution of ASU as the New American University. The current SIS and HR/Payroll systems are built on COBOL, IDMS/DB2 and mainframe technology. The ability to support this technology is diminishing as this workforce is retiring and there is no new workforce with this skill set to replace them. Moving to a new system will not only update the technology (Oracle and open systems) but make a whole new generation of workforce tools available to ASU. Current limitations of the ASU SIS include limited capacity to implement seamless business processes required by the university, and outdated supporting technology. As a result, Colleges and functional areas are increasingly adding their own technical staff to build and maintain shadow auxiliary student systems to meet their needs, raising issues of consistency, liability, and inconsistent service to our students. ASU must plan the replacement of the current system immediately to be able to test and implement the new system while the current system still functions. Replacing the current SIS with a new vendor supported system would address these limitations and allow ASU to focus on the ASU brand and quality of service. The replacement would provide the flexibility to respond and adapt both technically and functionally to the future role and growth of the University. ASUs HR/Payroll System has similar deficiencies. Its older, inflexible technology has limited support for the Human Resources office and the services it offers the university community. For example, because the HR/Payroll System is actually a payroll processing system, it does not include a benefits module. As a result, ASU must work through the state benefits system, which results in inefficient benefits practices and slow responses to employee needs. In addition, the current system does not support the recruiting and hiring processes. The resulting inefficiencies dramatically increase time required for recruitment, and regularly results in the loss of top candidates to other employers.
Vision
Improve service to students and employees, improve recruitment of students and employees, minimize costs, and begin to coordinate across universities to simplify student access to university resources. Install a modern infrastructure to respond to the needs of the New American University.
04/23/2006.
PROJECT CHARTER
1.3
Mission
The mission of this Core Project Team, including ASU staff members and consultants, is to work collaboratively to implement the PeopleSoft system, within the time and budget prescribed, in such a way that it will (1) improve service to students and employees, (2) enrich the learning and working environment, and (3) provide the greatest long-term value to the institution.
1.4
Project Goals
To achieve our mission, we have defined specific project goals, and for each goal, we have included examples of concrete guidelines that will enable us to meet these goals.
1.4.1 Complete the project on time and within budget.

The following guidelines will help us to meet this goal: 6. Upfront planning. Develop a milestone-based project plan to optimize resources. 7. Manage the project to the project plan, regularly tracking project status against milestones and acting on potential problem areas before they delay the project. 8. Establish and follow a well-defined issue resolution process that includes time limits for escalating and deciding on issues.
1.4.2 Position ASUs administrative applications to support significant growth and expansion.
The following guidelines will help us to meet this goal: 1. Emphasize self-service. 2. Learn the capabilities of the new software. 3. Plan for non-credit and credit students, and non-credit and credit offerings when configuring the system. 4. Plan for multi-campus and virtual locations. 5. Plan for AZUN and other ABOR initiatives/organizations.
1.4.3 Optimize the delivered capabilities of the software to adapt business processes, improve productivity, personalize service, enable selfservice, and provide access to services.
The following guidelines will help us to meet this goal: 9. Use this project to examine business processes and practices and redesign them where needed within a Regents' Vanilla implementation, and conform to the best practices delivered out-of-the-box by PeopleSoft. 10. Provide appropriate PeopleSoft training for ASUs functional team leads, to familiarize them with PeopleSoft features and functions.
04/23/2006.
PROJECT CHARTER
11. Use proven methodology and tools for knowledge transfer and documentation of process decisions and designs. 12. Given a choice between modifying the delivered software to accommodate a current business process or redesigning the process to optimize the software, choose redesigning the process as long as all critical business needs can be met.
1.4.2. Implement the most upgrade-compatible system feasible and minimize total cost of ownership.
The following guidelines will help us to meet this goal. 1. Establish and modifications. follow precise approval criteria for all software
2. When software modifications are necessary, utilize a bolt-on approach and do not modify delivered software unless absolutely necessary. 3. Thoroughly document technical specifications for all modifications and interfaces. 4. Reduce the number of shadow or distributed systems that duplicate functions in PeopleSoft. 5. Provide adequate training to technical support staff on the tools and technologies needed to support the new system. 6. Use a mentoring approach with consultants to ensure maximum knowledge transfer to ASU personnel.
1.4.2. Implement a reliable, secure, and scalable technical infrastructure.

The following guidelines will help us to meet this goal: 7. Provide adequate training to technical support staff on the tools and technologies needed to support the new system. 8. Use a proven hosting organization to house and support the hardware and software with a contracted service level agreement.
1.5
Critical Success Factors
Critical success factors are conditions and resources that must be present and available for the project to be successful. Because these factors typically pertain to commitment of project resources, the Functional Council should be notified if a critical success factor is altered during the course of the project, so that it can take mitigating action. The critical success factors that have been identified for this project have been organized into separate, but interrelated, categories as listed below. 04/23/2006. Arizona State University Last revised Page 8
PROJECT CHARTER
Personnel
9. People are open to a new way of doing things, and there is a willingness and ability to change. 10. There are skilled people on the project who are good communicators, see the big picture, and think outside the box. 11. People are given permission to tell the truth and do so. 12. The most appropriate and knowledgeable people are assigned to the project. 13. There is a process for getting short-term temporary assistance to help offset the loss of key staff during this project. 14. Qualified subject matter experts are available to work with the Core Project Team in specific design sessions, as well as in testing and user training. 15. There will be representation by all campuses. 16. There is adequate functional and technical staff assigned to the project and they are afforded time to devote to the project. 17. Those in key roles have the necessary training and tools for the implementation. 18. A comprehensive training plan is in place. 19. A comprehensive communication plan is in place. 20. An appropriate number of consultants are available. 21. An appropriate amount of information from NAU is available.
Processes
22. The timeline is aggressive and requires prompt decision making. 23. The scope should be limited and decisions regarding scope should be prioritized. 24. Up to date information is provided. 25. The project participants listen to users in their respective service units. 26. All departments will cooperatively review current business processes with the intent of streamlining them to achieve best practices using the PeopleSoft software. 27. New processes will be thoroughly and accurately documented. 28. The current level of service is uninterrupted.
Technology
29. The necessary infrastructure is in place for conversion, development, training, testing, and prototyping. 30. PeopleSoft release upgrades will occur as scheduled with documentation and support. Arizona State University Last revised Page 9
04/23/2006.
PROJECT CHARTER
31. Legacy data to be converted is accessible, accurate and complete. 32. There is University awareness and acceptance that new development in the legacy systems will be restricted to mandatory functions only.
1.6
Assumptions
Assumptions are internally or externally imposed conditions that impact the project and are assumed to be unchangeable. Because assumptions set expectations regarding the ground rules for implementation, they should be communicated to all project participants as well as the broader University community. Some examples are given below:

The scope of software functionality, data conversion, and interfaces has been correctly defined. The academic calendar and fiscal calendar will be considered to determine when go-live dates are set within the project timeline and contractual schedules. PeopleSoft will introduce change for both end users and technical staff. Funding for the project will be available at the budgeted amount. ASU Core Project Team members will receive necessary PeopleSoft training. Both ASU and consulting Core Project Team members will be available to work on the project whenever needed. A project work environment, including the necessary hardware, software, network connections, office supplies, and meeting facilities will be available to Core Project Team members for the duration of the project.
04/23/2006.
PROJECT CHARTER
2.0 PROJECT SCOPE

The project scope was determined by an assessment of the software required to replace the applications currently running as part of the Student Information System (SIS) and HRMS on the mainframe. This scope includes the software modules identified in Table 1. Additionally interfaces will be adapted or created to allow systems not moving to PeopleSoft to continue to function. All required active and historical data will be converted to the new system.
Table 1: Project Scope

SOFTWARE Human Capital Management CAPABILITY Student Administration HR Talent Acquisition Manager Candidate Gateway Payroll Time and Labor Base Benefits Benefits Administration Position Management GL interface State of Arizona HR interface Marketing for Undergraduate Student Recruiting Online Marketing for Undergraduate Student Recruiting Identify best practices to use CRM Marketing/Online Marketing Admissions/Recruiting Academic Structure CRM interface Campus Community Financial Aid Student Financials Student Records DARS/DARWIN interface GL interface Web application interface Room scheduling interface Enables reporting and data analytics Affiliate interface Interfaces to critical administrative systems as determined by project management
Customer Relationship Management (Pilot only)
Enterprise Performance Management Other Software
04/23/2006.
PROJECT CHARTER
3.0 PROJECT ENVIRONMENT

3.1

FACILITIES
AND
TECHNICAL
Technical Environment
PeopleSoft HRMS Suite Customer Relationship Management PeopleSoft Campus Solutions & Student Administration PeopleSoft Portals and EPM Modules UPK UPK Content
ASU will contract with CedarCrestone, Inc., to provide a hosted environment for the following applications:
The hosted environment will include the DEV, TST, and PROD instances of the following:
Application Servers Oracle Database Servers Web Servers
CedarCrestone will be responsible for (1) Monitoring servers (2) Monitoring performance (3) Installing PeopleSoft applications (4) Applying fixes and patches (5) Migrating customizations from test to production (6) Providing an environment and tools for 2-tier development (7) Providing disaster-recovery tools For a complete list of CCI and ASU responsibilities, please refer to the CedarCrestone MLA-SLA and CCI Client Manual documents.
3.2
Project Facilities
Arizona State University will make facilities and necessary equipment available for the core project teams and the service teams on the Tempe Campus. Specifically, a designated area will be provided in the Computing Commons building to house all functional and technical personnel. With appropriate advanced planning, facilities and equipment will also be available for hands-on training of end users.
04/23/2006.
PROJECT CHARTER
4.0 PROJECT MANAGEMENT
AND
CONTROL
The purpose of this section is to provide a general overview of the processes and tools to be used to ensure project performance is regularly measured so that variances are identified and, where appropriate, actions are taken to resolve the variances. The following best practices will be deployed throughout the ASU Implementation Project lifecycle to ensure that the project plan is effectively executed and controlled.
4.1
Project Plan Maintenance
The Project Plans will be maintained using the Microsoft Project application. Separate plans will exist for Student Administration, Customer Relationship Management, and Human Resources. Each plan contains a comprehensive list of the required phases, tasks, and milestones for successful execution of the project. The plan identifies estimated begin and end dates for each phase, task, and milestone. As the project evolves, the plans will be updated to reflect percentage complete references for each task, phase, or milestone. The following control processes will be used to ensure that the Project Plans are regularly updated, monitored, and communicated.
4.1.1 Project Plan Availability

The Project Directors alone will have the security access to update the Project Plans, and will do so at least once per week. The Project Directors will ensure that current versions of the Project Plans are available to all members of the Core Project Team on the shared drive.
4.2
Meeting Management
4.2.1 Project Meetings

Planning: Facilitators (typically the consultants or ASU Functional Lead) will use Microsoft Outlook Calendar to schedule meetings. Agendas and supporting documents will be shared with meeting participants before the meeting. Communicating Results: Meeting minutes, using the standard Meeting Minutes Template, will be created for each formal meeting. The facilitator of the meeting is responsible for creating and distributing the meeting minutes. The meeting minutes will be saved using the standard naming conventions described in Section 6.3.
Types of Meetings:
IDP Sessions IDP (Interactive Design Prototype) sessions occur for each respective project module for the purpose of gathering functional requirements and designing business processes to optimize the capabilities of the system. The consultants supporting the functional leads are responsible for facilitating these meetings. Module Team Meetings - These meetings occur on an as needed basis to coordinate, validate or modify team activities. Common reasons for these meetings include; Arizona State University Last revised Page 13
04/23/2006.
PROJECT CHARTER
conversions, module scope, testing, training, modification reviews, etc. ASU functional leads or supporting consultants are responsible for facilitating these meetings. User Review Sessions These meetings occur on an as needed basis so that the proposed system users may review system deliverables and provide open, candid feedback about the performance of the deliverables. ASU functional leads or supporting consultants are responsible for facilitating these meetings. Project Status Meetings These meetings are held regularly and attended by the appropriate Core Project Team members. The purpose of these meetings is to discuss project status as it relates to schedule and performance for the project. Functional Council Meetings Regular meetings of the Functional Council will be scheduled on a monthly basis to review project status and issues. These meetings are attended by the ASU Functional Council members, Functional Directors and Technical Directors. The Functional Council will also meet as needed to address unresolved issues that require executive decisions.
4.3
Project Reporting
The principle vehicles for project reporting will be standard weekly and monthly status reports. These reports will be developed and submitted as described below. Once a status report has been reviewed and approved by the appropriate recipient (Project Directors or Functional Council), it will be posted to the Project Shared Drive and be available to all Core Project Team members.
4.3.1 Weekly Status Reports

Using the standard Weekly Status Report Template, weekly status reports will be submitted jointly as follows:
ASU Functional Leads and the supporting consultants will submit joint status reports to the Project Directors by the end of each week. The ASU Functional leads will be responsible for posting the status reports to the Shared Drive using standard naming conventions described in Section 6.3. ASU Technical Leads and supporting consultants will submit joint status reports to the Project Directors by the end of the week.
4.3.2 Monthly Status Reports

Using the standard Monthly Status Report Template, the Project Directors will jointly submit a monthly status report to the Functional Council. This report will summarize the status of critical target dates and milestones, accomplishments and activities of the past month, and any issues that still need to be resolved. Monthly project summaries will also be available to everyone in the University on the project website.
4.4
Project Budget Management
04/23/2006.
PROJECT CHARTER
The 5 year Project Budget has been established including offsets in the final two years.
T AL SOFT OT WARE AND FINANC ING T AL HOST OT ING/ HARDWARE T AL FAC ILIT OT IES T AL BAC KFILL OT T AL ST OT AFF T RAVEL AND T RAINING T AL FUNC T OT IONAL ST AFFING T AL T HNIC AL ST OT EC AFFING T AL C ONSULT OT ING OFFSET S T AL OT F iscal '06 $911,763 $267,000 $300,000 $396,000 $368,000 $48,750 $144,788 $824,000 $0 $3,260,300 F iscal '07 $1,879,663 $794,900 $100,000 $892,667 $48,000 $311,253 $587,837 $3,182,000 $0 $7,796,320 F iscal '08 $1,879,663 $1,405,600 $0 $164,667 $8,000 $1,057,308 $605,472 $1,070,000 $0 $6,190,710 F iscal '09 $1,295,959 $1,517,000 $0 $0 $0 $1,252,873 $623,637 $0 ($536,250) $4,153,218 F iscal '10 5 Year T otal $712,255 $6,679,304 $1,437,000 $5,421,500 $0 $400,000 $0 $1,453,333 $0 $424,000 $1,290,459 $3,960,642 $642,346 $2,604,079 $0 $5,076,000 ($965,250) ($1,501,500) $3,116,810 $24,517,358
A project account XJ51014 has been established and all project expenses will be charged to this account. The account has been setup with suborgs that reflect the budget breakdown of Software, Hosting/Hardware, Facilities, Backfill, Travel and Training, Project Staffing, Consulting and Miscellaneous.
4.4.1 Budget/Expense Approval

All project expenditures are approved by one of the ASU members of the OASIS Project Management team. All invoices and other expenses are approved by the project director with a signature before they are entered into the accounting system (Advantage). All expenses over $15,000 are reviewed by the University Technology Officer and the UTO Business Manager.
Budget Status Reports and Review

Daily Advantage Web Reports are available for the OASIS Project Account that show all current transactions that have been posted. A monthly OASIS Budget and Expense report is prepared by Project and UTO administrative staff and is distributed to UTO, Financial and University Budget Office staff. In the first weekly Project Management Team meeting of each month the Project Budget status report is reviewed for the prior period. At the beginning of each quarter the Project Budget will be reviewed with the Functional Council. There will also be a quarterly project and budget review by a outside consultant on behalf of the Arizona Board of Regents
04/23/2006.
PROJECT CHARTER
5.0 PROJECT STRUCTURE

The purpose of this section is to describe the project organization, explain project roles and responsibilities. The chart in Figure 1 below provides an overview of the structure of the Project Team:
Functional Council Project Management Team

Max Davis-Johnson (Project Director) Michael Dickson (Functional Director) Katherine Ranes (Functional Director) Tina Thorstenson (Functional Director) Sue Bishop (Functional Director) Tasleema Lallmamode (Technical Director)
Consultants
Todd McElroy (Functional Lead) Barry Brummund (Technical Lead)
Core Teams
Academic Structure Campus Community Student Records Admissions / Recruitment Student Financials Financial Aid Academic Advising / DARS Human Capital Management CRM Marketing/Online Marketing
Service Teams
Training/End User Assistance Functional Technician Development Conversion Workflow Security Data Warehouse & Reporting Communications
Consultants
Figure 1: Project Structure
04/23/2006.
PROJECT CHARTER
5.1
Teams, Roles, and Responsibilities
This section describes the various teams, their roles and their responsibilities. Each table below addresses a particular team. Additionally, a team roster with contact information for all consultants and ASU project team members will be maintained and updated throughout the project. It will be available to all team members in the Project Communication Center.
Table 1: Functional Council

ROLES Membership and Responsibilities The functional council will advise and facilitate the implementation of the Oracle PeopleSoft Student Administration and Human Capital Management systems. The Functional Council will consist of directors and administrators who have a vested interest in the new system. They will help make decisions that will have a direct impact across the university community. RESPONSIBILITIES 1. Facilitate high level project decisions. One of the keys for the success of the implementation project is to make decisions wisely and quickly. 2. Research and help solve issues raised by the Project Management Team and provide input into strategic project planning and implementation. 3. Draft and if appropriate approve project, computing and data management policies and procedures. 4. Serve as a vehicle to help keep the ASU community informed about changes, issues, and decisions. 5. Review and approve project scope and priorities if appropriate. 6. Review and approve system modification requests if appropriate
Table 2: Project Management Team

ROLES Membership and Responsibilities The Project Management team consists of project, functional and technical directors. Project Director: The project director oversees all aspects of the project and leads the project management team. RESPONSIBILITIES
1. Resolve staffing and business issues/concerns . 2. Monitor project progress and consultants performance. 3. Make overall project decisions that ensure the project is completed on time and within budget constraints. 4. Coordinate all activities that involve entities external to the project team.
04/23/2006.
PROJECT CHARTER
5. Lead project management team. 6. Monitor milestone achievement and takes corrective action if warranted.
Functional Directors: The Functional Directors oversee project implementation and facilitate communication across core and service teams, with focus on business processes.
7. Manage issue resolution. 8. Manage scope, monitor milestone achievement and take corrective action if warranted 9. Regularly report progress of the project to the Management Team and the Functional Council. 10. Direct the training and end-user support efforts. 11. Facilitate prioritization of project activities. 12. Manage issue resolution. 13. Manage scope, monitor milestone achievement and take corrective action if warranted 14. Regularly report progress of the project to the Management Team and the Functional Council. 15. Direct technical training efforts. 16. Facilitate prioritization of project activities. 17. Respond to requests for technical enhancements in the PeopleSoft system from the Functional Directors. 18. Provide interfaces and interface support between PeopleSoft and other systems when requested by Functional Directors.
Technical Director: The Technical Director oversees project implementation and facilitates communication across core and service teams, with focus on technical requirements and processes.
Table 3: Service Teams

ROLES AND PERSONNEL Training/End User Assistance RESPONSIBILITIES 19. Develop end user documentation, training, and post-implementation support plans 20. Plan and oversee development of end user training materials and user guides 21. Coordinate train-the-trainer program for end user training 22. Coordinate with Project Management Team to determine technical environment and facilities needed for end user training. 23. Coordinate with Support Services in implementing post-implementation end user support 24. Develop and implement Helpdesk plan.
04/23/2006.
PROJECT CHARTER
Functional Technician
25. Assist functional groups in IDP sessions 26. First group of technicians who respond to customizations including interfaces from functional groups 27. First group of technicians to implement customizations that are owned by functional groups without technical representation. 28. Assist functional techs with customization requests as necessary, 29. Implement interfaces from current ASU legacy systems to PeopleSoft systems as necessary. 30. Convert existing legacy data to the new PeopleSoft environment 31. Assist functional groups develop and implement workflow requirements. 32. 33. security 34. security 35. security Develop security strategy Develop functional requirements for Develop technical specifications for Configure application and database
Development
Conversion Workflow Security
Data Warehouse & Reporting
1. Extract, transform, and load data into reporting databases and warehouse 2. Develop and support data query and reporting needs using appropriate ASU toolsets. 1. Develop and execute plan for communication of project information to targeted audiences University-wide. 2. Develop and distribute articles about project benefits, status, training, etc. 3. Provide Quality Assurance review for communications to all audiences beyond the Core Project Team.
Communications
Table 4: Core Teams

CORE TEAMS & LEADS Academic Structure Katie Ranes, ASU Todd McElroy, CedarCrestone Campus Community: Susan Moore, ASU Evelyn Pidgeon, ASU Todd McElroy, CedarCrestone CORE TEAMS RESPONSIBILITIES 36. Carry out the Project Plan 37. Define business processes 38. Determine table values 39. Complete required table setup and maintenance 40. Define data conversion requirements and timeline
04/23/2006.
PROJECT CHARTER
Admissions / Recruitment: Kelley Brundage, ASU Kristi Zona, ASU Mark Myhre, CedarCrestone Financial Aid: Richard Cons, ASU Jeanette Phillips, CedarCrestone Student Financials Joanne Wamsley, ASU Tom Montgomery, CedarCrestone Student Records Janice Garcia, ASU Dorella Banks, CedarCrestone Human Capital Management Elaine Moore, ASU Shona Bodai, ASU Debbie Scott, ASU Ken Mehalko, ASU Clara Adams, ASU Joe Belarde, CedarCrestone Ken McKee, CedarCrestone Mike Williams, CedarCrestone CRM Reuben Minton, ASU Brenda Starck, ASU Teresa Mallott, CedarCrestone Subject Matter Experts (SME)s: ASU Functional experts who will share these responsibilities in their respective areas of expertise for each of the teams listed above.
41. Define required reports 42. Develop information for test scripts 43. Define security requirements 44. Recommend policy change 45. Define modifications/customizations 46. Complete testing 47. Maintain business process documentation 48. Work with Training Team to develop and deliver training curriculum to end users 49. Resolve or elevate issues 50. Define data cleanup requirements and process
51. Identify and map critical business processes 52. Explore software to understand capabilities 53. Formulate best practice processes and procedures 54. Assist in design of prototypes 55. Review prototypes with appropriate university members 56. Participate in testing 57. Assist with documentation and training 58. Serve on Business Process Teams as needed 59. Assist in resolving open Help Desk
04/23/2006.
PROJECT CHARTER
issues as needed
04/23/2006.
PROJECT CHARTER
5.2
Project Team Training Requirements
The project directors along with consultants will work to determine team members training needs based on their project roles and project budget. Once these needs have been determined, the Technical Team will schedule training with Oracle University.
04/23/2006.
PROJECT CHARTER
6.0 PROJECT PROCESSES

The purpose of this section is to describe the processes and tools that will be used to design, develop, configure, and set up all software that is included in the project scope. These processes and tools are critical to the success of the project in meeting its goals. In addition to the standard procedures of Propel, CedarCrestones implementation methodology, critical project processes include the following:

Issue Resolution and Change Control Decision Making Modification Criteria Document Management
6.1
Standard Procedures
Propel 1. Project Planning and Preview 2. Analysis and Design 3. Configuration and Development 4. Testing and Training 5. Deploy and Optimize
This project will follow the standard procedures of CedarCrestones implementation methodology, which is organized around five phases:
6.1.1 Phase I: Project Planning and Preview

The planning phase provides an opportunity to discuss and come to agreement on a set of common goals and objectives and develop positive working relationships. It is the beginning of building a team that has a shared vision, views the project from a systems thinking perspective, develops team learning capabilities, and advances individual mastery of new skills.
Objectives
33. Jointly define and communicate the project vision, goals and objectives 34. Confirm project scope 35. Specify the project organization and roles and responsibilities of participants 36. Establish a timeline and resources necessary to guide the project to a successful completion 37. Identify project risks and formulate mitigating strategies to eliminate them 38. Develop a communication plan based upon constituency needs for project information
04/23/2006.
PROJECT CHARTER
Process
Project Chartering. We will conduct planning meetings with the appropriate group/individuals to complete the following tasks: formulate the project vision, goals and objectives; discuss and confirm the project scope, organizational structure and roles and responsibilities of participants; conduct a risk analysis; develop/confirm the decision making process; formulate the Training Plan for Core Project Team members and end users; and determine the appropriate strategies for modifications, interfaces and data conversion. Project Plan Development. Based upon the finalized Statement of Work and methodology, we will proceed to formulate an initial Project Plans for the SA, HCM and CRM modules. We utilize Microsoft Project to develop and maintain a detailed Project Plans that lists tasks in sequential order with corresponding start and finish dates, proposed staff, and projected duration for each task. Once the CedarCrestone Project Director has drafted the Plan, it is refined in collaboration with ASUs Project Directors and Functional Council. The CedarCrestone Project Director will be responsible for the systematic and timely collection of measurable, meaningful and accurate information to maintain the Plan. The Project Directors will regularly review the Project Plan with the Project Team and Functional Council and make a summary available for the Project Website.
Phase 1 Deliverables
The ASU Project Team and consultants will produce the following deliverables in this phase of the project: 1. Meeting Agendas 2. Project Statement of Work 3. High-level Project Plan 4. Project Charter 5. Standard Deliverable Templates
04/23/2006.
PROJECT CHARTER
6.1.2 Phase 2: Analysis and Design

This phase of the project is also known as Interactive Design/Prototyping (IDP), CedarCrestones approach to designing and prototyping system and business processes. We begin with a discussion of the needs of end users who are to be served by the software. From this perspective, we review current business processes and the capabilities of the software. Functional teams comprised of ASU subject matter experts, team leads, and CedarCrestone functional consultants collaborate to identify any required adaptations in business practice or software, develop a comprehensive implementation task list, and create a prototyped system design. This phase encompasses all processes and software determined to be within scope. This approach accelerates the analysis and design stage of the project by building a prototype and facilitates knowledge transfer by including business process experts in the design process.
Objectives
1. Design and develop prototypes of high priority processes 2. Develop strategies for testing and security 3. Refine the project plan 4. Accelerate system set-up
Processes
IDP Planning. During this initial IDP process, CedarCrestone functional leads work with ASU staff to select functionality topics, identify business processes, confirm participants for IDP sessions, schedule IDP sessions, and conduct an IDP orientation. The IDP process is intended to involve users immediately to draw upon their knowledge of the Universitys business functions. By bringing users in at the start of the project, we hope to achieve the following: (1) they will have ownership of the process, (2) they will have realistic expectations of the project scope, and (3) they will be more willing to invest in the outcomes. IDP Sessions. The IDP sessions will involve a wide range of the Universitys functional and information systems staff in focused sessions. In the IDP sessions, a functional lead will walk the users through a particular functionality of the software. During the sessions, the functional teams will map the softwares functions to the Universitys current or desired business processes. System support for these processes will then be compared to the delivered functionality of the product, and users will be walked through the actual processes on-line. This walk-through encourages active participation and input from team members regarding the components of the system and how they will be used. By using the delivered product as a template for discussion, differences or gaps between delivered functionality and anticipated utilization are clearly identified. At the conclusion of the process, users have a specific understanding of the extent to which the system will support their requirements and where changes to business processes can help optimize the software and improve productivity. If a software modification is considered absolutely necessary, a request and rationale for modification are submitted to the Project Management Team for review and approval. Arizona State University Last revised Page 25
04/23/2006.
PROJECT CHARTER
IDP Outcomes. The IDP sessions enable the team to quickly uncover gaps in functionality and explore alternative solutions. The issues and their recommended solutions are documented using the IDP Session Minutes Template or IDP Workbooks, and minor changes to the system can be incorporated immediately. Other changes, such as those to business processes or program logic, are documented and addressed later in the implementation. The results of the IDP sessions enable the project team to develop a working prototype using ASU-specific business process models. The prototype will provide a working model that reflects ASUs unique rules, processes, and data. It can be used in management demonstrations, training development, and testing. Another outcome of the IDP phase is an expanded and more detailed Project Plan. This iterative approach to refined planning incorporates specific requirements and provides an increasingly more specific road map as the project enters the detailed development, implementation, and deployment phase. Specifically, the Project Plan includes the following information: 39. Specific work breakdowns structures (WBS) 40. Dependencies and other relationships among tasks 41. Estimated effort 42. Resource allocation of both internal and external project staff At the conclusion of this prototyping process, we will have the complete project template to accomplish modification, enhancement, conversion and implementation. This overall model will provide enough structure and discipline to drive the project forward while maintaining necessary control and accountability.
The ASU Project Team and CedarCrestone consultants will produce the following deliverables in this phase of the project: 43. IDP Sessions Minutes 44. Detailed conversion plan and definition of data conversion requirements 45. An overall logical flow of the system and interface points 46. Functional and technical modification requirements 47. Assessment of report requirements 48. Assessment of Interfaces with existing internal systems and third party vendor systems 49. Development of security templates and security requirements 50. Refined end-user training strategy
6.1.3 Phase 3: Configure and Development

With sufficient planning and involvement of key stakeholders and prototyping of the system in Phase 2, this phase entails the development, data conversion, setup, and configuration of the PeopleSoft software, interfaces, and reports. By this stage, ASU 04/23/2006. Arizona State University Last revised Page 26
PROJECT CHARTER
project team members should be familiar with the software and well prepared to develop functional and technical specifications and business process guides.
Objectives
51. Develop Technical Plan to include modifications, interfaces, and conversion 52. Develop detailed functional and technical specifications 53. Configure the application 54. Map data from the legacy system to the new system 55. Document business processes 56. Develop and unit test modifications, interfaces, reports and conversion processes 57. Apply fixes, upgrades, and security
Process
The first step in this phase is development of a Technical Plan, which includes detailed functional and technical specifications for approved application modifications, custom reporting, interfaces and conversions. The Technical Plan outlines the assumptions, number of interfaces, timing, and technical considerations. The technical staff builds the necessary conversion programs, tests the conversion programs, and executes the conversion. Data Conversion Data conversion activities are often among the greatest challenges of an implementation project. Irregularities in legacy data must be rectified, or the results can have catastrophic impacts on business functionality and distort data exponentially with use. Therefore, one of the project deliverables for Phase 2, Analysis and Design, is a detailed conversion plan, which establishes the objectives and criteria for the conversion effort and identifies specific data and database sources to be converted based on these criteria. The key strategies driving the conversion plan are included in Section 8.1, Data Conversion Strategy. We organize the specific tasks associated with conversion according to the following major components: (1) conversion planning, (2) data analysis and mapping, (3) conversion programming, (4) data integrity checking and audit, (5) conversion execution and (6) post conversion clean up. CedarCrestone will provide a data mapping methodology and a facilitator who works with the functional users and appropriate technical staff. This data mapping activity results in information that assesses the integrity of the data, identifies policy issues, clarifies and formulates data definitions, and provides a basis for proceeding with the conversion in a logical manner.
04/23/2006.
PROJECT CHARTER
Customization Strategy As set forth in the Project Statement of Work, all software modifications, other than simple SQRs (query programs), must be approved by the Project Management Team. Approval of software modifications will be restricted to those modifications that meet one of the following criteria.
Mandatory Regulatory Requirement There is a Federal or State/ legal requirement or accreditation requirement imposed by an external agency that cannot be eliminated or changed. The requirement will be cited, subjected to careful review for alternative interpretations, and challenged if reasonable to do so. Business Requirement - There are policy compliance and reporting requirements mandated by the Universitys by-laws or the Chancellor. Productivity Enhancement - There is a substantiated, well-documented business case, i.e., cost benefit, for the modification based on real costs and savings. Mission Critical - without this capability, the institution will lose a competitive advantage or capability considered critical to its mission.
If a software modification is approved by the Project Management Team, we will follow the technical guidelines described in Table 9, below, in order to minimize the impact of the modification on future upgrades.
Table 9: Technical Guidelines for Customizations

DOMAIN Data Structures GUIDELINE When unable to store required data in provided data structures, we will always add new record definitions rather than augment existing records. IMPLICATIONS This prevents PS changes to those records from overwriting our own, and prevents impact on other processes that use those records. Clone and Edit may be cumbersome. See Subpages approach.
Pages and Components
PeopleCode Programs
Several techniques may be used to prevent PS changes from impacting custom changes, including the following: Clone and Edit: we may clone existing PS objects and modify them for our use as needed. Sub-pages: when Clone and Edit may be cumbersome, we create links to new data on the existing pages. If a page is changed by PS, only the link must be restored. New Pages & Components: Sometimes it is a more viable option to use our own page or groups of pages to access data. PeopleCode is a scripting language that performs work for the user when certain actions are performed in the system. The
Changes to these programs can be risky for upgrades. However,
04/23/2006.
PROJECT CHARTER
DOMAIN
Online or Batch Programs
Application Engine Programs
GUIDELINE PeopleSoft PS system contains over 30,000 of these programs. Some approaches using PeopleCode include the following: Make the change and accept the risk. Clone items and change clones: In some cases, it is possible to avoid changing PeopleSoft PeopleCode but still alter how a page behaves with this method. Approaches to modification of these items vary depending on what kind of item is in question. Examples of approaches are highlighted below: COBOL Programs: we seek to avoid any modification to COBOL programs. We would either build a new process using another tool, or recommend a pre or post processing program to be added before or after the delivered process to achieve desired results. SQR Programs: New SQR programs are often created to support custom reporting requirements. Existing SQR programs that must be changed are usually cloned. Sections of AE programs can have effective dates. If we need different functionality for an existing program, it is easy to create a copy of the existing section, update it, and save with a new effective date. New batch processes will be written using this tool.
IMPLICATIONS PeopleTools 8.0 added flexibility we can utilize to reduce upgrade risk in some cases. For certain small changes, the risk is minimal.
COBOL programs are the most difficult to maintain, and over time PeopleSoft is expected to phase them out. We seek to minimize modifications to SQR programs because it can be difficult to maintain these programs when PS makes changes.
Modifications to programs written with this tool represent the lowest risk.
The ASU Project Team and consultants will produce the following deliverables in this phase of the project: 58. Technical Plan 59. Detailed functional and technical specifications 60. Conversion maps 61. Tested and documented system components 62. Business Process Guides 63. Module Security Matrices
04/23/2006.
PROJECT CHARTER
6.1.4 Phase 4: Testing and Training

It is somewhat misleading to refer to testing as a sequential phase. We emphasize the importance of providing sufficient time for testing throughout the project, using appropriate methods and tools and involving the right people. This phase is the quality assurance step that is critical to assure that the system has been configured properly, the data have been converted correctly, and the technical environment can support the efficient operation of the system.
Objectives
1. Provide testing for the procedures necessary to successfully implement, support, and use the new system at the established levels of performance. 2. Develop Testing Plan to include objectives, types of testing required, and timing. 3. Develop test scripts. 4. Develop end user training materials and schedule. 5. Deliver end user training
Process
Our testing program begins with a Test Plan developed jointly by the ASU Project Team and consultants. The strategy that drives this plan is included in Section 9.2 of the Charter. The test plan explains what is to be tested and the criteria for evaluating the test results. All test results will be reviewed by the Core Project Team. The typical test plan encompasses both functional and technical users and includes unit testing, system integration testing, acceptance testing, system stress testing/performance and beta/parallel testing. If customizations are made, we also test the customizations. Any exposures revealed during the test will result in the creation of new tasks with deadlines. Required coding corrections are made and testing continues until all conditions are successfully tested. This testing is the final development activity for an individual component. A training plan will be developed jointly by the ASU Project Team and consultants. The strategy that drives this plan is included in Section 10.1 of the Charter. Business processes will be identified and target audiences identified. The type of training may vary from large classroom settings, web based or small group based training. Training materials will be crafted from Business Process Guides developed in the previous phase. Testing scenarios can be modified to create practice activities or homework. When a large number of users are to be trained on a set of processes, a train-thetrainers approach will be used to prepare the trainers. A separate training environment may be necessary to accommodate the numerous training sessions.
The ASU Core Project Team and consultants will produce the following deliverables in this phase of the project: 64. Test plan and objectives Arizona State University Last revised Page 30
04/23/2006.
PROJECT CHARTER
65. Test scripts and results 66. Successful test approvals 67. End user training plan 68. End user training materials
6.1.5 Phase 5: Deploy and Optimize

The final phase of the implementation process must be formalized to assure that all necessary pre-requisites to going live are completed. This phase must also address any outstanding issues and assess achievement of all of the objectives set forth in this charter.
Objectives
69. Prepare technical staff for system operation 70. Assist end users in learning to use new system and new business processes 71. Complete final preparations for go-live. 72. Complete cutover to production 73. Assess go-live results.
Process
Training coordinators, functional team leads, and functional consultants will develop training materials and carry out end user training. Project directors will develop a go-live checklist, including dependencies and estimated elapsed time, schedule go-live, confirm resources, roles and responsibilities, and assess readiness for go-live. With these preparations in place, the Core Project Team will execute the go-live processes, including conversion and migration of components. We will obtain go-live approval from the Functional Council. Finally, following implementation we will conduct a Post-Implementation Review. The results will be presented to the Functional Council.
The ASU Core Project Team and consultants will produce the following deliverables in this phase of the project: 74. Go-live checklist 75. Production system 76. Training materials 77. Post-Implementation Review
04/23/2006.
PROJECT CHARTER
6.2
Issue and Risk Resolution and Change Control Processes
As the project evolves, issues will surface and risk will be introduced to the project. To ensure that issues are managed so that risk is appropriately mitigated and a plan for resolution is completed within ten business days, the following processes will be deployed:
6.2.1 Capturing, Monitoring, and Communicating Issues

The Project Directors are responsible for capturing all identified issues via an Issues Log setup in the Communication Center. As issues are raised, the Team leads will log into the ASU Communication Center and open a new issue. The Project Directors will open the submitted issue, review it to ensure the issue is clearly named, concisely defined and accurate, a priority (high, medium, low) assessed, a responsible party assigned resolution responsibility, and an estimated date for completion given. The Project Communications Center Issue tracking capability will be use to manage issue resolution. The Project Directors will monitor the issues to ensure that they are worked to closure. When an issue is resolved, the Project Directors will update the issue from Open to Resolved and add a description of the solution and indicate the date resolved.
6.2.2 Escalating Issues

Issues that cannot be resolved by the Project Directors will be documented and communicated to the Chair of the Functional Council. The objective of this process is to resolve all issues within three business days of being escalated to the Chair of the Functional Council.
6.3
Documentation Management
To ensure that the project processes described in this section are being followed and that strategies, plans, issues, decisions, solutions, status, and results can be accurately recalled and communicated, we will follow the project documentation development and management standards described in this section. The project team has three primary locations to use for documentation and communication. The Project Website is intended for communicating project information to the greater ASU community. It will eventually link to a project support website that will include documentation, training opportunities, problem resolution methods and other material for users of the system. The Project Center is used for communications through the forums, issue tracking and file storage. Those files stored in the Project Center will be considered in near final form and can be used across teams for reference. The shared file system is available for all other documents and files used by project team members. Table 10 describes the types of information to be documented, the tools to be used, and the party responsible for the documentation. Templates for all tools listed in Column 1 of Table 3 are contained in the Shared Drive\Templates and Examples. Note that the guidelines provided here pertain primarily to project documentation.
Table 10: Project Documentation

TOOL ASU Project Charter.doc TYPE OF INFORMATION Project objectives, organization, scope, RESPONSIBILITY Project Directors, Functional Council, STORAGE & ACCESS Shared Drive\Project Management
04/23/2006.
PROJECT CHARTER
YYMMDD [Application] Project Plan
and ground rules Project Management and Control Project Facilities Project Processes Issue Resolution Process Communication Plan Conversion Strategy Testing Strategy End User Assistance Strategy Project tasks, milestones, and percent completed, etc.
CedarCrestone Project Director
Team\Charter Project Website
CedarCrestone Project Director
Shared Drive\Project Management Team\Project Plans Project Center for reference Shared Drive\Training & End User Support
Project Team Training.xls
Required and optional courses by role and team member, courses scheduled, and courses completed Who, What, When, How Often, and How to communicate project information to project team and University community Track status and resolution of project issues Document a specific issue that needs to be escalated for resolution
Training Coordinators Project Management team Project Directors, Consultants & Communications Coordinator Project Directors
Project Communication Matrix.doc
Shared Drive\Overall Project Documents\Communica tions Communication Center > Issues Shared Drive\Application\Issues When complete Communications Center > Issues Shared Drive\Application\Status Rpts Shared Drive\Appropriate Module Folder Shared Drive\Appropriate Module Folder Shared Drive\ [Application]\ [Module]\IDPs
Communication Center > Issues database [Issue Name] Escalation and Response.doc
Team Leads
YYMMDD [Team Name] Status.doc YYMMDD [Meeting Title] Agenda.doc YYMMDD [Meeting Title] Minutes.doc IDP YYMMDD [Module Component] Session Agenda.doc IDP Workbook [Module
Weekly team status reports
Team Leads
Agendas for project, team, or committee meetings Minutes for project, team, or committee meetings Special agenda for IDP session
Meeting facilitator
Meeting facilitator
CedarCrestone Functional Consultant
Document IDP results, decisions, setups from IDP
ASU Functional Team Lead or
Shared Drive\ [Application]\
04/23/2006.
PROJECT CHARTER
Component] Topic Version YYMMDD IDP YYMMDD [Module Component] Session Minutes.doc IDP YYMMDD [Module Component] Assessment.doc ASU [Module Component] #### Mod Request.doc
session
appointee and CedarCrestone Functional Consultant ASU Functional Team Lead or appointee
[Module]\IDPs
Document decisions and table setup values from IDP session
Shared Drive\ [Application]\ [Module]\IDPs
Participant evaluation of IDP session
CedarCrestone Functional Consultant Consultants and ASU Functional Leads
Shared Drive\ [Application]\ [Module]\IDPs Shared Drive\ [Application]\ Modifications Shared Drive\ Modifications\Functional Specs Shared Drive\ Technical\ Modifications Shared Drive\ Modifications\Technical Specs
Draft Functional request for software modification Approved Functional requests
[Module Component] #### Technical Spec.doc
Draft Technical specification for software modification, report, interface, or data conversion programming Final Technical specifications Inventory of current reports and list of planned reports Specifications for custom report Approved Functional Report spec
Consultants and ASU Technical staff
[Module] Reports Inventory.xls [Module] #### [Report] Spec.doc
Functional leads
Shared Drive\ [Application] [Module]\Reports Shared Drive\ [Application] [Module]\Reports Shared Drive\ Modifications\Functional Specs Shared Drive\ [Application] [Module]\IDPs Shared Drive\ [Application] [Module]\Business Process Guides Shared Drive\ [Application] Conversion Shared Drive\ [Application]\ Interfaces
Functional Lead & Report Programmer
[Module] Bus Process Log.doc [Module Component] BPG.doc [Module] [Conversion Table] Mapping.xls [System] [Title] Interface Mapping.xls
Log status of business process design Step-by-step guide for conducting key business processes using PS Template for mapping legacy data to PeopleSoft tables Template for mapping data from 3rd party software source to PeopleSoft tables. Should be included
Functional Lead
Functional Lead or SME
SMEs and technical staff
SMEs and technical staff
04/23/2006.
PROJECT CHARTER
with a Mod/Report Request [Application] [Module] Security Roles .xls [Module] Test Script Log.doc [Module Component] [Business Process] Test Script.doc Template for defining access and restrictions by user role Log of test scripts ready for use Template for developing test scripts Functional Leads, SMEs and Security Technical Team Functional Leads Shared Drive\ [Application] \Security
Shared Drive\ [Application] [Module]\Testing Shared Drive\ [Application] [Module]\Testing\Test Scripts
Functional leads
6.3.1 Naming Conventions

The template titles listed in Table 10 above will serve as standard naming conventions for project file names. Documentation titles should follow the same conventions minus the program extension. When creating a document or saving a file, author will enter the appropriate information in the template by replacing the generic names in brackets with specific names. Naming and numbering schemes for reports, interfaces, and modifications should use these same naming guidelines and abbreviations. Guidelines for these author-entered items are as follows:

[Application]: SA for Student Administration, CR for Customer Relationship Management, HR for Human Resources, FN for Financials. [Module]: Use the following abbreviations to represent the respective modules: Customer Relationship Management (CR) Modules: SL = Sales MA = Marketing Human Capital Management (HCM) Modules: AW = Administer Workforce BB = Base Benefits PM = Position Management PR = Payroll RW = Recruit Workforce Student Administration (SA) Modules: AA = Advising AD = Admissions AV = Advancement AS = Academic Structure Arizona State University Last revised Page 35
04/23/2006.
PROJECT CHARTER
CC = Campus Community FA = Financial Aid SF = Student Financials SR = Student Records
Miscellaneous Naming Standards

In file names, leave spaces between words. Do not use an Underscore character between words. Capitalize the first letter of all words, except articles and prepositions, in document titles and file names. For titles or file names that include dates, use this dating format: YYMMDD.
6.3.2 Documentation Lifecycle

The lifecycle of project documentation outlined in Table 10 above will typically follow these stages: 1. Meeting discussion / whiteboard graphic / brainstorm To reduce confusion and rework, key points should be captured on paper. All standing meetings and most working meetings will assign a dedicated scribe to make sure that key points are captured on paper or electronically during the meeting. Project team members are encouraged to use the appropriate Microsoft Office tool for their documentation, including: Word, Excel, PowerPoint, Project, and Visio. WIP documentation should be stored on the projects file share: \\itfs1.asu.edu\sishr\ This file share is dedicated to the OASIS project. It is secure (administered by the project) and is backed up daily. There are individual folders for each of the primary functional and technical teams. Completed documentation should be stored in the Files page of the Communication Center: http://www.cedarcrestone.net/index.php? module=user&op=index The Communication Center is hosted by CedarCrestone. Security is administered by the project. Titles, descriptions, topics, subtopics, and document types should be entered for all completed topics. These completed documents are a valuable product of the OASIS project and will be referenced during and after the project. They will certainly be Arizona State University Last revised Page 36
2. Work-in-progress documentation
3. Completed documentation
04/23/2006.
PROJECT CHARTER
helpful during Upgrades and may customizations during Updates & Fixes.
be
helpful
when
reapplying
04/23/2006.
PROJECT CHARTER
7.0 COMMUNICATION STRATEGY

The purpose of this section is to present a Communications Strategy to ensure the timely communication of appropriate information to University community about the PeopleSoft software and project, including its benefits and limitations, features, project funding sources and costs, implementation progress, and impact upon business and academic administration practices.. This undertaking will cause considerable change in the activities of ASU administrative staff, and, to a lesser degree, and in the way faculty and students exchange information and send and receive information to and from the University. This plan defines the goals, strategies, methods, timelines, roles and responsibilities for communicating information about the project to the University community. Understanding that this project will be a learning experience, changes to this plan may be made after its initial distribution with alerts to the community posted appropriately.
7.1
Communication Goal and Objectives
The challenge of the communications team is to help ensure the success of the project during the project lifecycle by using traditional and new media techniques of information and knowledge distribution. The communications plan must be organized, consistent and nimble enough to be modified as new issues arrive. The goals are: 1. Target communications to administrators, staff, faculty, and students. 2. Target communications in order to build and maintain credibility, sponsorship, and ongoing support. 3. Utilize available communication channels and media to increase overall involvement. 4. Build a positive impression within the community. 5. Remain flexible and nimble to adapt as the Project evolves.
7.2
Approach to University-wide Communication
The Communication Coordinator for this project will be the University Technology Office Communications Coordinator and project team members selected by the Project Director. Together they will develop a Communication Plan that determines project milestones, message go-live dates and delivery using traditional and new media tools (ex: faxing media advisories or blogging [or both]). University-wide communication will depend heavily on the contributions of Functional Team Leads, Project Management and University leadership. The Communication Team will proactively recommend communication methods and activity to the Project Management Team and the Functional Council. Timeliness on approval turnaround for communications pieces will be critical to ensure quality and timeliness of delivery.
7.2.1 Critical Communication Success Factors

The following conditions are critical to the successful execution of this Communication Strategy: Arizona State University Last revised Page 38
04/23/2006.
PROJECT CHARTER
Communications efforts are validated by Functional Council and Project Management Team through usage, delivery and endorsement to the larger community of project participants and university community. Financial support and resources will be provided to design, develop, and deliver effective communication materials and events. Feedback is kept confidential communication effectiveness. Creativity is collaborated. Innovative use of new media technology is encouraged. and used constructively to improve
7.3
Roles and Responsibilities
7.3.1 Leadership Involvement

Responsibilities for Project Director, Functional Directors, Team Leaders, include, but are not limited to, the following:

Contribution and participation to communication efforts and team meetings, communication events and required training sessions. Communicate the goals and benefits of the project within their spheres of influence.
7.3.2 Communication Team Roles and Responsibilities

Generate articles and updates regarding the project, for internal and external communications. Creation and distribution of project media press releases, media advisories, blogs, podcasts, wikis, and some web design developments. Planning and coordination of communication update meetings. Identify audiences and their information needs.
7.5
Communication Processes
7.5.1 Leveraging Communication Efforts

Following are a few techniques to help leverage communication efforts and sustain desired behavior:

Develop a plan that is dynamic, interactive and integrated with the overall project plan. Integrate communication initiatives with key project events. Develop a clear, expeditious approval process. Deliver messages in a style that underscores the new direction, behaviors and results of the project.
04/23/2006.
PROJECT CHARTER
8.0 DATA CONVERSION STRATEGY

Only data that is identified by project functional teams as critical to key business processes will be converted to the new database platform. Wherever possible, we will utilize CedarCrestones developed data migration scripts for migrating data to the target PeopleSoft database. Because of their knowledge of legacy data, however, OASIS team members will have primary responsibility for extracting and cleansing data from legacy systems.
8.1.
Conversion Scope
It is typical of most conversion projects to try to convert as much data into the new platform as possible. However, it can be counter-productive to convert data just because it exists. Some data may be better served by not being converted or by being transformed into another usable format. The scope of the data conversion effort is determined by applying the key strategies to three basic questions: What data will be converted? When will it be converted? And what tools or resources will be needed?
8.1.1 What Data will be converted?

As a general rule, data will only be converted if they have been identified by project functional teams as critical to key business processes or to meeting externally imposed regulations. These will be reviewed by functional team members in the context of the Interactive Design and Prototyping (IDP) sessions for the various PeopleSoft Student Administration modules and the respective business processes that they support.
8.1.2 When will the data be converted?

The timing strategy for converting data is based on two key criteria: 78. When will the converted data be needed in the production database in order to meet the targeted go-live dates, which have been staggered to coincide with the administrative activities and information needs of the academic calendar? 79. What are the dependencies of each conversion category on other categories? Based on these criteria, a logical conversion scope and sequence will be determined, which will include the following milestones for each conversion category:

When the mapping of a specific conversion category should be complete When the extraction program for this category should be complete When testing of this conversion category should be complete When the data is needed in the production database When the converted data is required in production
04/23/2006.
PROJECT CHARTER
9.0 TESTING STRATEGY

9.1 Testing Processes
Described below are the types of testing that will be applied throughout the project.
9.1.1 Unit Testing

The goal of unit testing is to test setups, assumptions, business processes, converted data, and customized code for a specific component. The functional team is responsible for developing and executing unit test cases of setup, assumptions, and business processes. The development team is responsible for developing and executing the unit test cases for converted data and customized components. Coding and unit testing will be iterated until all conditions are successfully tested. This testing is the final development activity for an individual component. The unit test plan and results are reviewed according to the quality assurance plans in place for the project before migrating the code from the development to the test database.
9.1.2 System Integration Testing

System integration testing begins once the setup data, converted data, and individual components have been migrated to the test database. The testing team is expanded beyond the initial functional and technical staff to include developers of interfaces and interfacing systems; users; system, network and database administrators; and documentation specialists. While this expanded team is used to define and conduct this testing, the responsibility for fixing errors discovered remains with the original functional and technical team. Simple conditions are tested first, followed by increasingly complex conditions until all inputs, processes, outputs and interfaces have been thoroughly tested. Functional requirements as well as data, security, performance, recovery, documentation and procedure requirements are tested.
9.1.3 Customization Testing

Functional Teams will develop and execute unit test scenarios for each modification to any type of PeopleSoft object, such as a record definition, programming code, report, interface, screen, menu, workflow process, or new application. These test scenarios are developed to assure that the customization has been successfully completed and the underlying processes are performing correctly within the module. If the expected results are not achieved during testing, problems will be documented and reported on a test incident report. The customized objects will be reconsidered and reviewed by the developers to determine whether the customization was improperly performed, or if there is a problem with the validity of the test case scenario and expected results. Corrections will be made as required and the module will be subject to re-test until the expected results are achieved.
9.1.4 Performance Testing

As the implementation progresses, performance and stress testing methodologies will be incorporated into the project planning to validate the performance levels and resolve any issues prior to go-live. Post-production, these methodologies can be leveraged for ongoing monitoring. Arizona State University Last revised Page 41
04/23/2006.
PROJECT CHARTER
9.1.5 Acceptance Testing

During this activity, PeopleSoft outcomes will be verified in a simulated production environment based on user acceptance that the system performs in accordance with the stated objectives and meets ASUs requirements. Testing will be conducted at multiple locations, including off-campus to validate network accessibility. Users accept the system based on their validation of testing results utilizing live data. Users will be provided with test scripts to test supported processes. Their efforts will be supported by functional members of the Core Project Team. Each process to be supported is run through a scripted testing scenario that must yield anticipated results.
9.2 Participants
Representatives from across the University will be involved in the testing of the PeopleSoft system. This includes but is not limited to: 80. OASIS technical team members 81. OASIS core functional team members 82. Technical and functional consultants from implementation partners 83. Subject Matter Experts (SMEs) and other members of the campus community that have become engaged in the implementation
04/23/2006.
PROJECT CHARTER
10.0

END USER ASSISTANCE STRATEGY

Documentation Training Help Desk
The purpose of this section is to present a strategy that encompasses the following end user support service components:
These components must be integrated through common objectives and oversight, and through integration of materials and resources. To achieve this, Help Desk coordinators will work with the Documentation and Training Team to develop an End User Assistance Plan.
Resources
A Documentation and Training Team will be established. This team will consist of the following members:

Functional Project Directors Training Coordinator Training Specialists Functional Leads Documenters (Subject Matter Experts from the functional teams with focus on developing documentation and training materials) Trainers (Subject Matter Experts from the functional teams with focus on delivering training)
04/23/2006.
PROJECT CHARTER
10.1
End User Documentation Services

Documentation Objectives
84. Provide flexible documentation tools to guide core functional users, faculty, and students in performing tasks relevant to their respective roles using the new software 85. Follow a consistent style within the context of the ASU Style guides for printed and web-based media 86. Follow a revision and control process 87. Validate accuracy of information in all end user documentation through thorough testing
10.1.1
10.1.2
Documentation Approach
Each functional team will be responsible for developing the end user documentation for its respective business processes. The Business Process Guide is the foundation for documentation and training materials. The Functional Team Leads will be responsible for identifying each business process that requires additional documentation for ongoing process support. Working with the Documentation and Training Team the functional team will adapt the information in the Business Process Guide for documentation materials. .
10.1.3
End Users Documentation Needs
It is anticipated that documentation material will delivered primarily through electronic media and available through a project website. The following documentation materials are examples of those that will be available:

Training Manuals Business Process Guides Reference Guides Frequently Asked Questions Job Aids
10.1.4
Documentation Development
The Training Coordinator and Functional Project Directors will be responsible for planning and coordinating the document development and revision process. An outline of the steps is presented below. 88. The foundation of good documentation is the participation of those knowledgeable in the business processes within the IDP teams. Team members will leverage current documentation about current processes as well as their experience.
04/23/2006.
PROJECT CHARTER
89. During IDP sessions workbooks provided by CedarCrestone will be modified and adapted to the scope of implementation and functionality needs at ASU. 90. IDP teams will summarize the results of their meetings into Business Process Guides, which will serve as the primary end user documentation. The Business Process Guides will follow a common format using the Business Process Guide Template. 91. The Business Process Guides will be used during testing. Further modification may be made based upon feedback from those involved in testing. 92. The Business Process Guides will subsequently provide the framework for End User Training materials.
10.1.5
Maintenance and Distribution
End user documentation will be stored on the Project Website, enabling immediate updating and self-service access as needed. The Training Coordinator will monitor the revision and control process. Each Functional Team Lead will be responsible for assuring that documentation relevant to his/her area of responsibility is maintained and updated.
04/23/2006.
PROJECT CHARTER
10.2
Training Services
Training Objectives
10.2.1
The goal for training is to provide opportunities for ASU staff to enhance their skills to improve customer service, streamline business processes, reduce operations costs, and increase our systems management capability. To meet these goals, the training team will be guided by these objectives: 93. Develop a process-based approach to ensure that all training is specific to the job tasks of our personnel. 94. Work with administrators to determine the training needs of the management and staff in their areas. 95. Apply a just-in-time schedule for training end users. 96. Provide training through technology where feasible to enable users to complete training with as much convenience as possible. 97. Develop a training curriculum using a variety of tools to match the need for initial training within the available project resources and provide the foundation for an ongoing training program.
10.2.2
Training Approach
The first step in defining the training approach is the development of a training plan for initial implementation. The Training Coordinator will be responsible for developing this plan which will include defining a training curriculum and a schedule for developing materials and delivering training. It is anticipated that the training curriculum will use a modular approach that is business-process oriented and use a variety of delivery methods. Example Delivery Methods: Face to face training using both training specialists and Subject Matter Experts as trainers. Web-based resources for self-paced training including documentation, process guides, training materials and web-based tutorials. Train the trainer offerings where core team members will train key users who will then be responsible for training others in their units.
The project team will use the ASU developed Business Process Guides and training materials and programs developed at other institutions. Resources available to support training efforts include the Training and Documentation team, a separate technical environment for training, training tools licensed from PeopleSoft, training classroom facilities and the project website, Materials developed for initial implementation will be available to meet ongoing training demands.
04/23/2006.
PROJECT CHARTER
10.2.3
Training Processes
There are four processes essential to successfully implementing end user training: communication, enrollment, delivery, and assessment. We outline below activities to be conducted within these processes.
Communication Processes
Using project communication methods, the Training Coordinator and Functional Project Directors will be responsible for communicating the following information to end users regarding end user training:

Training requirements for staff and faculty Training plans explaining what training is required and recommended, based upon role Course availability, schedules, objectives, descriptions (including course length), and options Enrollment information,
Enrollment Processes
The Training Coordinator will manage the training enrollment process that entails the following activities:

Scheduling courses, instructors, and facilities Setting and enforcing course eligibility Registering learners and maintaining enrollment and completion records Correlating security profiles with training needs
Delivery Processes
Delivery of end user training will depend on the type of end user, the number of users who need to learn a specific process, and their location. The Training Coordinator and the Functional Project Directors will work closely with administrators to determine specific combinations of training units needed for ASU staff and faculty members. This information will be documented in the Training Plan. At a strategic level, for the purposes of this project charter, we group end users into four types and will address each group in the training plan. There are four major types of end users: Core functional users (primarily ASU staff and administrators) who process business transactions ASU faculty and instructors ASU faculty and staff who provide assistance to students and customers ASU self-service customers both employees and students
Assessment Processes
An assessment process will be developed to evaluate the following: Arizona State University Last revised Page 47
04/23/2006.
PROJECT CHARTER
Prerequisite skill levels for course entry Competency levels for course equivalency Mastery levels for satisfactory course completion Quality and effectiveness of the training provided
Training Environment
Once an end user training plan has been developed, the training team will be responsible for setting up the training schedule and securing facilities and equipment for hands-on classroom training and open labs, including desktops with the necessary network connectivity, as well as projection and other presentation equipment. The Training Team working with the Security Team will design a PeopleSoft technical environment for training, including training databases with appropriate security.
04/23/2006.
PROJECT CHARTER
10.3
Support Services
Included in this description of a support model which outlines a preliminary strategy, objectives and approach.
10.3.1
Help Desk and Support Service Objectives

1. Train Help Desk staff in PeopleSoft functions and related hardware and browser issues. 2. Accept, document and track service calls. 3. Route trouble tickets to the appropriate technical or functional specialist for resolution. 4. Validate satisfactory resolution of each trouble ticket. 5. Analyze problem reports to serve as feedback for continued improvement of business processes, system enhancements, training, and documentation. 6. Provide a framework for assigning users with the security access to PeopleSoft which is appropriate to their role.
10.3.2
Approach
End user assistance for will be provided by a central support organization. The proposed model is based on both current practices at ASU and an effort to adopt best practices. This model utilizes centralized receiving and tracking of all problems, centralized response to basic or common problems, such as system access and basic system navigation, and referral to technical and functional specialists for more complex problems. If a problem cannot be resolved by ASU staff, an ASU technical specialist will open a case with the hosting vendor, CedarCrestone, or with PeopleSoft. The specifics of the support structure will by defined through the Help Desk plan.
04/23/2006.
PROJECT CHARTER
11.0
POST-IMPLEMENTATION STRATEGY
The Post-implementation strategy must address two critical concerns: (1) The transition from familiar to unfamiliar terms, forms, user interfaces, and processes, and (2) the ongoing operation of the new system. Budget has been identified for system sustainability and staffing needs. The project management team will develop a Transition Plan by second quarter, 2007 which will address the following issues: New Roles and Responsibilities in Functional Areas New Roles and Responsibilities in University Technology Office Implementing desired PeopleSoft functionality not included in the OASIS Project Sustainability of the PeopleSoft system Upgrades
04/23/2006.

Oasis Charter

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oasis Charter

Uploaded by

Copyright:

Available Formats

Arizona State University Oracle/PeopleSoft Implementation OASIS Project Charter

April 19, 2006

Barry Brummund, Technical Director

All All All All All All All

Arizona State University

Last revised 04/24/2006 Page i

Arizona State University

Last revised 04/24/2006 Page ii

Arizona State University

Last revised 04/24/2006 Page v

SA-HCM Implementation Timeline

3/15/2006 Campus Community Defined

6/9/2006 Bio Demo Conversion

12/20/2006 Enrollment History Converted

1/1/2006 12/1/2005 1/31/2006 Academic Structure Defined

7/1/2006 8/8/2006 Course Catlog/Schedule Fall 2007 Conversion

5/20/2006 HCM Milestones Defined (timeline available )

7/1/2007 7/15/2007 Disburse Financial Aid 5/18/2007 Post Grades

3/15/2007 Fall 2007 Registration

10/1/2007 Post-Implementation Support Completed

Summary of Key Milestones

Applicant Data Converted/Applications Loaded / Transfer Articulation/Admission

Arizona State University Last revised Page 2

Arizona State University Last revised Page 4

Apply local knowledge

Accelerate decision making

Arizona State University Last revised Page 6

1.4.1 Complete the project on time and within budget.

Arizona State University Last revised Page 7

1.4.2. Implement a reliable, secure, and scalable technical infrastructure.

Critical Success Factors

Arizona State University Last revised Page 10

2.0 PROJECT SCOPE

Table 1: Project Scope

Customer Relationship Management (Pilot only)

Enterprise Performance Management Other Software

Arizona State University Last revised Page 11

3.0 PROJECT ENVIRONMENT

Arizona State University Last revised Page 12

4.0 PROJECT MANAGEMENT

Project Plan Maintenance

4.1.1 Project Plan Availability

4.2.1 Project Meetings

4.3.1 Weekly Status Reports

4.3.2 Monthly Status Reports

Project Budget Management

Arizona State University Last revised Page 14

4.4.1 Budget/Expense Approval

Budget Status Reports and Review

Arizona State University Last revised Page 15

5.0 PROJECT STRUCTURE

Functional Council Project Management Team

Figure 1: Project Structure

Arizona State University Last revised Page 16

Teams, Roles, and Responsibilities

Table 1: Functional Council

Table 2: Project Management Team

Arizona State University Last revised Page 17

Table 3: Service Teams

Arizona State University Last revised Page 18

Conversion Workflow Security

Data Warehouse & Reporting

Table 4: Core Teams

Arizona State University Last revised Page 19