FRMS Transfers. Project Charter Document

FRMS Transfers Project Charter Document FRMS Transfers Charter.docx 1 Last Update Date: 8/2/2011

Executive Summary The FRMS Transfers project will simplify and streamline the process of creating requests for transfer of funds (RTFs) at the University of Texas at Austin. The project will: Facilitate quick, reliable creation of RTFs; Reduce labor content in the administrative processes; and Improve accuracy and accountability in transaction processing. The FRMS Transfers project involves implementing a Web system to replace functionality currently hosted in *DEFINE. Users will no longer need to know what type of transfer document they need to create, nor know the transaction object codes to assign to individual transactions. The system will prompt users for the information necessary to automatically generate the appropriate accounting transactions. It will also improve controls around the allowability of transfers, requiring less manual review in the processing offices. The FRMS Transfers project is aligned with the goals and vision of the Financial Resource Management System (FRMS). FRMS Transfers Charter.docx 2 Last Update Date: 8/2/2011

CONTENTS Introduction... 4 Purpose of the Project Charter Document... 4 Review and Approval of this Project Initiation Document... 4 Project Definition... 5 Background... 5 Project Approach... 5 Project Objectives... 7 Project Scope... 7 Project Deliverables... 7 Constraints and Expectations... 8 Project Governance... 10 Roles and Responsibilities... 10 Project Quality Plan... 12 Communication Plan... 13 Training Plan... 14 Risk Management Plan... 15 Change Management Plan... 18 Implementation Plan... 19 FRMS Transfers Charter.docx 3 Last Update Date: 8/2/2011

Introduction Purpose of the Project Charter Document This document has been produced to capture and record the basic information needed to direct and manage the FRMS Transfers project. It addresses the following fundamental aspects of the project: 1) What is the project aiming to achieve? 2) Who is the target user group? 3) Who will be involved in managing the project, and what are their roles and responsibilities? 4) How and when will the project be executed? 5) What resources will be available to the project? Review and Approval of this Project Initiation Document The first version of this charter document will be reviewed by the Operational Sponsors, using the following Quality Criteria: 1) Is the objective of the project clear? 2) Is the scope of the project clear? 3) Does the document correctly reflect the project? 4) Is the project management organization complete? Have all the roles been considered? 5) Are the relationships and lines of authority clear? 6) Have the risks of the project been assessed? 7) Are any variations from the standard process workable and agreed to by relevant parties? For examples, variations to the Quality Process, changes in Sponsors, or other teams? The Operational Sponsors include Fred Friedrich, Jerry Fuller, Mary Knight, and Jamie Southerland. Kevin Hegarty is the Executive Sponsor for FRMS. The project charter and project plans for each phase of the overall project will be approved by the Operational and Executive Sponsor. Once approved, this charter document will provide the Baseline for the project. It will be referred to whenever a major decision is made about the project and used at the conclusion of the project to measure whether the project was managed successfully and whether it delivered a quality outcome for the stakeholders. FRMS Transfers Charter.docx 4 Last Update Date: 8/2/2011

Project Definition Background [This section is from the FRMS Project Charter.] The administrative software systems used by UT Austin have historically provided reliable and stable transaction processing. The systems permit the university to capitalize on a highly decentralized IT environment to support goals in real time, through coordination of subject area and IT experts. The financial system which includes a wide array of applications including general accounting, cashiering, cash management, accounts payable, purchasing, financial reporting, general ledger and chart of accounts, inventory, tax reporting, travel, departmental accounting, budget, facilities, and pre- and post-award research has evolved into a similarly stable and reliable toolset; however, the CASE project revealed a number of focus areas for the future, if these systems are to remain viable: A need to integrate existing university administrative systems in order to realize the benefits and efficiencies of a comprehensive and fully aligned ERP. The need for documentation and transparency of business processes Increased need for business integration and business process redesign A need for centralized support and standards for stakeholder training, customer service support, and improved communication. A need to convert legacy mainframe user interfaces to a web-based design. A need for increased planning associated with business continuity and disaster recovery, long term platform, hardware and software choices. The FRMS Project will respond to the issues identified above, in improving the finance system utilized in the UT Austin and UT System communities. Project Approach [This section is from the FRMS Project Charter.] The FRMS Project will be designed, developed, and deployed in alignment with the administrative software systems strategic plan. Some of the elements of the strategic plan that are worth highlighting as important in this project include: The (project) should value collaboration for streamlining business processes and providing clarity and consistency to users over the ability to control impact or ensure benefit to an individual unit; Project plans should ensure an integrated system that avoids redundant functionality, cumbersome business processes, and siloed design; The (project) should have flexibility in adopting new technologies, infrastructure changes, and process changes as they best serve the university; FRMS Transfers Charter.docx 5 Last Update Date: 8/2/2011

Functional experts should be paired with information technology professionals to couple expertise in industry trends and cutting edge business integration with sound and flexible technological solutions; The governing body should clearly define which features of the ERP are core and as a result should be consistently deployed across all business units where feasible. Processes outside the core should be developed as extensions and allow for configuration by each campus or business unit; Assumptions and critical success factors should be clearly stated and identified as part of the functional specifications; Interface design should focus on optimizing each target stakeholder groups experience. This may include maximizing efficiency and speed, data access, simple and accessible navigation, and should gear workflow and procedure automation towards maximizing the stakeholder experience; and, Systems deployed should be intuitive so training time is reduced and processes are easily understood. Additionally, the project will be approached in small, manageable efforts using an iterative development and deployment methodology. Iterative development refers to a process in which sponsors, technical experts, functional experts and stakeholders are continually refining requirements and output over multiple development efforts, versus trying to determine all requirements up front and implementing on a specific date as is common in application implementation projects. Some of the many reasons for this approach are as follows: Complex development projects have a better track record for success using iterative development. The stakeholders are typically not fully able to articulate requirements until at least one or two iterations are done and there is output to review and react to. Management typically does not make a full commitment to a project until actual results are tangible and obvious. Visible results demonstrating progress can be seen quickly. Given the complexity of this project and all of the dependencies on other systems and personnel throughout the UT Austin campus and the state, the Operating Sponsors will be responsible for prioritizing the phases that will be in scope. During the first phase, the Operating Sponsors will review all efforts underway and in the pipeline for the future. FRMS Transfers Charter.docx 6 Last Update Date: 8/2/2011

Project Objectives The FRMS Transfers project will simplify and streamline the process of creating requests for transfer of funds (RTFs) at the University of Texas at Austin. The project will: Facilitate quick, reliable creation of RTFs; Reduce labor content in the administrative processes; and Improve accuracy and accountability in transaction processing. The FRMS Transfers project involves implementing a Web system to replace functionality currently hosted in *DEFINE. Users will no longer need to know what type of transfer document they need to create, nor know the transaction object codes to assign to individual transactions. The system will prompt users for the information necessary to automatically generate the appropriate accounting transactions. It will also improve controls around the allowability of transfers, requiring less manual review in the processing offices. Project Scope The FRMS Transfers project will implement a streamlined process for processing requests for transfer of funds. Transfer document(s) Transfer modify document(s) Transfer status page Transfer search page Project Deliverables Process Diagrams These should be done by business experts from a process standpoint and by the IT leaders. They should document attributes, relationships, field names, indexes, keys, filters, etc. Business Rules These should define what must be true for the process being implemented to function accurately. Glossary This data will provide for consistency, maintainability and repeatability in the project (or others to follow) and define what is meant by certain key terms. Test Plans and Results This will include the testing plans and critical thresholds that were tested to ensure the highest quality and attainment of phase objectives for system functionality and stakeholder delight. Communication/Training Plans This will include a plan and curriculum to address the various user groups needs and perspectives. Metrics Metrics will be defined and monitored so that efficiencies that are expected can be monitored, increasing the opportunities for them to be achieved. FRMS Transfers Charter.docx 7 Last Update Date: 8/2/2011

Usability, Accessibility, Internal Audit, Focus Group, and User Feedback This will include a plan for and documentation of how project decisions are made and vetted through stakeholders in order to ensure the system meets the needs of the various user groups needs and perspectives. Where possible, decisions will be supported by metrics. Security Assessment Design specifications will be reviewed by the ISO and the final product will be scanned by the ISO for website vulnerabilities. Detailed Project Plans A detailed project plan that outlines milestones and contingency plans. Benefits and Return on Investment documentation Every subproject of FRMS will have an associated benefits and ROI document that will be developed early in each subproject. Baseline metrics will be gathered for later analysis of impact as well as documentation of expected changes to campus. Constraints and Expectations [This section is from the FRMS Project Charter.] As stated in the administrative software systems strategic plan, the FRMS Project will not be successfully implemented unless the following Critical Success Factors are achieved: Knowledgeable, Decisive Leadership Without trusted and empowered leadership, progress will be slow and benefits achieved will be marginal at best. Appropriate Governance The governance structure should be established such that it is characterized by a clear mission, defined scope, appropriate stakeholders, and commonly embraced values. An important aspect of the governance structure is the requirement that the business needs drive the deployment of the university ERP with the support of key partners such as IT and user support services (such as training and communication). Shared Vision If the university leadership collectively agrees to a shared vision for the university ERP and how it can best support the mission of the university, all aspects of the deployment of the university ERP will be made easier. The vision should be clearly communicated to ensure that while the ultimate vision for the project is shared and known, it is also clear that the deployment of the first phase of Financial Resource Management System will not achieve the ultimate vision of the project but that subsequent phases will be undertaken to achieve this vision over the course of several years. Environment By fostering an environment that is characterized by teamwork and collaboration, success will be easier to achieve. Improved support, training, documentation, communication, user involvement, business process transparency and support for lifelong learning will help create an environment to attain the maximum success possible. FRMS Transfers Charter.docx 8 Last Update Date: 8/2/2011

People To achieve the strategies in this plan, the most talented staff will be required to be committed to these efforts for many years. A commitment to the people resources required for each phase should be achieved prior to each phase beginning. Adequate Funding Additional resources and a realignment of current resources will also be required with plans and methods to harvest the expected return on this investment. A commitment to the funding required for each phase should be achieved prior to each phase beginning and be appropriately allocated to each member institution benefiting from the administrative system. Time Regardless of the financial and human resources provided, a significant amount of time will also need to be invested. Wisely balancing the need to complete and implement solutions in a timely manner with the risk of a poor implementation or a poor solution is critical. A detailed project plan that is developed prior to each phase beginning as well as following an iterative development methodology will assist in the project being on time. Technical Infrastructure Maintenance and deployment of administrative software cannot succeed without stable, dependable, high-performing, scalable and secure technical infrastructure. Assessment Responsible stewardship demands periodic assessment to determine if the chosen course continues to be the best course of action given changes in industry, product availability and success of the university ERP. The definition of success should be defined before the project is started and should be measurable. FRMS Transfers Charter.docx 9 Last Update Date: 8/2/2011

Project Governance Project governance will follow the administrative software systems strategic plan governance model with the addition of two new groups (UT Austin Advisory Group and Stakeholder Leadership Group): 5 Shared Services Group Operational Shared Services group - functional area leadership from all participating campuses 2 UT Austin Administrative Systems Operational Sponsors Similar make up to HRMS Operational sponsors following a review of current membership and unrepresented areas (Mary, Fred, Jamie and Jerry) 1 3 UT Austin Administrative Systems Executive Sponsor Kevin Hegarty UT Austin Advisory Group functional area leadership from all participating campuses 6 Project Managers Project Team 4 Stakeholder Leadership Group Directors and Asst/Assoc Directors in Stakeholder departments (Amy, Kim, Robin others added as subprojects dictate) The project team should be a combination of IT and functional team members. Members should be staffed by the most talented and appropriate resources available. Where services are not within the scope of shared services, flexible, consistent, standard interfaces will be developed. Roles and Responsibilities 1. Executive Sponsor The purpose of an Executive Sponsor is to provide highlevel strategic direction on the project, cascade project sponsorship throughout the university, and resolve resource and budget constraints. The Executive Sponsor will meet with the Operational Sponsors and Project Managers quarterly to receive an update on project status and resolve outstanding issues, in particular those related to resources. At this time, the Executive Sponsor should review the strategic direction of the project and adjust as appropriate to ensure that the project remains in line with university goals and objectives. (In order to minimize meetings, the Executive Sponsor can participate in monthly Operational Sponsor meetings). 2. Operational Sponsors The purpose of the Operational Sponsors is to establish project objectives and deliverables, determine project priorities, provide tactical project direction to the project and resolve and act as a final decision point for any issues, including questions of policy that cannot be resolved by the Project Team. Operational Sponsors will meet bi-weekly with the Project Managers to monitor project progress, review deliverable status, resolve issues as appropriate and ensure that timelines are being met. The scope of any established objectives and policies FRMS Transfers Charter.docx 10 Last Update Date: 8/2/2011

developed by the Operational Sponsors will operate within the strategic direction established by the Executive Sponsors. 3. UT Austin Advisory Group The purpose of the UT Austin Advisory Group is to provide broad-based advisement to the Operation Sponsors and project team related to the project. This group will be made up of representatives from all portfolios and/or their departments as each portfolio sees fit to be included. 4. Stakeholder Leadership Group The purpose of the Stakeholder Leadership Group is to help determine how proposed changes will impact daily operations and/or strategic direction of their units, gain consensus on direction, and provide input as to how the systems are envisioned, designed and deployed. This group will be made up of Directors and Assistant/Associate Directors from Stakeholder Departments. The make up will be determined by the Operational Sponsors. 6. Project Managers and Project Team The Project Managers, Functional Leads, Technical Leads, and QA/Testing Coordinators will manage all day-to-day aspects of the Transfers project, including project plans, deliverables, status reviews, milestone reviews and project team member activities. FRMS Transfers Charter.docx 11 Last Update Date: 8/2/2011

Project Quality Plan [This section is from the FRMS Project Charter.] One of the important roles on the FRMS project is a Quality Assurance (QA) Coordinator. The QA coordinator and all those who work on the QA team will have responsibility for all quality reviews. After each project milestone (i.e. major project deliverable within a phase), the QA Coordinator will be asked to conduct a final quality review with their team. If the deliverable is acceptable, then the QA Coordinator will sign off that the milestone is complete. The reason for this review is to ensure that each deliverable works as expected and quality software is deployed. The QA Coordinator will be responsible for defining the QA methodology for the project to include incident tracking and response system and processes, test plans and checklists. Quality reviews at project milestones will be accepted based on the following criteria: Software performs as expected Data changed by the software results in accurate updates to the database Integration points between FRMS and other areas are working properly (to be coordinated with QA specialists in the area FRMS is integrating with) The file and software design supports efficient processing (load time for the initial screen and subsequent update screens are within user-defined acceptable limits) Feature/functionality being tested has been through stakeholder usability testing, focus group or feedback or in some way has been vetted through the stakeholder of the feature or function. FRMS Transfers Charter.docx 12 Last Update Date: 8/2/2011

Communication Plan All communication to stakeholders should consider the needs of the various stakeholder target audiences to tailor communication to the audience. In order to ensure widespread communication regarding the FRMS Transfers project, the following media will be used: Status Reports In order to provide regular updates to stakeholders, the Advisory Group, Operational and Executive Sponsors, status reporting will take place at regular intervals. These reports will be placed on the FRMS Web page so that all interested parties can review them. UT Austin Advisory Group Provide important feedback to the project from a crosscampus decision-making perspective. This group is made up of decision makers from across the campus. This group meets monthly. Town Hall Provide important feedback to the project from a cross-campus data entry/processor perspective. This group is made up of primarily front line document creators and people who deal with financial management issues on a regular basis. This group meets monthly. Monthly in-person update to wide financial management (*DEFINE) community - Monthly presentations to the UBOC and Town Meeting groups to spread knowledge about the system and inform them about important dates and activities, e.g. training. E-Mail Notifications These will be sent to creators and reviewers of current users of Requests for Transfer (RTF) documents in *DEFINE to inform them about important dates and activities, e.g. training. Public Website The FRMS public website will contain general information about the project status, system availability, and contact information. Project Team The FRMS core project team (those individuals who report to the Project Manager) will meet regularly for both status updates and collaborative work sessions. Collaboration work sessions will be held frequently to make sure all project team members are working in harmony. Between work sessions, project team members will be encouraged to speak to other team members about the project in person when possible (preferable), via phone or web meeting when in-person is not possible, and via e-mail as a last resort. This will require that project team members make an extra effort to see each other and find opportunities to work in labs or war room environments. FRMS Transfers Charter.docx 13 Last Update Date: 8/2/2011

Training Plan To optimize the stakeholder acceptance of the product, planning for training will begin early. Training opportunities will be announced early, and training will be conducted timely, so that users will know about the new system and how to use it at the time the new system is implemented and before the existing system is decommissioned. Training will be offered as often as demand dictates and conducted using a variety of methods. A Training Coordinator will be responsible for developing a detailed training plan for the project. Some of the types of training to be included in the detailed plan will be: Introductory training for o Processors o Approvers Hands-on training to assist people in accomplishing tasks using the new system, e.g. open labs Some specific methods to be employed include: in-system help pages askus information sessions open labs online videos one-on-one where needed The following tasks will be scheduled: Evaluation of existing training materials to be adapted or deprecated Identification of new training materials needed Development of training materials Scheduling of classes and open labs in TXClass Walkthroughs of training materials Deployment of training FRMS Transfers Charter.docx 14 Last Update Date: 8/2/2011

Risk Management Plan Risks are inherent in any project. As a result, risk logs and mitigation plans are maintained throughout the life of a project to ensure that plans are in place to minimize project impact. The FRMS Transfers project will change the way internal transfers are processed on campus, moving functionality to the Web, simplifying the process for the departments, and minimizing the need for processing offices to review individual transfer documents. At the onset of the project, the following risks have been identified: Risk Inability to make planned milestones and targets Project is not staffed appropriately with the right number of people or people who do not have the talents, experience, and skills required for the project. This may lead to impaired or failed deployment. Errors in financial data and related data Mitigation Highly developed project plan Frequent monitoring of progress and risk plan. Put in place a prioritized feature list so that if the project or phase needs to be scaled back, it is easy to do. Project governance structure Critical path decision process Before each phase of the project begins, the Executive and Operational Sponsors will receive a resource plan for the phase and appropriate resources should be allocated prior to any work beginning. If there are significant losses to the project that result in staffing problems, the Project Manager will work with the sponsor groups to determine if the project can continue and be successful. Robust test plan Ability to extend duration and ensure thorough end-to-end testing Controls and monitors in rollout decision making e.g. code freeze milestones. Controls and monitors post rollout FRMS Transfers Charter.docx 15 Last Update Date: 8/2/2011

Risk Sponsor groups do not share a common vision for the project or support the project as a team. Go live date becomes more important as a driver than quality deployment Failure to realize and harvest expected returns on investment in software development and workflow changes. System does not meet the needs of the colleges and university. Mitigation The charter is used as the basis for the project to which all sponsors agree to use Sponsors agree to work in concert with the Project Manager to come to agreement on any issues that need resolution. Use of QA Coordinator to determine if system is of sufficient quality to be deployed Sponsors have ultimate decision on Go Live dates Detailed quantifying of benefits by comparing resource processing requirements for current environment versus those that will be required with new system. Commitment of project personnel to follow up and monitor user acceptance to ensure desired results are attained. Have participation from the Colleges and departments on the Operational Sponsor group and stakeholder advisory groups. Seek feedback from FRMS Advisory Group. Make use of focus groups, usability groups, stakeholder surveys, and data documenting current behavior. Simplify process Communications planning Training plans User manuals and materials Commitment of project staff until some predetermined date after implementation to ensure adequate support of new system. FRMS Transfers Charter.docx 16 Last Update Date: 8/2/2011

Risk Lack of physical meeting space, office space, and training and testing labs. Conflicting internal and external projects (e.g. HRMS, Shared Services PeopleSoft migration, etc.) that may affect financial data or project staff. Changes in the institutional mission and objectives as a result of economical, political, environmental, etc. factors Effect on financial reports that are using the document type in the selection criteria Mitigation Sponsors agree to work with the Project Manager and other university officials to find and secure available space Sponsors agree to work in concert with the Project Manager to come to agreement on any issues that need resolution. Fred and/or Mary will keep the Business Services Council (BSC) updated and involved in any necessary discussions so that conflicts in priorities might be identified early and changes to plans and schedules made accordingly. Sponsors agree to work in concert with the Project Manager to come to agreement on any issues that need resolution. Effective communication to all IT groups that might have developed reports that select by document type Throughout the life of the project, risks in addition to those listed above will be identified. Each identified risk and corresponding mitigation plan will be documented in a project log and reviewed with Project Sponsors on a bi-monthly basis. Any risks that have potential wide-spread impact will be reviewed with the Executive Sponsor during quarterly meetings. FRMS Transfers Charter.docx 17 Last Update Date: 8/2/2011

Change Management Plan The purpose of change management is to define and implement procedures and/or technologies to deal with changes in the business environment and to benefit from changes. Successful adaptation to change is as crucial within an organization. For the FRMS project, all changes to the software, business processes, and the like will be documented to ensure proper tracking. At present, the university is pilot testing a new software version control system that will enable the software to be automatically versioned, thus making change management of the software much easier. The project team will need to define version control methodologies in case the pilot project is not fully deployed for the project to use. During planning, the project team will set a code freeze date. The code freeze is the point after which the systems to be implemented are substantially complete in the Quality Assurance environment; only trivial changes to systems or procedures will happen after this date. Before the code freeze date, changes in the scope, timeline, or available resources may be proposed to the project managers. The project managers will take the proposed change to the project team, who will evaluate the benefit of the change. If the project team agrees to the change and the change does not significantly impact the timeline or deliverables, the project team can approve the change and the project managers will adjust the project plan as necessary. If the project agrees to the change but it substantially impacts the timeline or deliverables, then the change must be approved by the Operational Sponsors, who will consult with or inform the Executive Sponsor as appropriate. After the code freeze date, changes in the scope, timeline, or available resources may be proposed to the project managers. The Operational Sponsors will be asked to review and evaluate the proposed change. If the Operational Sponsors approve, they will set the parameters that the project managers will use to adjust the project plan. If the change will substantially impact the timeline or deliverables, the Operational Sponsors will consult with or inform the Executive Sponsor as appropriate. FRMS Transfers Charter.docx 18 Last Update Date: 8/2/2011

Implementation Plan The purpose of the implementation plan is to define how to transition from the existing system to the new system. The implementation plan needs to answer several questions: 1. When will the code base be implemented in production? 2. How will the new system handle the display of data processed in the old system? 3. Will the old system continue to be used to view data processed in the old system? 4. How will the old system be altered to allow other campuses to continue its use, but to disallow user by UT Austin staff? 5. Will the new system handle transactions in process at the time the new system is implemented? 6. Will there be a date where transactions can no longer be initiated in the old system? 7. Will there be a date by when transactions initiated in the old system must be completed? 8. How will these rules be communicated to constituent groups? 9. How will tier one support be handled during the implementation timeline? 10. How/When does support transition to its final state? FRMS Transfers Charter.docx 19 Last Update Date: 8/2/2011