Student & Academic
Administration System
Project Charter
& Work Plan
Project Charter
Assumptions & Priorities and the SAA Rollout
The
Project Charter was initially drafted in June 2002. Many parts of the Charter were used since the FAST Project
began. Many parts were included in
the Project Management Handbook from 1999.
However the Handbook did not have very wide distribution or reference.
The financial schedules and cost schedules were added in July 2002.
In
July, the project work plan, target schedules and cost estimates were assembled
and provided to the project Executive Management to be included in the Regents
PeopleSoft Project Status report of August 2002. During the management review process of the PeopleSoft
Project Status report to the Regents in July 2002, many of the target schedules
and funding assumptions were changed. Since
that time, the project assumptions, work plans and project cost schedules have
been under review. Therefore the
schedules, work plans and cost schedules included here are no longer valid.
The
project charter revisions must be revised to include the changes made in the
project strategies, many of which are listed below, but most significant of
which is the change in the timing of delivery of the SAA Rollout, which is to be
based upon available funding rather than timeframe as the major determinant.
Changes
in project strategies to be applied into the next version of the work plan and
cost schedules include (but many are subject to change):
1.
The project is based upon the priority of available funding stream rather
than targeted to address a proscribed completion date.
2.
The roll out may proceed sequentially to each campus rather than
simultaneously.
3.
Sequence will be determined at later date.
4.
A decision to implement the UHCL Financial Aid
module had not been made.
5.
Consultants will be used on a strategic approach
instead of full time during the project.
6.
Consultants will not provide project management assistance.
7.
The project will take longer than the 2005 timeframe previously planned.
8.
Back fill funding was eliminated.
9.
UHCL PS 8 should be rescheduled for completion in
October 2003.
10.
Functional analysts will be hired to the project
team instead of lent to the project team by the business process owners.
11.
Work by the functional process owners will be
conducted elsewhere that at the project team facilities at the University
Business Park.
12.
The anticipated reduction in development items as a
result of the continuing discussion from the post fit gap business process
review sessions have not yet been identified.
The Project Charter will be updated in conjunction
with revision of the work plans, target schedules and costs estimates after the
Business Process Options Review sessions.
November
21, 2002
Bob Shortle
July 2002
FAST Project Office
University of Houston System
Table of Contents
Expectations and Anticipated Benefits
Project Sequencing – Testing Multiple Institutional
Processes
Purchase of Available Modules - PeopleSoft TASP Deployment
Project Management
Organization
Student And
Academic Leadership Group - Steering Committee
Student And
Academic Leadership Group
Project Implementation Process
User Acceptance Test & Implementation
Project Implementation Considerations
Testing and Standards Compliance
Decision Making Process Priorities
Business Process
Options Review
A. Meta Level Fit Gap Requirements
Meta Level Fit Gap Discussion with PeopleSoft March 6,
2002
Insert pages for
fit gap analysis here
C. Centralized versus Decentralized Database
& Operations
Evaluation of Single versus Multiple Database Environments
This Project Charter identifies key strategic decisions that keenly impact the definition of the project. Decisions at this level represent Executive Sponsor support for the project and provide directions to guide the Project Charter development and planning process.
Executive Goal
This Project Goal as set forth by the Executive Sponsors:
The goal
is to install and upgrade the PeopleSoft Student & Academic
Administration system that over time is at a level of equal or better business
functionality and service, while maintaining
vendor support by implementing new releases.
This goal was derived from the directions given by the Board of Regents to install a centralized, state of the art, vendor-supported, integrated system. This plan for the installation of the PeopleSoft Student & Academic Administration system for all UH System universities will achieve the directive set forth by the Board of Regents.
Project Objective
The Project
Objective is to successfully install new software within the implementation
scope as defined by the plans adhering to the multiple priorities of achieving
installation within a reasonable time schedule and within an acceptable budget,
while meeting as many requirements as possible.
Implementation Scope
The Scope of the Implementation for this project
includes:
- Student Records, Student Financials, Student Financial Aid, Admissions and Campus Community modules from PeopleSoft.
- Installation of these PeopleSoft modules at UH, UHV and UHD to replace existing systems (UH/UHV Student Administration, ABC, Financier; and UHD Banner, PowerFaids).
- Fit Gap sessions will identify functionality provided by the existing systems not contained in the PeopleSoft modules. Plans will be built upon analysis of the requirements gaps to meet the required functionality.
- Development items (modifications, interfaces, reports, integration automation, workflow and business rules and tables set-up) resulting from the Fit Gap sessions are identified in the Plan section. Any additions or changes will be subject to the Project Charter Scope Control procedures.
- Upgrading the Student & Academic Administration system installed at UHCL to PeopleSoft version 8.
- Interactive Voice Response (IVR) will be continued for all institutions
- Academic Advising will be included as an option for all institutions and schools.
- Professional and graduate level schools at UH will be included.
- Distance Learning and support for MITC is included except as noted in the following paragraph.
The Scope of the Implementation for this project does not
include:
- Continuing Education
- Modifications for creating consolidated processes to support unique MITC needs.
- Modifications for creating common processes to address issues from the 1998 Oracle Business Process Project.
- Data Warehousing and reporting solutions beyond a copy of production data for reporting purposes.
- Imaging
- Workflow, distributed data entry and approval of transactions, except where specifically noted to meet existing requirements from the Fit Gap analysis
- Conversion of existing data from supplemental systems for back-up and historical reporting purposes including historical Coordinating Board reporting and historical Fact Book Reporting except for the storage of the data onto the PeopleSoft storage areas in their existing data storage formats
- Hardware and Technical requirements have been identified separately by CCTS.
Common Processes and Alternative Solutions Discussions
Following the FIT GAP sessions, estimates were developed for the effort to install the software, including all customizations and other development items required to fill the gaps identified in the software requirements. From the plans, timelines and staffing needs were developed to project the cost of the project including making all changes to the software to fill the requirements. These estimates represent an expected “TOP” or “CAP” to the project cost.
The requirements sessions identified areas for review and discussion. There was insufficient time to hold these sessions after the Fit Gap sessions and still develop the Plan to meet the report timeframe established by management and the Regents. Furthermore, the participants were not sufficiently familiar with PeopleSoft to fully evaluate the options; therefore, separately discussions are being planned for the upcoming months.
The purpose of the discussions will be to hold cross campus sessions to identify and discuss options and alternatives including modification of current business practices, development of common procedures, processes, forms and reports and to evaluate options and alternatives to the development items in the CAP plan.
It is anticipated that Business Process Options Review discussions will result in reductions in the development items in the plan. All proposed changes would be reviewed and estimated for the impact on the cost, resources and time to the project plan. As part of the Project Charter, such items constitute a change in the project scope control that require Executive Sponsor review and approval according to the scope control procedures describe in later sections of the Project Charter.
Planning Assumptions
The Plan was determined using a number of assumptions and predictors and a summary of the general assumptions is listed below. (Specific assumptions associated with each project and application module are listed with the detail project plans section.)
Management
1. Executive Sponsors will have a direct hand and active participation in the allocation of resources, removal of barriers, creation of new practices and policies necessary and encouragement to everyone involved in this enterprise wide endeavor.
2. Decisions will be made rapidly as needed by those participating as outlined in the decision making section.
3. Resources will be committed to staff the project on a full time basis as further defined in the Organization section
Project Scheduling
1. The SA&A installed at UHCL will be upgraded to PS 8 first.
2. The SA&A system will be extended to the three other universities (UH, UHD, UHV) simultaneously to reduce costs and project duration.
3. The Financial Aid system will be installed at all four universities simultaneously at all universities and during the extension of SA&A.
Project Costs
1. Consultants will be minimized to providing only advice and counseling to reduce the project costs.
2. Staffing to undertake the project implementation will be obtained from the departments responsible for the systems at the various universities (campuses). (Staffing will follow the model used for Finance project)
3. The Plan calls for availability of staff, from the FAST Project, from ES and CTS and from the offices of the business process owner departments. Some existing positions are vacant and that some are not yet budgeted and authorized.
4. The work included in the project plans assumes that development items (modifications, interfaces, integration efforts, reports and interfaces) are required to fulfill all of the requirements gaps identified. Future Project Options Review sessions are expected to identify option to the development items. Such a review anticipates that options to the development items will reduce the total cost.
5. Contingency was built into both the timelines and into the costs to cover unforeseen changes and problems.
Project Timelines
1. UHCL SA&A Upgrade to PS 8 – Start July 2002, End March 2003
2. UHCL Financial Aid - To Be Determined and to be incorporated with the installation of FA at the same time with the other campuses.
3. UH, UHV, UHD – Start July 2002 – End November (to be determined)
4. Does not include time to create common process or consolidated documents described in the Expectations and Anticipated Benefits Section.
Expectations and Anticipated Benefits
Process owner management must develop project Expectations and Anticipated Benefits anticipated from the new system. Those benefits typically expected include:
- Improved quality, access and visibility of information
- Integrated business processes
- Automated updating and processing information
- Common software and hardware platforms resulting in easier UHS and vendor support
- Ease in training, ease of use
- Improved student and faculty responsiveness
- Self Service Support for student and faculty system usage
- Increased control of business processing by users
- Reduction in transactional costs
Many of these benefits will not be fully realized until after the system is installed and a mastery of the system is developed. In many cases, a second wave of innovation is required to apply the new system to further automate and streamline processes. In some areas, additional resources will be required to provide additional functionality and services to the targeted customer constituencies.
Each group benefiting from the system should prepare a detail listing of expectations their benefits or costs and the corresponding time frame. Within 90 days of the project initiation, management should review these expectations and benefits to determine goals for each area. The effort to identify the anticipated benefits and to estimate the additional work has not been undertaken.
Project Management
will work with the S&A process owners and users to review options between
July and September to identify alternatives, consider business process
modifications, search for common practices across schools and across
universities to further refine costs and reduce development items.
From a recent white
paper by Synergy3, sponsored by PeopleSoft,
"Expectations for the return on investment
(ROI) include automating and streamlining processes, reducing manual input,
sharing data, improving services through 24-hour access, overcoming the risk of
using aging technology, and freeing resources to focus on providing service.
To achieve the ROI from implementing a new
or replacement student information systems, higher education institutions must
focus on an enterprise-wide approach.
Success factors include:
·
Information
technology plan
·
Management, administration,
technology executive, and faculty buy-in
·
Strong
executive champion
·
Clear measures
for performance improvement and cost savings
·
Training and
change management programs"
Resource Requirements
These plans have been developed assuming that the resources identified in the plans are willing and available to participate, which is not the case. The planning process has been started around the efforts required to identify the needed resources, rather than plan around the resources available.
The Project Lead position, yet still named in the organization structure, is vacant and other positions that have been identified are not yet approved and funded. There are also vacancies in the business offices unfilled. Staff members required from the functional areas (business process specialists) have not yet been formally allocated to the project efforts although they are participating in the Fit Gap sessions. After the required plan is reviewed and staff members can react and respond and adjustments can be made to fit the current reality.
We also expect that the business process specialists to be assigned to the project be on a full-time basis or nearly full-time, that they have broad and thorough knowledge of the subject matter areas and that they have the authority to make the thousands of decisions needed without having to consult with their superiors. A significant difference in the approach to this project from the Student Administration & Academic System installation at UHCL is the approach of the Fast Project Staff. In that effort, the FAST project team was expected to conduct all of the data and rules set-up, develop the testing scripts, conduct the testing, develop the training materials and train the key training staff at UHCL. Contractors assisted the project staff as needed. UHCL participated in limited testing, and until the revision of the expanded work plan after the initial Go-Live date, was not heavily involved. In this planning cycle, the responsibilities have been reversed. The Business process owners, the subject matter experts or the functional or business analysts from the campuses are expected to perform all of the set-up and business rules development, create the test cases, conduct the testing, develop the training materials and conduct the training at their campuses. The FAST Project Functional Team Facilitators will provide necessary consultation and guidance on how to conduct the work, rather than completing the work. Consultants will be used to advise the Lead Facilitators when and where needed. This approach was best used with the financial system project successfully and achieved a higher satisfaction and quicker transfer of knowledge to the process owners.
Contingency funds have been identified to deal with the reality view and the uncertainty of the future. Other problems will occur, as people leave the University during the project. In the nearly four years of the project, all top five FAST project management members have left the University or project. Contingency funding for staff augmentation for such interruptions, but this cannot be specifically quantified. Project management should review the loss of key personnel upon the impact of the project schedule as it would other scope control issues.
One important consideration is the need for backfill staffing. Although discussed in the project’s early stages, nothing was made available. The following sections contain a review of the need for allocating funding for backfill. Estimates of the costs for backfill have been included in the plans.
One of the best ways to increase the efficiency and reduce
that cost is allocate key internal staff members fulltime to the project from
start to finish instead of external consultants. In most if not all cases, the only way to do that is to
“backfill” those positions. While
there’s a cost associated with backfill, that cost is usually much less then
the alternative, which is not to backfill and therefore not dedicate key
internal staff fulltime to the project.
There are numerous benefits to allocating the appropriate internal staff
to the project fulltime. A further
discussion of the benefits and considerations is included in Appendix D.
Key Considerations
Key considerations in the high level planning process must deal with the following items to provide a basis for the decision to move forward with this project and to provide information for the planning.
These key considerations evaluated include:
- Project Sequencing – Testing Multiple Institutional Processes
- Database Design – One database per campus or one common database?
- Database Design – Integrated with HRMS or Separate?
- Will the PeopleSoft TASP software be employed?
- Backfill for key business process Owners Staffing will be provided
Project Sequencing – Testing Multiple Institutional Processes
The second implementation of the student and academic administration system should be at a campus other than UH Central.
Managing daily tasks and processing, such as printing catalogs and fee bills, would be simplified if the volumes were smaller. Utilizing the same system and database is more manageable with smaller institutions. If UH Central campus is the second wave of installations, we run the risk of finding problems with multiple institutional conflicts from which the recovery would be more difficult.
Based upon this premise, UH Victoria should be the candidate for the second installation because the time and effort to install Victoria is significantly less: fewer students, schools, programs, careers, majors, etc. Victoria is also the most similar school to UHCL with enrollment of only upperclassmen and masters candidate students. UHV also need of fewer of the modifications requested by UH.
We would lose some of the parallel efforts afforded by the installation of all three remaining campuses. However, operations for UHV could be available in only 12 – 15 months.
Data Base Design
Crucial to the origination
of the project was the need to centralize reporting and to integrate financial
information from the student application into the financial applications. One suggestion has been to separate the
databases by university. Separate
databases allow each university to maintain its own data and provide its own
technical support. The design of the
PeopleSoft system allows each university to maintain unique database
requirements within a common structure.
Separating the databases would require additional integration facilities
and diminish the integration capacities as required by the project originators.
Appendix A contains review of the
advantages of each approach and the operational costs of such support.
Separate HRMS/ SA Databases
The strength of the design
by PeopleSoft is the common use of database elements for both the Human
Resources (and payroll) with the Student Administration modules. This allowed a single update of common
information without interfaces, which is valuable for students who are also
employees. Common reference or set-up
tables no longer require duplication and procedures to maintain the
synchronization between business process owners from the groups of each area.
Due to this integration,
software application changes and upgrades must be jointly planned with student,
finance and HR areas.
One means to relieve this
coordination planning is to separate the database elements and operate the HRMS
and Student applications separately.
This would require additional integration routines and the development
of business processes to synchronize the updating of common information tables. The estimate of these activities is
projected to be of greater cost than the savings in the joint planning
restrictions. Furthermore, the project
requires precious resources required to further enhance the HRMS system and to
extend the student application to the other universities. Finally, it has been openly discussed that
PeopleSoft plans to provide this database separation as free upgrade in the
future, removing some of the cost to the separation activities.
Purchase of Available Modules - PeopleSoft TASP Deployment
The Fast Project purchased TASP modules from PeopleSoft, which is a specially developed add-on application for use with Texas schools. PeopleSoft is expected to provide ongoing maintenance; however, the product has only been applied at one community college in Texas. UH will be the test-bed for use by four-year universities.
The purchase, rather than development, of additional PeopleSoft modules has been the approach undertaken. It was expected that the FAST Project would purchase the Coordinating Board module; however, PeopleSoft withdrew support for the Coordinating Board add-on module. As other schools purchase PeopleSoft for their enterprise solutions for Student & Academic solutions, UHS plans to cooperate and collaborate to develop and maintain commonly needed modules. This will follow the practice that was established with the HR module and our collaboration with UTHSCSA for Comptroller of Public Accounts for HRIS reporting.
Backfill
The cost and effort to implement a PeopleSoft software
solution is significant. One of the
best ways to increase the efficiency and reduce that cost is allocate key
internal staff members fulltime to the project from start to finish. In most if not all cases, the only way to do
that is to “backfill” those positions.
While there’s a cost associated with backfill, that cost is usually much
less then the alternative, which is not to backfill and therefore not dedicate key
internal staff fulltime to the project.
There are numerous benefits to allocating the appropriate internal staff
to the project fulltime. A further
discussion of the back fill topic is included in Appendix D. The plan includes the costing of backfill
staffing.
 |
Project
Management Organization
Roles and Responsibilities
Advisory Council
Advisory Council is comprised of senior executives from UHS who are stakeholders in the project and are committed to its success. The Advisory Council provides project guidance and is responsible for the overall success of the project.
This committee also reviews the decisions made which affect the project resources, budget, timeline or campus policies. Issues impacting more than one campus may also be presented to the Advisory Council for resolution.
Chair: Chuck Shomper Meeting
Frequency: Monthly
Responsibilities:
·
Determine
ability of organization to support planned changes in terms of financial and
other resources, i.e., backfill positions, hardware, training, etc.
·
Provide
tie-breaking vote in the event that the Student and Academic Leadership Group
is unable to reach closure of its own or business decisions go beyond
functional jurisdiction.
·
Define
project ownership, organization and reporting relationships.
·
Oversee
project support, ensuring that needed resources are made available.
·
Review
the project budget and overall project plans.
·
Determine
measures of project’s progress & success
·
Provide
project vision and direction.
·
Ensure
inter-division cooperation throughout the project.
·
Monitor
high-level project status.
·
Communicate
with other groups to champion ongoing project support and sponsorship.
Student And Academic
Leadership Group - Steering Committee
The Student And Academic Leadership Group – Steering Committee is composed of Student Administration and Academic executives from all four of the campuses. This group is responsible for reviewing proposed system development, or business process changes to avoid system development, and approving their resulting impact on the project scope and budget.
This committee is also responsible for resolving issues that are undecided by the Student And Academic Leadership Group.
Chair: Elwyn Lee Meeting
Frequency: Monthly
Responsibilities:
·
Available
and supportive with a list of expected results and targets.
·
Oversee
human resource allocation.
·
Oversee
the project budget.
·
Oversee
unresolved implementation and integration issues.
·
Oversee
overall project plans.
Student
And Academic Leadership Group
The Student And Academic Leadership Group is composed of Student Administration and Academic stakeholders. The Student And Academic Leadership Group collectively decides major project objectives, schedules, and priorities and is responsible for ensuring that the project effort meets the business requirements of UHS for function, cost, schedule, and quality.
This committee also makes decisions on project issues brought forth by the individual teams. Issues are presented to the Student And Academic Leadership Group when the issue impacts the project budget, timeline or campus policies. Issues impacting more than one campus may also be presented to the Student And Academic Leadership Group for resolution.
Co-Chairs: Application Project Lead and Steve Webb Meeting Frequency: Bi-Weekly
Responsibilities:
·
Available
and supportive with a list of expected results and targets.
·
Monitors
the alignment of the overall project delivery to business needs.
·
Resolves
high-priority issues.
·
Secures
UHS resources to conduct the project.
·
Ensures
inter-division cooperation throughout the project.
·
Monitors
project status.
·
Communicates
with other groups to champion ongoing project support and sponsorship
·
Manages
project risks
Project Director
The Project Director is responsible
for project coordination & communication while staying within the
parameters of the budget & timetable.
The Project Director is responsible for managing activities on the
project.
Typical Responsibilities include:
·
Identifies project risks
·
Monitors project scope and UHS
expectations
·
Coordinates project work plan and
activities
·
Communicates status and issues to
the Advisory Council
·
Ensures timely and adequate
communication throughout the project team
·
Monitors project schedule &
milestones
·
Identifies resource needs
Application Lead
The Application Lead is responsible
for coordinating project team activities and identifies issues requiring
decisions by the Student and Academic Leadership Group. Coordinates activities between the various
teams to ensure cross-functional communication.
Typical Responsibilities include:
·
Monitors project progress and the
quality of deliverables on an ongoing basis
·
Coordinates project work plan and
activities
·
Reviews deliverables
·
Ensures consistency of activities
and deliverables across teams
·
Communicates status and issues to
Project Director and Student And Academic Leadership Group
·
Ensures timely and adequate
communication throughout the project team
·
Manages project priorities
Technical Lead
The Application
Lead is responsible for coordinating project team technical activities and
identifies issues requiring decisions by the Student and Academic Leadership
Group. Coordinates activities between the
various technical teams, the application teams and the other technical
resources to ensure communication.
Typical Responsibilities include:
·
Monitors project progress and the
quality of deliverables on an ongoing basis
·
Coordinates project work plan and
activities
·
Reviews deliverables
·
Ensures consistency of activities
and deliverables across teams
·
Communicates status and issues to
Project Director and Student And Academic Leadership Group
·
Ensures timely and adequate
communication throughout the project team
·
Manages project priorities
Team Facilitator
The Team Facilitator serves as the
management contact for a particular team.
The team facilitator will be responsible for coordinating meetings,
managing and resolving team issues, issuing status reports, and reporting
progress to the project management team as well as serving as liaison between
the project management and campus lead.
Typical Responsibilities include:
·
Ensures work is being completed
according to the agreed upon deadlines
·
Reports progress of team to
project management
·
Coordinates and facilitates team
meetings
·
Facilitates team progress
·
Manages identification and
resolution of team issues
·
Coordinates team resources
UHS Campus Lead
Functional/technical specialists – Perform as a project team member,
leader for the individual campus and as a subject matter expert.
Typical Responsibilities include:
·
Assures that deliverables meet the
business and/or technical requirements
·
Ensures all deliverables are
documented, reviewed, and completed timely
·
Knowledge of end user needs
·
Knowledge of business processes
& procedures
·
Knowledge of management
expectations
·
Responsible for achieving team
milestones
·
Communication of business needs
& gaps to team facilitator
·
Look for business process
improvement opportunities
·
Aid & carry out testing
·
Assisting with data
conversion/interfaces
·
Assist in training
·
Aid in report definition
·
Completion of project tasks
· Assist in building & reviewing prototypes
Project Team Members
The following are the members of
each group.
|
Project Management Team |
|
Project Director: Bob Shortle Student & Academic Application Lead: to be hired |
|
Admissions Team |
|
Team
Facilitator: Peggy Osbourn UH
Admissions Lead: to be assigned:
to be assigned UHCL
Admissions Lead: to be assigned UHD
Admissions Lead: to be assigned UHV
Admissions Lead: to be assigned |
|
Student Records Team |
|
Team
Facilitator: Gayle King UH
Admissions Lead: to be assigned UHCL
Admissions Lead: to be assigned UHD
Admissions Lead: to be assigned UHV
Admissions Lead: to be assigned |
|
Financial Aid Team |
|
Team
Facilitator: To be hired UH
Financial Aid Lead: to be assigned UHCL
Financial Aid Lead: to be assigned UHD
Financial Aid Lead: to be assigned UHV
Financial Aid Lead: to be assigned |
|
Student Financials Team |
|
Team Co-
Facilitator: Katina McGhee Team
Co-Facilitator: To be hired UH
Student Financials Lead: to be
assigned UHCL
Student Financials Lead: to be
assigned UHD
Student Financials Lead: to be
assigned UHV Student
Financials Lead: to be assigned |
|
Academic Advisement Team |
|
Team
Facilitator: To be hired UH
Academic Advisement Lead: to be
assigned UHCL
Academic Advisement Lead: to be
assigned UHD
Academic Advisement Lead: to be
assigned UHV
Academic Advisement Lead: to be
assigned |
|
Campus Community Team |
|
Team
Facilitator: Peggy Osbourn UH
Campus Community Lead: to be assigned UHCL
Campus Community Lead: to be assigned UHD
Campus Community Lead: to be assigned UHV
Campus Community Lead: to be assigned |
|
Technical Team |
|
Team
Facilitator: Steve Webb Data base: Grace Davila, Jitender Kumar,
Susie Winters Network
Lead: Charles Chambers Hardware
& operating systems Lead:
Fran Beach Programming
Lead: Steve Webb Programming
Team: Leo Moreno, Meredith LaGrone, Annette Culberson, Brian Thompson, Richard
Wall, and others to be assigned and or hired Upgrade
Analyst: Lupe Sosa |
Project
Implementation Process
The
Project Implementation process is a fundamental cornerstone to the successful implementation
of the PeopleSoft application. At UH, a
sound process is especially significant because of the breadth of the planned
implementations. A large number of
resources will be used to redesign processes and develop several applications
on a variety of schedules. Most of
these implementations will be completed in several highly integrated sequences
of installations. The Project
Management process used to control this number of activities is critical to the
enterprise wide success of the FAST Project initiative.
Managing
the Systems Implementation portion of The FAST project will be accomplished
using the standard implementation methodology pictured in the following
diagram. This diagram illustrates the
fundamental project phases that will be used to control and report on the many
activities carried out within the project area and phase. Following the diagram, each standard phase
is documented, with type of activities carried out within that phase.
The standard project phases are listed across the top of the diagram. The activities listed in each box are only representative of the type of activity carried out with each.
The FAST Project has employed CIBER as its implementation partner. CIBER was selected for many reasons including a wealth of expereience including its own proven project planning methodologies. Application of their proven project templates has resulted in some alternate names for the same project planning phaese and tasks. However, the methodologies are very complementary. Any initial apparence of discrepancy is quickly resolved when an inspection of the detail tasks is undertaken to examine the differences. To the practitioner, those discrepancies are easily understood and dissolved during execution.
Planning
The Planning phase of a project is where the initial
scope of the project should be established and documented. Funding should be appropriated and a project
plan should be prepared to properly assess the anticipated staffing
required. This project plan will also
be used to establish the schedule for all project deliverables. The tasks included in this phase are the
following:
·
Define
the project scope and organizational units and processes impacted.
·
Identify
the current structure, resources, processes and policies of the impacted
operations.
·
Develop
the project plan and high-level staffing and budget requirements for successful
project delivery.
·
Gain
budget approval for the project.
·
Define
the project team roles and responsibilities.
·
Create
the service contracts for all support areas required for the project (change
management, data administration, technical support, administrative, customer)
·
Mobilize
the project team and establish all working environments required.
·
Define
high-level success criteria for the project.
·
Define
standard project deliverables to be produced by the project.
Process Analysis
The Process Analysis phase of a project is where the
project base-line is created as a measure of future project success. The preliminary steps required to support
Fit Analysis and Design and Setup are incorporated into this phase. This is also the phase where all work with a
‘beta’ application is undertaken. This
work is aimed at influencing the vendor design of the application at a point
early enough in that development cycle where such influence may save work
required by UH when the final application is received. The tasks included in
this phase are the following:
·
Customer
and end-user requirements definition.
·
Customer
satisfaction assessments.
·
Identify
core processes and prioritize opportunities.
·
Develop
‘as-is’ process models.
·
Identify
specific problems to be analyzed.
·
Define
baseline performance measurements for the project.
·
Implement
product ‘demo’ and ‘beta’ systems.
·
Develop
strategy for moving from current to planned operations.
·
Identify
interfaces and versions of interfaces to be included in project.
·
Install
development hardware and software.
·
Identify
key ‘to-be’ process models to be tested during FIT analysis.
Fit & Gap Analysis
The Fit & Gap Analysis phase serves to introduce
the applications to the key personnel who will ultimately be required to use
this software. These personnel will
confirm the capabilities of the software and determine how the software fits the
needs of UH. The tasks included in this
phase are the following:
·
Define
the high level ‘to-be’ process models.
·
Confirm
high level business policy and operations requirements.
·
Idenfity
external compliance reporting
·
Identify
functional detailed fit of software.
·
Resolve
functional gaps inherent in software.
·
Identify
detailed user interfaces.
·
Identify
report requirements.
·
Identify
data sources.
·
Identify
conversion requirements.
·
Identify
high-level ‘to-be’ data requirements.
Design & Setup
The Design & Setup phase creates a prototype
system based upon the information developed in the Fit Analysis phase. The objective of prototyping is to confirm
that the software is capable of supporting the business requirements and
related processes and functions. In addition, the processes traditionally known
as business process redesign will be incorporated into this phase.
All conversion requirements are resolved in detail, and detail design
specifications are completed where further development is required. The tasks
included in this phase are the following:
·
Populate
setup and control tables.
·
Prototype
all delivered functionality.
·
Develop
a detailed plan for implementing new business process models, organizational
changes and job redesigns.
·
Design
new or modified outputs.
·
Design
software interface requirements.
·
Design
control audits and security requirements.
·
Design
system extensions and additional functionality.
·
Analyze
data conversion requirements and design conversion systems.
·
Develop
and test all conversion programs required to support the application.
·
Document
modifications required to software.
·
Prioritize
list of required modifications, including estimates.
·
Document
all required workflow changes for implementation.
·
Document
required report development, including SQR, Crystal, PS Query.
·
Design
modifications to desktop standards.
·
Design
new user processes and documentation.
·
Design
new user training tools and processes.
·
Design
user, technical and ongoing support requirements.
·
Design
software test processes and cycles.
Development
Development includes the classical tasks associated
with application development. During
this phase, the design specifications are developed into executable code and
tested for compliance to the specifications.
This includes all aspects of the system, including modifications to the
core applications, interfaces, and the additional reporting required to support
the new business processes. In
addition, production of procedure manuals and training of end users takes
place. The tasks included in this phase
are the following:
·
Develop
and test all application code required to support system as designed.
·
Develop
and test all report code required to support the new processes.
·
Perform
all system and integration testing required to prepare the new application for
the User Acceptance Test.
User Acceptance Test & Implementation
During this phase the developed software is tested
as a whole. This test process is
usually conducted as a user exercise rather than as a technical systems
exercise. Once complete, the users not
only confirm the accuracy and reliability of the developed software but also
confirm their ability to use it. All
data is converted during this phase and the system is implemented into
production. The tasks included in this
phase are the following:
·
All
software processes are tested by user.
·
All
converted data is tested for accuracy and integrity.
·
All
user processes are tested for accuracy and completeness.
·
All
user security processes and accesses are tested.
·
All
production processess are tested.
·
Disaster
recovery processes are tested.
·
Hardware
failure processes are tested (including catastrophic failure).
·
Production
cutover processes are performed.
Deployment
After the first implementation of new production
software is complete, the software is considered ‘installed’. Any additional implementation phases, sites,
users or workstations are considered additional deployment. This phase may continue long after the
initial ‘implementation’. The tasks
included in this phase are the following:
·
Install
additional workstations after initial implementation.
·
Install
additional users after initial implementation.
·
Install
additional application server hardware, especially at additional sites after
initial implementation.
Project
Implementation Considerations
Conversion
The Project should carefully weigh the costs of individual conversion
efforts against the ‘perceived’ benefits.
Two key considerations should be answered.
1.
Is the quality
of data targeted for conversion of sufficient quality that comparative reports
using this data will be of value?
2.
While there
may be needs, can the needs be met in a more cost-effective manner other than
converting data?
Data conversion
represents one of the top two activities the Project Team’s technical personnel
will be working on. It is critical to
both project timeframes and project costs that the University critically and
objectively assess the data conversion needs.
During the implementation the conversion process is an iterative
process; multiple loads will be performed at different times during the
project. Early conversion efforts will
concentration on sub-sets of basic key data.
Subsequent data loads will continue to add data as well as correct
earlier versions.
After the conversion needs have been established, a detailed conversion
strategy and approach for each application will be established by the
functional and technical project Leaders
for each areas. These plans will include
the following elements:
1.
Identify the
detailed scope for each legacy system.
·
Identify automated conversions where feasible.
·
Identify manual conversion where not feasible.
·
Identify source files/data and quality of existing data.
·
Assign responsibility for who will write the actual data
extract programs from the legacy system(s) and who will enter the actual data
loads to PeopleSoft.
·
Identify how the data will be loaded (i.e., using the Import
Manager within PeopleSoft with edits or via batch mode using SQR’s and no
edits).
·
Identify how the data loads will be reconciled (development
and use of compare reports) and who will be responsible for the reconciliation
(functional subject matter experts).
2.
Conversion
Process Overview.
·
Document the high-level conversion process that will be followed.
· Determine the number of conversion iterations and timeframe requirements for each conversion program.
Conversion should be
undertaken early, long before the target PeopleSoft system is ready to
expect. The first step would be to
extract data from the legacy systems.
Edit reports should be written to validate the values within the
data. Business owners responsible for
the data should correct errant data whenever possible, and when not, identify
routines to clean the data as part of the loading process. This step should also identify when data
scrubbing in the PeopleSoft system will occur after the data conversion. The second step is to develop conversion and
load routines to reformat and transform any data to meet the business needs and
to fit into the PeopleSoft tables’ formats.
When all of the requirements
of data conversion are identified and estimated, the project plan should be
revised and approved through the decision making and scope control management processes.
Interfaces
The implementation of the Student & Academic Administration system will have require internal and external interfaces. Required interfaces will be designed and implemented during Prototype 4 – Environmental Adaptations. For each required interface, detailed specifications will be developed Project Team members. This will also require various levels of information and participation in interface design and testing from external vendors and University of Houston departments.
A complete list of interfaces will be developed in the Fit/Gap process.
Consideration will be needed for the timing of the interfaces. Some interfaces will be temporary, such as those that interface to existing financial aid systems. These interfaces will be dissolved after the time period for which the existing financial systems are replace by the PeopleSoft financial aid systems, and the data in the existing financials systems are no longer processing information for students in the active financial aid year.
Interfaces to local systems or shadow systems will be the reasonability of the local campus. Extracts using PeopleSoft development and reporting tools and applying PeopleSoft security will be the responsibility of the local campus. Direct-access read and write capabilities to the data bases outside of the PeopleSoft environment will not be permitted to maintain the integrity and security of the information.
Reporting
Each PeopleSoft module comes with a limited number of “canned” reports, both Crystal & SQR. In order to lessen the cost and impact to the project, the University should attempt to use the delivered reports wherever possible.
A major advantage of the PeopleSoft system is support for end-user access to integrated data for analysis that supports operational and strategic decision-making. For end users, PeopleSoft delivers Query, which can be used to extract data for Excel or plain list printing. The Crystal reporting tool is also delivered, however this can be difficult for most end users to master. PeopleSoft’s nVision reports, while primarily used in the financial area, can also be developed for the other suites. If properly created, the drill down advantages of nVision can be used in S&AA system.
The University has creating a reporting database; a separate daily copy of production that would minimize the impact of system intensive reporting request on normal production processes. The reporting database would be as ‘fresh’ as the last nightly copy of production.
Successfully shifting the primary reporting burden from IT to the functional areas will involve some process change management. Striking the proper balance between end user report development and IT development is a similar issue with which most universities have grappled.
Development Standards
Standards for the design and development of customizations are critical to successful implementation efforts and post-production support. These standards include naming conventions for database objects; approval processes for proposed modifications, code review and unit testing. A central point of control and a decision-making process has been established. Changes to records and panels that are well documented, will make future upgrades easier. A business case is required for each proposed system change.
Naming convention standards ensure that all University of Houston developed objects are easily identified. Typically, all PeopleSoft object names begin with ‘PS’. All custom or modified objects should use have a unique identifier, such as ‘UH’. This greatly facilitates future upgrade efforts, which rely on ‘compare’ reports to identify differences between PeopleSoft versions.
The development standards, naming conventions and procedures for the PeopleSoft environment were established for the initial PeopleSoft installation.
For detailed recommendations on development standards,
please see Operations Guide http://www.uh.edu/fast/DesignStandards.pdf. For details on the production change control
management process see http://www.uh.edu/fast/changemanagement.htm.
Documentation
Documentation is critical in managing change to the system throughout its life and to ensure consistent and appropriate use of the system. Current and accurate documentation facilitates rapid and exacting changes, reducing the cost of system corrections and modifications. The documentation effort will be an integral part of the project, conducted throughout the course of the project, not just at the end. The development of the documentation for these systems is primarily an end user department responsibility co developed by the trainers for consistency. This is the only way to ensure that the documentation will meet the university’s support personnel’s needs. By developing the documentation it reinforces the training preparation and the testing. The Team Facilitators will work closely with team leads and staff to provide guidance and support, and can provide samples and templates of end-user documentation and documentation of customization specifications.
It is expected that the delivered PeopleSoft system documentation will be supplemented with documentation of all customizations to the PeopleSoft modules. Customization documentation will include bridges and interfaces to and from the PeopleSoft modules, all reports, queries, and logic designed and built to extend the delivered system, all procedures needed to operate the system, and terminology used in conjunction with the PeopleSoft system. It will also include panel views using the University of Houston’s data.
User Documentation
User documentation consists of detailed descriptions of how to utilize the completed system. This includes run procedures for the scheduled batch runs, desk procedures to be used in concert with the on-line system, and terminology definitions to assist where University of Houston’s terminology is different than that used within the PeopleSoft system. User documentation should be process based, offering ‘how to’ guidance as staff perform their daily activities.
UH may elect to define two or more levels of user documentation, one for typical users and another for ‘power users’ who have additional system responsibilities such as table maintenance, troubleshooting, etc. This would consist of the basic users manual plus documentation of the additional functionality.
User documentation is not static, to be of value it must be updated as system functionality changes or new procedures are implemented. Documentation planning should include the designation of staff responsible for on-going documentation maintenance through out the life of the system. It is recommended that documentation be located in a centralized, on-line location with easy user access. This will eliminate excessive paper consumption and updates can be done in one place without distribution concerns.
Security
The security for the PeopleSoft system will be important in deploying the system. The universities current policy is to assign security responsibility to the process owners. Because the database and security is shared between HRMS and Student Administration, specific process fro sharing security administration is needed. The PeopleSoft version 8 upgrade also requires revamping of the security. The security standard is that security must be limited to the lowest level/ limited access available. The specifics for providing security access and data usage within the system will be determined as part of the project. Prior to acceptance testing, the university should execute a security test, to verify that the setup properly restricts access while allowing for individuals to complete their work.
Security Layers
Due to the nature of client/server technology, there are several layers of security involved when accessing a PeopleSoft application. They are file server security, RDBMS (database) security, and PeopleSoft online security. When all layers of security are implemented, users have to pass security authorization at each level. As the University of Houston continues to plan and apply system security, they should understand the individual roles these different security layers play in securing the system, and how they work together to protect sensitive PeopleSoft application data.
File Server / Network Security
In a networked environment, users share hardware and software resources. Every network has its own security system for controlling user access to its shared resources. This system includes the following security measures:
- Assigned IDs and passwords for user identification and verification.
- Authorized log-on times.
- File access rights, such as execute, read-only, read/write, no access, and so on.
The University can use server file access rights to restrict a user’s access to PeopleSoft applications. To do this, do not grant read, read/write or execute access to the application. This prevents the user from running the restricted application.
For example, to run SQR reports, users need read or execute access to the network directories containing the PeopleSoft-delivered SQR’s and the SQR program itself. By not granting access rights to these directories and files, the University of Houston can prevent users from running SQRW to generate reports. All PeopleSoft file server directories will be established as read-only.
Database Security
The Oracle relational database management system (RDBMS) has its own security system, which works in conjunction with PeopleSoft online security. The University of Houston will generally rely on RDBMS Security to:
- Control who can logon to a database and what they can do once they logon.
- Control which tables or views operators can access and the commands they can use to manipulate data.
- Control who can perform server system administration activities.
- Access directly to the Oracle RDMBS will only be permitted though PeopleSoft security.
PeopleSoft Online Security
The PeopleSoft system is comprised of many components—menus, processes, object definitions, application data – and the University of Houston can control access for many of them.
When a user signs on to PeopleSoft, they enter an ID and a password. If the ID and password are valid, the user is connected to the database and their user profile is retrieved. If the user is not signing on during a valid sign-on time—as defined in their security profile—they are not allowed to sign on. The University of Houston can specify both a sign-on time allowed and time-out interval (how long the machine can remain idle before it automatically logs off) using Security Administrator.
The Security Administrator PeopleTools also controls what parts of the PeopleSoft application each user can access. The security administrator can do this by granting or restricting access to the PeopleSoft menu bars (each menu bar represents an application or PeopleTools), menu items (the commands available on the individual menus), and dialog box options.
Process Security
Using Process Scheduler, the University of Houston can assign Process Definitions to various Process Groups, then grant or restrict user access to those groups using Security Administrator. If a process definition is not assigned to a user’s authorized process groups, the user is not allowed to run that process.
Object Security governs access to the individual database object definitions—record definitions, field definitions, panel definitions, and so forth. Using Object Security, the University of Houston can grant developers full access to the PeopleTools they need (using Security Administrator), while protecting particular object definitions from being modified.
PeopleSoft also provides a number of ways to control the application data that a user is allowed to access in the system. In many cases data can be secured at the table level (queries only), the row level, and field level.
Query is a PeopleTools that helps build SQL queries to retrieve information from the application tables. For each Query user, the University of Houston can specify the records they are allowed to access when building and running queries. The University of Houston can do this by creating Query Access Groups—with the Tree Manager—then assigning operators to those groups—using Query Security.
Query security is only enforced when using Query; it doesn’t control run-time panel access to table data.
The University of Houston can design special types of SQL views—security views—to control access to individual rows of data stored within the application database tables. PeopleSoft applications are delivered with built-in, row-level security functions tailored to specific applications.
For example, in PeopleSoft HRMS, security tables are provided that enable you to restrict operator access to employee rows according to organizational roles, or to permit an operator to view and update rows for employees in their department only. Similarly, in PeopleSoft Student administration you can use security views to determine who has access to which universities, schools and programs.
Field Security
PeopleSoft doesn’t provide field security within a row
except as how the information may be divided by separate panels, now pages in
version 8. However, using PeopleCode,
one could restrict access to particular fields or columns within the panel of
an application tables. However, this is considered a modification
to the delivered product.
Version 8 Changes
The most significant consideration for security is the wholesale change or version 8. Generally the security information will need to be rebuilt, as it doesn’t convert. Security activities will require full time attention to initiate the new training.
For details on the security, please reference the Operations Guide http://www.uh.edu/fast/UHS_OpsGuide_v2_d6.htm.
Testing and Standards Compliance
Testing must be an on-going activity throughout all steps of the project and should be an integral component of the University’s quality assurance efforts. The Project Team members, functional experts, and end-users will be primarily responsible for conduct testing. Testing involves the definition of test scenarios, building of test cases, definition of acceptance criteria, execution of the test cases, and validation of the test results. Correction and re-testing continues until user acceptance is attained. Testing is primarily a responsibility of the functional users for each campus and not for the Project Team, although thorough technical testing is also critical. The University’s expects to have the end-users signoff that system processes are working as expected. This approach works within the overall objective of implementing an end-user maintained and ‘owned’ system.
Thorough testing is essential to the delivery of a quality product and will be conducted in all stages of the project. Testing activities include:
Test Scenarios
A test scenario is the documentation of the scope of a testing effort. It identifies the portion of the system being tested, the approach to the test effort, and the expected outcome of the testing. One or more test cases will be defined to accomplish the defined test scenario.
Test Cases
A test case is the data and the process steps to test the system or a portion of the system for correctness, in support of a test scenario. A test case is comprised of a statement of the portion of the system being tested; the input data to the system for this test; the base data to begin the test; the process steps to be performed to accomplish the test; and the expected outcome from the test in the form of expected data results and deliverables. Test cases should be established for both functional testing and technical testing of the test scenario.
Test cases are also referred to as test scripts. The business process documentation as described through the Fit/Gap and other sessions will also serve as an excellent basis for generating test cases. As these test scripts are completed they serve as a good foundation for documentation efforts.
In order to minimize test case development, cases should be developed so that individual cases used for specific task testing can be used as a component of later business process and integration testing.
Functional Test
To validate the functionality and correctness of the components being tested the user defines a functional test. This will involve the users entering data, executing system functionality in processing and generating output (reports and queries), and verifying the results of the test.
Technical Test
A technical expert defines a technical test to ensure that the system operates correctly from a technical and performance standpoint. This involves the technical specialist verifying that the system operates correctly, that bridges are correctly developed, that data loads correctly, that control tables are loaded, and that the system fixes are applied and operate correctly.
Unit Test
This is a test with a narrow scope, relating to the test of a single module, a conversion process, an interface, a report or query, or any other single component of the system. This test includes both a technical test and a functional test, with the task owner taking responsibility for configuration and base documentation. Test cases for the unit test will become components to build into scripts or cases.
Integration Test
An integration test verifies the correctness of several system components working together. This test includes both technical and functional testing, validating the ability of the system components to “talk” to each other and pass data correctly. These intermediate signoff points help ensure user ownership and knowledge transfer.
System Test
The system test is the full-system testing of all unit and integration tests to validate that all aspects of the system is a functional test. This will require both functional and technical testing.
Stress Test
The stress test will assess the ability of the system to handle expected production-size volumes. A number of people will be required to generate a simulated volume for a high volume activity function such as student registration during grading period, at a month-end financial close, and during a payroll processing cycle.
Parallel Test
The parallel test is used typically to compare results from the new system to results or expectations from the old system. The downside to a full parallel test is that the same data must be entered in both systems. This can be very labor intensive and time consuming. Payroll expects to conduct a parallel test prior to go-live. The parallel test will consist of multiple pay cycles using only limited data entered into the old version system.
Acceptance Test
The acceptance test is the final testing of the full system after it has been placed into a ‘non-live’ production environment. This test can include performing the same tests as used during the system test, and may include a mini parallel test where data previously run into the existing system and the results can be cross-checked and validated. Upon user satisfaction with the final acceptance testing, the University will take ownership, and cut over from the old system(s) to the new system.
The testing methodology to be utilized at the University of Houston will include parts of all of the above types of testing. Testing will start out at the unit level, in essence testing small bits of functionality encompassed within a single module. As any customizations are completed the developer will test the customization before submitting it for testing by the functional users. Functional users will conduct a unit test of the customization and sign-off their acceptance before it is moved to production.
As the implementation of the project progresses so will the nature of testing. After each module has been thoroughly unit tested, integration testing begins. As integration testing proceeds, more end-user participation is needed. If not already prepared, test case scripts will be prepared for the test scenarios that are to be used. A section outlining expected results is also included in the scripts. It is in integration testing that testing starts to take on more of a structured approach. It is recommended that there be one control point responsible for tracking the test scripts and the documented results of the test. Any test scripts in which there are errors will be tracked and given to the appropriate person to resolve. After the error has been resolved, it will be re-tested by the same individual who originally uncovered the error.
The next step in the testing cycle is to carry out system testing. Unexpected results will be analyzed, resolved, and re-tested.
Each module project team will develop detailed test plans and acceptance criteria. These plans will be integrated and coordinated for the testing of inter-module processes. Included in the planning will be the identification of one or more Testing Coordinators within a module team.
Training
In order to gain the greatest return on investment from the new PeopleSoft system, it is important to provide all users with training on how the system functions and how they will use the system to perform their daily tasks. Project Team members must become experts in the operation of the software and key process owners - end users must become self-sufficient in its use. Managers and executives should have minimum enough knowledge of the system to understand its capabilities and its requirements for operations and on-going maintenance.
Training for Project Team members should not be restricted to the formal sessions outlined below, but naturally occurs as a result of active participation in the implementation effort. Our experience showed that participation in setup activities, testing case development and testing was the best learning preparation for business process owners. Timely and active involvement in both formal and informal experiences will best position us not only for a successful (cost effective implementation), but will allow for effective ongoing post production support without the continuing cost of consultants.
The training strategy is composed of the following components.
Project Team Training
University employees directly involved with the implementation project activities, both functional and technical, will attend the standard PeopleSoft application and technical training applicable to their specific application module(s). This training is conducted by certified PeopleSoft instructors and can be held at PeopleSoft training facilities, at the Service Center, at another hosting university, or brought on-site. Most recently we have the ability to obtain this training through CD’s.
The initial training focus will be to attend critical classes during the initial design stages of the project. These classes will primarily cover the basic functionality and setup of the software. These should be taken prior to the project start but in close proximity to the actual design activities. Less critical or advanced courses can be taken as needed, or as time permits later in the project.
The course recommendations are in Appendix E.
End User Training
The University of Houston will define the detailed training plan for the deployment phase of the project. Using role analysis, the team will define key training groups within the organization. Members of each group will require the same functionality and level of expertise with the system. For each training group, agendas, training material requirements, and delivery methods will be defined. Included in this training plan will be the identification of ‘pre-requisite’ training needs, such as Word or Excel and the PeopleSoft Navigation Tutorial available on-line via Customer Connection. The functional implementation teams will work together to develop end user documentation and training materials. These materials will encompass PeopleSoft functionality and University of Houston business processes. Prepared test scripts can be a useful outline for training materials and documentation preparation.
Where larger groups must be trained, consideration must be given to training facilities at each campus. Individual training classes should be accompany 12-16 attendees. This will require a training room, equipped with access to the PeopleSoft applications and appropriate Internet connections and audio-visual equipment.
A “Train the Trainer” approach
will be utilized as much as possible, training key resources that will in turn
train the end user groups. This entails
utilizing trained employees to work with University of Houston employees to
train them in focused parts of the functionality of the new system. This will be done by application area. This type of training will be used prior to
individuals becoming involved in the testing cycle of the project or as
individuals are preparing to use the new system as the project is nearing
completion. The timing of the training
should be such that these individuals can be effective in the testing
activities throughout the project, but not trained too early as they lose their
knowledge gained throughout the training classes. It is expected to use trainers from the functional development
team, although they may also be active with testing and implementation effort
activities. This conflict always present a risk.
There are a number of benefits to this end-users training strategy:
· UH process owners, as trainers, understand the system more thoroughly.
· Training is campus specific and related to each Universities’ business practices.
· Department participation contributes to ‘ownership’ and ‘buy-in’ of the new system.
· UH functional process owners’ staff will be better equipped to conduct on-going support and future training for new hires throughout the life of the system.
Change Management
Change Management generally refers to topic of preparing the organization and its constituencies for the upcoming changes. There is another project consideration control of the changes within the project schedules and tasks – typically named as Change Control. Issues dealing with Change Control are described in this document under the topics of Change Control within the area of Project management Controls.
Change Management should be championed by a senior executive, familiar and trusted by the university but not directly responsible for the deliver of the project implementation activities. Topics to be considered under change management include the following.
- Helping the university to understand the reasons, the process and benefits of the upcoming change
- Advocating for training and preparing people for change
- Assisting to identify organizational change required or resulting from the S&AA project
- Assisting the organization to identify the new processes
- Communicating the status of the project and listening to the feedback
The change management specialist should advise the Student Leadership on issues relating to preparing the organization to accept this project. He should act as an informal relationship of counselor and advisor between the project organization and the university organization.
Decision Process
During the project many decisions will be required. Difficult decisions will be faced to evaluate considerations such as service levels versus system modifications, change in processes versus changes in the system, one common process versus four unique processes and the like. In all cases this decision making process will be used to evaluate the alternative instead of presuming one standard approach or response to each situation.
The Vice Chancellor for Student
Affairs will resolve functional issues with the Student & Academic
Administration system, and the Vice Chancellor for Information Technology will
resolve issues regarding technology.
The following are the members of
each group and their responsibilities in the decision-making process.
|
Advisory Council: |
|||
|
Chuck Shomper, CHAIR Chaney Anderson Wayne Beran Michelle Dotter Randy J. Harris Jim Hayes Elwyn Lee Jim McShan Ed Sheridan Don Smith Art Vailas Molly Woods Arun Jain (ex officio) Bob Shortle (ex
officio) |
·
Project vision ·
Status review ·
Resource review ·
Budget Funding ·
Scope change review |
||
|
Student & Academic Leadership Group |
|||
|
Steering Committee Elwyn
Lee, CHAIR Ed
Apodaca Elaine
Charlson Glen
Houston Arun
Jain Chaney
Anderson Richard
Phillips Bob
Shortle Leadership
Members Darella
Banks, Co-Chair Steve
Webb, Co–Chair Ed
Apodaca, Campus Chair Liz
Branch, Campus Chair Penny
Cureton, Campus Chair Rose
Sklar, Campus Chair Raymond
Bartlett Darelene
Biggers Andrea
Bermudez Pat
Cavanaugh Ian
Evans George
Hampton Mario
Lucchesi Brian
McKinney Carl
Webster UHD
Dean of Student Affairs (to be named) |
·
Business process approval ·
Policy approval ·
Resource approval ·
Budget approval ·
Project Scope change
approval ·
Business process design
& recommendation ·
Policy design &
recommendation ·
Resource design &
recommendation ·
Budget design &
recommendation ·
Scope change design &
recommendation |
||
|
Module Teams |
|
||
|
Team Facilitator: Multiple UH Admissions Lead:
Multiple UHCL Admissions Lead:
Multiple UHD Admissions Lead:
Multiple UHV Admissions Lead:
Multiple |
·
Setup Table design and
proposal ·
Business process issue
identification ·
Scope change issue
identification |
|
|
|
Technical Team |
|
||
|
Team Facilitator: Steve Webb Data base Lead: Grace
Davila Network Lead: Charles
Chambers Hardware & operating systems Lead: Fran Beach Programming Lead:
Steve Webb Upgrade Analyst: Lupe Sosa |
·
Hardware & operating
systems design proposal ·
Database design and
proposal ·
Network design and proposal ·
Programming design and
proposal ·
Scope change issue
identification |
|
|
Decision
Making Process Priorities
UHS has established the following
guidelines for project decision making process.
Critical issues are defined as those that affect completion of current tasks. Any delay in resolving these issues will result in a delay to the project.
Important issues are defined as those that affect completion of future project tasks. Immediate resolution is not required to keep the project on time, but a delay in decision making could result in these issues becoming critical as time passes.
Low priority issues are defined as those that do not directly impact completion of project tasks. Business process decisions often affect the efficiency of operations after implementation, but are not required to complete implementation tasks.
To expedite the project, decisions will be made within the following timeframes:
·
Critical decisions: weekly
· Important decisions: bi-weekly
· Low Priority decisions: monthly
If resolution cannot be reached within the timing guidelines, issues are escalated to the next level decision making authority in the decision making structure. Critical decisions that are not made on schedule are automatically submitted to the scope change process, to document the cost of the resulting delay in project tasks.
Project Scope Control
The Scope Control process encompasses any alterations to the tasks, resources, schedule or quality of deliverables for a project. Notification of intended changes must be communicated in writing to the project members, and include justification and analysis of the impact on the project.
Some changes are imposed on the project as a result of external events beyond the control of the team. These include turnover of team members, imposition of new requirements by an external regulatory body, etc. Each of these changes must be evaluated for its impact on the project, and agreement reached on the approach to address the change. Changes that are ‘optional’ (generally system modifications or other changes to scope) will be scrutinized for alternatives and subject to an approval step.
Scope Control will include effective tracking, monitoring and control over changes by:
- Establishing a central point of control and decision making process.
- Minimizing any changes, even those that are easy to make (and that can cause a project to go out of control if too many are proposed). This step includes identification and analysis of alternatives.
- Establishing a Scope Control process for each proposed change and requiring a business case be documented and approved by the Student and Academic Leadership Group – Executive Committee.
Any proposed modifications to the PeopleSoft system are subject to the Scope Control process. Items approved during this process are subject to system change control, which specifies naming conventions and tracks migration of modifications to PeopleSoft-delivered objects.
Scope Control includes changes to the universe of tasks that was agreed to in the Project Charter, and to the project plan approved at the conclusion of the Fit/Gap process. Tasks identified in the plan for which new requirements surface (resulting in increased estimates of effort) are also subject to the scope control process.
Examples of events/circumstances that invoke the scope control process:
· Someone requesting a system modification
· Handling an Issue requiring a change
· Identification of an action to address a Risk
· New software release
· Changes in business requirements
· Team member turnover
· Decision to change the content or format (and therefore the quality) of training documentation
Key Elements:
· Establishment of project baseline, variation from which triggers the scope control process
· Documentation and analysis of proposed changes, including alternatives
· Formal approval process
· Structured tracking of proposed changes
For details on the production change control management process see http://www.uh.edu/fast/changemanagement.htm.
Issues Management
Issues are events requiring a decision or other actions to avoid negative impact on a project. The event excludes changes in system functionality, systems problems or scope changes. Most issues result from a project’s requirement for change in a company’s culture, business practice or procedures. It is expected that Risk Management should anticipate many such events but avoidance of all issues is impossible. Issues arise throughout the project and must be addressed expeditiously. Some issues require research or additional information; others can be dispatched immediately. All project issues must be assigned and tracked until resolved.
An efficient issue resolution process is pivotal in minimizing impact on forward progress of a project. The key to issue handling is the way in which an issue is defined and who is the best representative for a quick resolution. First, an issue must be properly identified, timely logged in a central project file and assigned to the appropriate resource. Once logged and assigned, the project manager must ensure that progress is being made. The current status is tracked and reported to the project sponsors and stakeholders on a bi-weekly basis.
Success Factors
It is important to
identify and define potential issues expeditiously to ensure project activities
are not immediately affected. Involving
the process owners of affected business areas in the solution process usually
concludes in amiable results. Project
team members working along with process owners in issue resolution is paramount
to achieving a well thought out solution. Careful consideration should also be
given to the following:
·
Communicate
issue handling process to entire project team
·
Central issue
repository with access by all project team members
·
Conducting
team discussion sessions to properly identify an issue
·
Timely
reporting of issue status to all affected
·
Assignment of
a specific resource to Lead
resolution process
·
Prioritizing
issues according to urgency and impact on project
·
Following a
defined escalation process for high level issues resolution
Procedures
The following
Issues Management procedures will be followed throughout the project:
1.
Track Project
Issue
At minimum the following information is required on
the issue report:
·
Name of the
person reporting the issue
·
Date issue was
identified
·
Nature of the
issue
·
Issue identifying
number
·Consequences and timeframe of consequences if issue is not resolved
(high, medium, low)
2.
Assign
Responsibility for Each Issue
The Application Lead will
identify and publish an owner for each issue (i.e. someone given the responsibility
to ensure the issue is closed in an appropriate manner). The Application Lead will set target dates for closure and interim status
reporting.
Add the following to the Issue report:
·
Name of the
issue’s owner
·
Target Date
for issue closure
·
Interim
Date(s) for reporting status
3.
Determine
Issue Resolution
The Application Lead will document the recommended
resolution to the issue and any alternatives that are considered.
Add the following to the Issue report:
·
Resolution
required to solve issue
·
Impact of
implementing resolution
4.
Escalate
Unresolved Issues:
The application Lead will
raise awareness of unresolved issues to the stakeholders and sponsors as soon
as possible to minimize the negative project impacts.
·
Suggest resolution
strategies and identify where their support is needed.
·
Follow through
on the direction given by the stakeholders and sponsors.
The Application Lead will
approve the resolution actions recommended and obtain Student and Academic Leadership approval if those actions
impact the scope, schedule, cost or quality of the project.
Add the following to the Issue Report:
·
Final
disposition of issue
·
Who is
responsible for carrying out resolution
·
Client
approval, if required
·
Close out date
5.
Publish Issue Reports
The Application Lead will
maintain a log of all issues.
The issues log will be visible to all team members.
The project manager will ensure the currency of the log and the status
of each issue.
On schedule, agreed during the Project Planning-Refine Approach and
Project Plan process, publish the issues log.
Note all significant changes made since the last distribution.
At minimum the
issue log will have the following information:
·
Issue
identifying number
·
Date issue
identified
·
Brief description
·
Who was
assigned the research
·
Final
disposition
·
Close out date
The Application Lead will
ensure that a complete history of all issues - their occurrence and their
resolution- is retained.
The Application Lead will
notify Student and Academic Leadership
in writing within five days about new issues that may cause a significant
change in project scope, schedule, cost, or quality.
System issues (e.g. testing issues) tracking
·
A process will
be put in place to recognize and handle error messages.
·
A log will be
established for tracking errors.
·
A central
control point will be created for receiving and distributing errors and error
messages.
Change Control
University of Houston System has committed to an implementation in which all business areas are expected to work within the delivered functionality of PeopleSoft, whenever possible. This commitment takes advantage of the efficiencies built into the PeopleSoft functionality while minimizing required modifications to the software.
In minimizing modifications, changes will inevitably be required to the policies and/or procedures of the University of Houston System or one or more of its components. To ensure that the necessary decisions are made to support these changes and continue the timely forward progress of the project, a strong change control process is required.
Requests for change may arise from a number of sources, including the Issue Management and Modification Management processes. The Change Control system described below is intended to possess at least the following characteristics:
Multi-level escalation process
Managed decision paths
Clear decision support responsibilities
Multi-level Escalations:
The items entering this model are expected to number at least in the hundreds. Most of these decisions will not require escalation to the highest level of the model. At the very least, the model supports three levels of decision responsibility.
The Executive Advisory Committee: The Executive Advisory Committee will be the highest and final level of decision responsibility. Only a small subset of items should reach this level of escalation, those that have the full backing of the SALG. The SALG should have attempted resolution on their own and been unsuccessful in that attempt. The pros and cons of all political, financial and schedule perspectives should be well documented by this point in the decision process.
The Student & Academic Leadership Group: Those items that cannot be resolved at the application level will be presented to the SALG to gain support and organizational perspective prior to escalation to the Executive Advisory Committee. This group will undertake the effort to negotiate a decision for those issues they feel merit such attention. They also have the responsibility for recommending a halt to efforts expended on items they do not feel should be pursued.
Student & Academic Administration Teams: To the extent that the Teams can properly assess the procedural, financial, political and legal ramifications of making a desired change to existing procedures, schedules, or operations, they should be empowered to do so. This of course assumes that they can achieve the concurrence of all faculty and administrative departments affected by the change. The Team Facilitators on each team are the key decision makers on the majority of the items that will arise during the project development phases. They can choose to support or terminate any decision requested by a team member. The Team Facilitators will present any items to the SALG that are escalated from the functional project team they support.
Managed Decision Paths:
The course taken by any item entering this change management model should be well managed and articulated. Decisions pursued by the Team Facilitators can be presented to the SALG for ratification and assessment of cross-module impact.
Presentations made to the SALG will be the responsibility of the Team Facilitators working with the Application Lead. All presentations made to the SALG will have to meet the qualitative standards set by the Project Office.
Clear Decision Support Responsibilities:
Decisions presented to the SALG should have justification prepared prior to SALG review. The preparation of the institutional level assessments will be the responsibility of Application Lead. The preparation of the departmental financial and procedural case will be the responsibility of the Team Facilitators.
Deliverable Acceptance
The final steps of the universities’ functional areas taking ‘ownership’ will be the deliverable acceptance process. Deliverable Acceptance can be associated to individual tasks, project milestones, or implementation. Acceptance of individual tasks is more a function of individual ownership and accountability where acceptance of a milestone is more serious in nature. Revisiting tasks after a milestone signoff is likely to cause a change of scope.
Milestone signoffs should require approval by both the functional team members as well as the management officials assigned at this level. This reinforces the ‘ownership’ and ‘accountability’ themes that will be critical in meeting the University of Houston’s project timeframes.
UH also faces challenges in gaining acceptance from periphery communities such as faculty. This is a major responsibility for the Project Director and Student & Academic Leadership Committee. One suggestion made to facilitate this was to use a ‘Federal Register’ approach where a signoff timeframe for input is published; along with requisite support material, and after that, time acceptance is automatic unless an issue is raised in a timely manner.
Should any deliverable acceptance be declined, it will be required for the person rejecting to state specific reasons. This allows for the Project Team to understand and focus on the issues causing the refusal and act on them in a timelier manner.
Quality Assurance
Quality Assurance management is an integral part of every successful project. Planning identifies what quality standards are relevant to the project. These standards are incorporated into all of the other strategies developed for the implementation, such as testing requirements, signoff of deliverable acceptance, and development standards. Adherence to and successful execution of the established procedures for Change Control, Risk Management, Issues Management, Status Reporting, and Communications will also assure quality output.
Quality control also involves monitoring specific project results to determine if they comply with relevant standards, identifying ways to eliminate the causes of unsatisfactory results, and monitoring that milestone dates are being met. An excellent way to monitor project quality is to use a non-project resource to review on a periodic basis, usually quarterly, that the project is complying with established processes and methodologies. Ross Hoskins has participated with FAST project in the past and would be an excellent recommendation to continue. The State Auditor’s Office also performed a review of the FAST Project quality assurance practices and gave it an excellent review. As this project is classified a Project over Threshold by the State, a review is expected.
Specific items the quality review process should evaluate include:
· Completeness and maintenance of the Project Plan.
· The financial performance of the project against budget.
· Effectiveness of the Change Control Process.
· Documentation and timely resolution of project issues and risks.
· Completeness and adherence of documentation and related standards.
· Effectiveness of communications.
Risk Management
Risk
Management identifies potential future events that may have adverse impacts on
the project, the specific nature and magnitude of those impacts, and the
likelihood that the events will occur.
Information gained from the analysis is used to develop contingency
plans for monitoring risk areas, and for dealing with the events. The expectation is that with effective Risk
Management, the risks identified can be managed or avoided altogether.
Risk
Management embraces a series of forward-looking linked activities and
processes, comprised of:
Risk Assessment: Identifying, evaluating and
prioritizing, as early as possible, all potential risks to the project. Risks may be identified at all levels (from
the project Executives on down).
Risk Analysis: Careful evaluation of each
risk identified. Assessing the
likelihood of each risk occurring and the impact to the project, should the
risk occur.
Risk Containment: Agreement on an action plan
to minimize the likelihood of each risk.
Actions should include avoiding, containing, and monitoring the
risk. Where necessary, these plans should
specify those contingency actions required should the event driving the risk
occur.
Risk Control: Regular maintenance of risk
action plans, risk reassessment, risk resolution, a process for the assessment
to new risks, risk reporting and review.
The
preferred approach is for all members of the project team to openly identify
and manage risk. This means that the
team members are happy to share identified risks for the greater good of the
project. The SALG and the Project
Director are, however, ultimately accountable for the effectiveness of project
risk management.
The
opportunity for risk management presents itself across a project’s life cycle,
from funding, resourcing and start-up to contract negotiation with suppliers
and business partners, and to testing and implementation. The following chart shows the project life
cycle with trigger points for risk activity.
|
Life Cycle Stage |
Activity |
|
Planning |
Risk
assessment |
|
Start
the Project |
Establish
risk control process |
|
Manage
the Project |
Risk
assessment Risk
re-assessment Risk
analysis Risk
containment Risk
tracking and reporting |
|
Close
the Project |
Lessons
learned |
Although
risks can occur throughout a project’s life, they generally attract the most attention
during project identification, endorsement, and definition. It is a lamentable fact that, after these
activities, risks are often given scant attention, even during important work
stages. A reason for this is partly
cultural (risk management has not been seen to be as important as issue
management) and partly process (a risk control process has not been established
at project outset). Projects often fail
to carry forward the risks identified at feasibility and definition stages into
an ongoing risk management plan.
Risk
management is, after all, a continuing process, and not something that is
undertaken just at the early stages of a project. As far as culture is concerned, if risks are managed on a par
with other key project exceptions, such as issues, changes and modifications,
then the habit of looking forward, which risk management provides, should
reduce the chances of impact from major issues.
Risk Management Process
The
FAST Project Office will define and implement the Risk Management System and
guidelines to be followed on this project.
For
the management of risk, the master vehicle is the Risk Control Form. A copy of the suggested form follows.
Risk Control Form
Once
a risk has been identified it can be evaluated; that is, why is it a risk and
how much of a risk is it? Relevant
factors are:
·
Precedence
(has the risk occurred before?)
·
Familiarity
of operation (has the work been undertaken before?)
·
Skills
(the ability of staff to carry out the work)
·
Resources
(adequate materials to carry out the work)
·
Time
(adequate time to complete the work)
·
Quality
(confidence about the quality of work required)
·
Cost
(sufficient funding to carry out the work)
·
Probability
(the likelihood of the risk occurring)
·
Impact
(the affect on the project or business of the risk occurring, in terms of
delay, cost, quality, specification, performance, etc.)
Some
of these criteria are also risk drivers, and may be considered during risk
identification. It is recommended that
the impact and probability of a risk be established as the minimum criteria to
employ. Probability is the percentage
likelihood of occurrence, whereas impact is an expression of severity through,
mainly, cost of damage or delay.
This
evaluation is important since it records why a risk was assessed as it
was. When a risk is revisited, some
time later, the evaluation criteria of the original assessment may have changed
in perspective causing a new assessment.
True
prioritization of identified risks can only take place after qualitative or
quantitative analysis. In practice,
however, it is often necessary to take an initial prioritization in order to
cut down the number of risks identified and, therefore, the amount of work
required in subsequent analysis. In
performing this initial prioritization, the possibility of losing a key risk
will be very low since the project team will have some idea of the importance
of the identified risk without undertaking formal analysis. Analysis will confirm the importance of the
risk and provide data for their ongoing management and control.
Following evaluation and initial prioritization, the identified risks should be qualified to the required degree using qualitative analysis. Qualitative analysis may or may not be extended to quantitative analysis, as required.
Each risk may be qualified according to the degree and complexity necessary for the project. Even if a decision has been made for the project not to adopt a quantitative approach, it is recommended that a numerical basis be used as the foundation for rating. A three-category qualitative system is in current widespread use within the IT industry (HIGH, MEDIUM, LOW). This may well be sufficient for a very small and contained piece of development work, but for a medium to large project, it is recommended that at least a five-category percentage approach be used (1-20%, 21-40%, 41-60%, 61-80%, 81-100%). Impact and probability can, therefore, be qualified for each risk according to these percentages. For discussion purposes, each percentage category may be given a descriptive tag, but care should be taken not to become locked into words rather than more statistically useful numbers.
Risk Containment
This
is the assignment of actions to contain or reduce the risks evaluated. Containment may be undertaken prior to
detailed risk analysis, but once started, it becomes an important ongoing risk
management activity. Containment should
be undertaken as soon as possible after risk evaluation, and comprises, for
each risk:
·
An
action statement
·
A
person responsible for carrying out the action
·
An
action-by date
·
An
estimated cost/consequence of the impact (where appropriate)
The forms for tracking these risks and assigned action steps, the Project Risk Log and Action Control Log follows, and shall be maintained by the Project Office. Some risks will have several actions associated with them, and some of the actions may need to contain contingency plans. Contingency plans will be required for risks of significant impact or for risks deemed to have 100% impact and 100% probability (that is, certain to take place). Often, such risks require actions more appropriate to issues.
Action Control Log
|
|
Project Risk Log
|
|
Project Communications
The overall goal for the FAST Project’s communications are to clarify, for various audiences, the expectations, objectives, implementation plans, progress, and training plans for the project, and to ensure that the project leadership and workgroups are receiving adequate information from the University of Houston in return. A dedicated communication leader is planned for supporting communications. A communications detail plan will need to be developed to consider all needed communications parties, methods for communications, and timings for communications. These are called the ‘Three F’s of Communications’; Factions, Format and Frequency. The communication Target is shown below:
Three
F’s of Communications
Factions
Format
Frequency
The Project Charter outlines a framework for a communications plan. The Project Director and the Communications Lead should attempt to standardize of a few common report formats and minimal sources of information when communicating project status.
Project Team
Project Team status meetings are expected weekly, by module, conducted by the Project Team Facilitator. Team member statuses be collected and reported through Microsoft’s Project. This would greatly facilitate the Application Lead in the dissemination of project tasks and results.
The Project Team will rely on both formal and informal communications. The latter will be especially enhanced by the approach of locating the project work in a single location. As best that it can accommodate, UHV will be facilitated by tele-video connections. The primary form of communications will be e-mail, with formal meetings as needed.
The Project Director will need to establish standards for document formats such as placing the path and filename on every document. Also, a common file repository for project documents will need to be established.
University Community
The communications to the communities will require multiple formats and approaches. The approaches should include web pages, e-mails, newsletters and telephone conference calls. A regular schedule for project status should be established.
Status Reporting
Reporting of the status of the project is an effective communication tool. However, status reporting can also become a significant and time-consuming activity. One objective of the project will be to provide project status reporting though automated means using the Microsoft Project tool.
The Application Lead will distribute project tasks and receive task status for the Project tools. This would mitigate the need for a separate written report from each team member.
Management status reporting will have a summary of the project reporting and will also address concerns, issues, problems that have been encountered and action required. The Project director will also provide routine status reports to various groups, as mentioned in the Project Communication section of this document.