UT Market Project Charter Document

Document: Charter UT Market v0.6.
docx 1 Last Update Date: 4/27/2010

UT Market

Project Charter Document

Doc. Ref.: Charter UT Market
Version: Draft 6
Status: REVISED on 4/27/2010
Initial Date: 2/4/2010

To be Approved by: FRMS Operational Sponsors and Executive Sponsor

Document: Charter UT Market v0.6.docx 2 Last Update Date: 4/27/2010

Executive Summary

The UT Market project will expand the availability of electronic commerce tools to
faculty and staff at the University of Texas at Austin.

The project will:
Facilitate quick, reliable creation of purchase orders from a broad base of
suppliers;
Provide a foundation for better supplier management that results in lower prices,
quicker delivery, and superior customer service;
Reduce paperwork and labor content in administrative processes; and
Improve accuracy and accountability in transaction processing.

The UT Market project primarily involves implementing a hosted vendor package called
SciQuest for the UT Austin campus. SciQuest is an electronic procurement product that
enables shoppers to browse for products across multiple suppliers, select items for
purchase by putting them in a virtual shopping cart, and assign the cart to an authorized
departmental buyer. The buyer completes the checkout process in SciQuest,
automatically triggering the creation of a populated requisition in POINT Plus. Upon
final approval of the purchase order in POINT Plus, the order details are transmitted back
to SciQuest, who transmits the order to the supplier. Suppliers ship products to the UT
Austin campus while invoices are submitted to SciQuest. SciQuest matches PO details to
any received invoices and to the receiving reports, and transmits payment information to
UT Austin when we are ready to pay the supplier. A pre-populated electronic payment
document is automatically created, ready to be reviewed by Accounts Payable, if
necessary, completing the procurement cycle. The local implementation of SciQuest will
be called UT Market.

UT Market is aligned with the goals and vision of the Financial Resource Management
System (FRMS).

CONTENTS

Introduction ......................................................................................................................... 4
Purpose of the Project Charter Document ...................................................................... 4
Review and Approval of this Project Initiation Document ............................................. 4
Project Definition ................................................................................................................ 6
Background ..................................................................................................................... 6
Project Approach ............................................................................................................ 6
Project Objectives ........................................................................................................... 8
Project Scope .................................................................................................................. 8
Project Deliverables ........................................................................................................ 8
Constraints and Expectations .......................................................................................... 9
Project Governance ........................................................................................................... 11
Roles and Responsibilities ............................................................................................ 11
Project Quality Plan .......................................................................................................... 13
Communication Plan ......................................................................................................... 14
Training Plan ..................................................................................................................... 16
Initial Risk and Mitigation Plan ........................................................................................ 17
Change Management ........................................................................................................ 20

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 UT Market 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, which are essentially the project leadership team, consists of
the following members, in addition to Wade Lorber, Dana Cook and Heather Hanna,
Project Managers.

Fred Friedrich Mary Knight
J amie Southerland J erry Fuller

Kevin Hegarty will be the Executive Sponsor for this project.

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.

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

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;

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.

Project Objectives
The UT Market project will expand the availability of electronic commerce tools to
faculty and staff at The University of Texas at Austin. When implemented, the project
will:
Facilitate quick, reliable creation of purchase orders from a broad base of
suppliers;
Provide a foundation for better supplier management that results in lower
prices quicker delivery, and superior customer service;
Reduce paperwork and labor content in administrative processes; and
Improve accuracy and accountability in transaction processing.
Project Scope
The UT Market project will implement an end-to-end solution from procurement
through payment. The following pieces will be developed:

UT Market shopping portal
o Shopping site across enabled suppliers
o Ad hoc workflow through cart assignment
o Cart checkout to initiate requisition creation
Electronic requisition and PO document
o Dynamic workflow to opt in processing office routing as necessary
o Account and amount distribution at the line item level
o Collect information needed to uniquely determine UT Austin object
code from NIGP commodity code
o Transmit approved orders to SciQuest for relay to suppliers
Electronic invoice receipt
o Receive and store invoices in an Oracle database
Report of finally approved central receiving documents
o Report to be used to trigger manual receipt of items by Accounts
Payable in UT Market
Electronic payment document
o Automatic creation and approval of payment documents when there are
no issues with order receipt and Accounts Payable elects not to review
the payment
o Automatic creation and manual review of payment documents by
Accounts Payable when there are issues with order receipt or Accounts
Payable elects to review the payment
Improved NIGP commodity code to UT Austin object code crosswalk
o Enhance the crosswalk to more accurately determine the UT Austin
object code by including the intent of item use
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.
Standards/Definitions 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.
Testing 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 Documentation 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.
Usability, 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.
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

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.

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.

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):

Roles and Responsibilities

1. Executive Sponsor The purpose of an Executive Sponsor is to provide high-
level 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
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.

5. Shared Services Group The purpose of the Shared Services Group is to ensure
that information is conveyed to all campuses who may be affected by changes being
made to systems and to provide input as to how changes will impact each campus.

6. Project Managers and Project Team The Project Managers, Project
Coordinators, Functional Lead, Technical Lead, and User Services Lead will manage
all day-to-day aspects of the Financial Management System project, including project
plans, deliverables, status reviews, milestone reviews and project team member
activities.

Project Quality Plan

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.

Communication Plan

All communication to stakeholders should consider the needs of the various
stakeholder target audiences to tailor communication to the audience.

This communication plan should be used as a template but refined for each project
phase to ensure communication is best suited for the unique needs for each phase of
the FRMS. After each phase, the communication plan should be assessed and
changed as needed based on lessons learned.

In order to ensure widespread communication regarding the FRMS, the following
medium 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 cross-
campus decision-making perspective. This group is made up of decision makers from
across the campus. This group will meet 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 (i.e. training).

Special FRMS User Groups It may be necessary to establish subject-area-specific
user groups. The purpose of these groups is to obtain feedback from experts in
existing or new processes relating to their specific area of expertise or responsibility.
Additionally, the user groups will be responsible for providing suggestions on
complex reports and additional data requirements back to the project team, plus assist
in evaluating and improving features and the design of the overall system.

E-Mail Bulletins These will be done on an ad-hoc basis to various user groups
established for the project

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.

Status update meetings will be kept to a minimum, and most of the status update
information will be exchanged via e-mail.

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.

Training Plan

To optimize the stakeholder acceptance of the ultimate FRMS deployment, training
should begin early, occur often, and be conducted using a variety of training 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:

Awareness of concepts, features to expect and differences in business processes;
Introduction training for
o Processors
o Approvers and consumers of financial transactions
Specialized training for
o Faculty-heavy colleges
o Large colleges
o Small colleges
o Administrative departments
o Central processing offices
o Auxiliaries
o Shared Service Campuses
Hands-on training to assist people in accomplishing tasks using the new system
(e.g. open labs)

Some specific methods to be employed include:

Classroom instruction
Workshops
Open labs
Q&A sessions
Online videos and web-casts
One-on-one where needed

Initial Risk and Mitigation 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 Financial Resource Management System project is
broad in scope and will enact fundamental change in the administration of the entire
workforce23,000 employees at UT Austin plus the employees at associated
institutions. At the onset of the project, the following risks have been identified:
Risk Mitigation
Lack of preparedness or ability of
dependent software systems (or
resources who maintain these systems)
to provide necessary integration or
functionality. This includes
dependencies on infrastructure hardware
and software that will be required in
order for FRMS projects to be deployed
successfully.
Break project into phases that are
designed and planned in detail such
that dependent areas have time to
prepare to meet the needs of the
FRMS.
Plan for and if necessary, develop
and/or deploy local alternate solutions.
Documentation of dependencies.
Communicate frequently with
dependent areas so they know the
status of the project and when the
project needs their changes to be in
place and the project knows in
advance if the changes will not be in
place
Inability to make planned milestones
and targets
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
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.
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.
Errors in financial data and related data The design strategy to use existing
financial files will mitigate complexity
of development/workflow issues.
Robust testing program, ability to
extend duration and ensure thorough
end to end testing
Controls and monitors in rollout
decision makinge.g. code freeze
milestones.
Controls and monitors post rollout
Sponsor groups do not share a common
vision for the project or support the
project as a team as is required for a
project of this size and complexity.
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.
Go live date becomes more important
as a driver than quality deployment
Use of QA Coordinator to determine if
system is of sufficient quality to be
deployed
Sponsors have ultimate decision on
Go Live dates
Failure to realize and harvest expected
returns on investment in software
development and workflow changes.
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.
System does not meet the needs of the
colleges and university and other
universities that share our software.
Have participation from the Colleges
and departments on the Operational
Sponsor group and stakeholder
advisory groups.
Seek feedback from shared services
Advisory Group.

Make use of focus groups, usability
groups, stakeholder surveys, and data
documenting current behavior.
Reduced transactions/volumes and
process
Communications planning
Shared services site visits, as needed
Training plans
User manuals and materials
Commitment of project staff until
some predetermined date after
implementation to ensure adequate
support of new system.
Lack of physical meeting space, office
space, and training and testing labs.
Sponsors agree to work with the
Project Manager and other university
officials to find and secure available
space
Conflicting internal and external
projects (e.g. HRMS, Shared Services
PeopleSoft migration, etc.) that may
affect financial data or project staff.
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.
Changes in the institutional mission and
objectives as a result of economical,
political, environmental, etc. factors
resolution.

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.

Change Management

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.

[This section is specific to the FRMS Procurement Project.]

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.

UT Market Project Charter Document

Uploaded by

Copyright:

Available Formats

UT Market Project Charter Document

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UT Market Project Charter Document

Uploaded by

Copyright:

Available Formats

Document: Charter UT Market v0.6.

docx 1 Last Update Date: 4/27/2010

You might also like