BUSINESS SERVICES COMPUTING

Interoffice Memo

TO: Mike Szczepanski

FROM: Tammy Murray
DATE: May23rd, 2003
SUBJECT: HRIS Post Implementation Review

Joan Vaughan conducted the Human Resource Information System (HRIS) Post
Implementation review on April 28th, 2003. Those in attendance were Rick Miller, Liz
Rulli, Jim Skiles, Kirk Tolliver, Harry Smith, Kevin Gillenwater, Greg McKinney, Mike
Schulte, Cheryl Gray, Peg Jasper, Susan Davis, Donna Muir, Sheryl Gick.

Overview of the Project

The purpose of the project was to successfully implement a Human Resource system. The
HRIS project began with vendor selection in 1996. In November 2002, Jeff Whitten and
Jim Almond decided to discontinue the project.

Purpose of the Meeting

The post implementation review was arranged to discuss what went well and what can be
improved. Consensus was not obtained on any items mentioned and the comments
documented do not necessarily reflect the group as a whole. While HRIS application wasn’t
implemented, a review was held because there are many lessons that can be learned from
the process.

Major areas of success:

 There were many knowledgeable business and technical staff on the project.

 Staff gained knowledge of HR system, processes, and learned new software tools.

 Modules such as Compensation Distribution (CD - payroll charge replacement) and

Time and Attendance (TAD) were well designed, developed and tested.

 Client quality assurance testing strategy was designed and implemented

 HRIS Post Implementation Review

Major areas where improvement is needed:

 As the scope of the project changed, neither the project timeline or project resources
were adjusted.

 Interface work had to start before development of the On-Line Transaction Process
(OLTP) was complete.

 Not enough time was allowed at the end of the project for adequate testing and
training.

 Project experienced schedule compression at the end by trying to meet a fixed

deadline.

 The functionality to be delivered in the product didn’t meet the original specified
requirements.
Business processes should be reviewed to determine how they could be changed
instead of modify the application.

 Decision-making authority was not delegated to the lowest possible level to facilitate
quick decisions.

 Project should have been broken into smaller pieces. Too many pieces have to come
together at just the right time for it to work.

What Worked Well

Requirements Definition/Scope

 For the first time in a long time we were able to put into writing what our systems
need to get the job done.
 Features of check printing, TAD went well.
 Documentation was organized and consistent at the launch of the project.
 Large group requirements gathering sessions (i.e. TAD) with many areas
represented.
 Requirements for Time and Attendance, check printing, Flex replacement were well
prepared.

Design

 Creative designs to get the job done with what we had.

 A greater number of people now understand the complexity of HR and Payroll.
 Documentation of key processes.
 Meeting with clients, Business Analysts, and project staff to generate overview of a
module before specs written (TAD, staffing) as opposed to developing individual
screens (Foundation).
 Following InPower design was good.

Page 3 of 14
 HRIS Post Implementation Review

 Redesign of database.

Development

 New technical skills were developed (i.e. Developer 2000, PLSQL, Unix Script, Auto
Sys).
 Account Profile Management System (APMS) went well because it was a small
project and each of the three people involved had expertise in their area of
contribution.
 Initial simulation (Prototype) pre-Aug 1998 went well. Was key to team learning
application.
 Standards that were put in place after Oleg Fedoror and Kevin Gillenwater
(analyst/programmer) arrived were very beneficial.
 Clients appreciated collaboration on Flexible Spending Account (FSA) module.
Issues that would impact other segments seemed to be uncovered in this work and
provided a means to illustrate and start problem solving.
 Dedicated staff.

Test

 Testing process implemented by Julie Graham worked well (with exception of

business process documentation – business process, testing and training materials
were going on at same time and shouldn’t have). Data load processes were well
tested and repeatable. The test group put together a great process for identifying all
the parts to doing a thorough test.
 Conversion and batch testing went well. Automated testing with Quality Assurance
(QA) Run and QA Director went well once we got beyond the initial learning curve.
 Business Analysts on the project team did a good job of testing the system at various
points in the development environment prior to production.
 Structured set of business scenarios and very detailed scripts to provided
consistency to user acceptance testing.
 TAD testing in ENAD was effective.

Implementation

 The roll out of a particular release of the Total Compensation (TC) system was both
controlled and timely.
 Hosted ‘workshops’ for central office staff. This allowed them to touch software and
become familiar. It allowed them to understand impact of needed business changes.
 Release strategy in 2002. – Broke project into pieces by focusing on project team
and schedule.

Page 4 of 14
 HRIS Post Implementation Review

Communication

 Communication within the project team and with the end users worked well and
kept pace with new needs as the TC system grew.
 Liz Rulli provided extremely good communication to the business representatives
and Process Implementation (PI) Team rep.
 Showcases were well attended and generally viewed as helpful. Helped build an
understanding of key concepts and demonstrate software and processes.
 Monthly newsletters potential system users were well received.
 With regards to interface work, we were told what was going on and asked for
feedback. Monthly meetings worked well (i.e. Interface Contacts).
 For the development team, regular meetings helped keep the development staff
abreast of timeline, developments, expectations, etc.
 Refined and improved Change Management. This is a process to notify the various
areas when changes to infrastructure needed to be put into place.

System Features (Product)

 The system had most of the features we need. It also had many features we never
could have used.
 Key on number other than SSN was attractive.
 Once we began to understand it, the compensation plans were flexible and a very
powerful way to run HR plans.
 One integrated Payroll/HR system.
 Good design and database.
 Web-based product.
 System design was tailored for Purdue’s business practices.

Training

 The Business Office Training Manual was developing into a good document.
 Hands-on sessions that included detailed materials and practice
examples/exercises.
 Resources were made available whenever we requested.

Other

 Contributions of the Business Analysts were outstanding

 Equipment acquisition and set-up.
 Product selection process was customer driven.
 The last year was extremely productive: Compensation Distribution, Time Entry,
FSA claims, check printing, staffing, client testing, parallel testing, data conversion.

Page 5 of 14
 HRIS Post Implementation Review

 Project team was dedicated to seeing a successful implementation.

Page 6 of 14
 HRIS Post Implementation Review
NOTE: SC = Steering Committee, PD = Project Director, PM –
What Can We Do Better Next Time? Project Manager, BA = Business Analysts, S = Stakeholders

Issue Solution Who Category

Need to manage scope better
 What was in original project documents and what was
eventually going to be delivered was very different.
 As changes to scope were made (i.e. PUID, e-forms),
project timeline wasn’t extended nor were additional
resources made available.
 As delays in schedule occurred (i.e. Flex more
complicated than) no schedule relief was made.
 Too much emphasis on Payroll at the expense of HR
component.
Current projects and their relationship to other projects need
to be better managed.
 The complexity added to both the Ariba procurement
implementation/upgrade and the HRIS project
through the HR e-forms was not fully understood for
some time. Linking the HRIS project to Ariba added a
layer of complexity that could have been avoided.
 Using Ariba for pre-employment was a big mistake –
had to redo work – no schedule relief.
 Wasted work: Ariba Pre-Employment forms and CD
Self-Sufficiency. Resources could have been better
used on core product.
Fixed implementation dates caused problems.
 Push to meet deadline caused more errors in code.
 Need to get ‘something out there’ sometimes seemed
to overrule good business sense.
 Management’s refusal/denial to believe that the
project was in schedule trouble cost time and waste
and caused delay.
Need to improve decision-making process.
 Decisions were made and then reversed after
development work had already been done.
 Too many competing forces in making design
decisions. Too many people involved.
 Document scope and criteria for determining that a SC/PD All
project is successful. /PM
 Implement process for modifying scope.
 If scope does change, then time or additional resources
should be made available.
 When there are changes to scope, estimates should be
developed on how much that change will “cost”.
 Manage scope creep.
SC/PD Requirements/Sc
/PM ope
 Cost and benefit analysts should be performed. A project
needs to clearly state that scope will be managed thru a
process that identifies whether a change will be paid for
from money or changes to schedule.
 Steering Committee needs to be willing to hear things they
SC/PD Other
may not want to hear and listen to the Project Manager.
/PM
 Communication to Steering Committee needs to include
good news and bad news. Failure to communicate
potential risks or unmet deadlines will only result in false
expectations.
 Determine what decision-making authority team members SC All
have (i.e. what decisions can business analysts make vs.
project directors vs. project managers vs. Steering
Committee).
 Need one person (Project Director) in charge with

Page 7 of 14

Issue
 Too many design decisions by developers, not by
designers.
 Decision-making authority wasn’t delegated to Project
Manager or Business Analysts.
 Steering Committee dealt with too many detail issues.
Tried to bring the entire system up at one time in an all-or-
nothing approach proved to be very complicated and risky.
Work estimates inaccurate (flex, Payroll Charge - PRC).
Business requirements were not complete.
 Disconnect between jobs and positions. Analysis of
legacy HR was inadequate. We often don’t
understand HR business rules outside the context of
legacy systems.
 Didn’t have someone who knew whole system.
Individuals knew specific pieces.
 New business processes were not complete prior to
training. Problems, audits, etc. were pointed out and
Pi Team had to respond ‘that is still in development.
Didn’t change business processes
 We struggled with buying a system designed for de-
centralized distribution of data entry. We didn’t have
routing and approval to actually move to this kind of
business process.
 Didn’t change business processes to meet existing
functionality within application. Needed more
business process mapping/redesign and earlier. No
commitment to change business processes (i.e.
multiple pay periods, direct deposit vs. printing).
 Jobs and positions required a fundamental business
change that hadn’t existed in the business processes
HRIS Post Implementation Review
Solution Who Category
complete authority over time (schedule), money, and staff.
 Need to use common sense approach in decision-making.
 Implement Change Management Board process and
procedures for timely decisions.
 Get decision-making process information from other
schools.
Future implementations of software should utilize phased SC/PD All
approach. /PM
Allow time for estimates to be developed. Don’t apply pressure to PM Requirements/Sc
project team to make estimates fit the time allowed, this will only ope
cause problems in the long run.
 Thorough analysis is needed of all business processes. BA Requirements/Sc
Usage of implementation partners can help with ensuring ope & Training
that requirements aren’t overlooked.
 Need to have a better understanding of what requirements
really are. Are they really requirements or just old
processes that we aren’t willing to change?
 Business processes should be developed prior to training.
 Thorough review of business processes should occur prior SC/PM Requirements/Sc
to any development work and time should be allowed in ope
schedule to do so.
 Need to change culture. Review Gartner’s white paper on
‘Effecting Workforce and Workplace Change’.
 Support is needed from top down to effectively change
business processes.
 When staff/departments agree that they will change their
business to fall in line with the system, they have to know
what they are agreeing to and then they have to be held to
it. Change means, change for me too.
Page 8 of 14
 HRIS Post Implementation Review

Issue Solution Who Category

and systems before. Struggled with understanding

what the business processes should be in new system
versus functionality in new system.
 Not enough political consensus to make meaningful
business process changes.
 Exceptions for processes kill us.
 Data entry was an issue with regards to ‘time to enter’
all data. Making corrections was never fully
investigated, documented, and tested.

Didn’t’ get buy-in from users. What users expected, wasn’t Involve users early and often PD/PM All
delivered. /S
Design work wasn’t coordinated
 Applications should be delivered in releases. PM Design
Development and testing should be separated and not
 Some aspects of design didn’t seem solidified until
going on at the same time.
late. Development and testing were going on at the
same time.  Plan should be developed on how to integrate pieces of an
application when multiple developers are doing
 Silo work resulted in pieces not working together development.
(TAD and Leaves example).
 A design made in one module would limit
functionality in a different module.
Underestimated the amount of time needed for the payroll  Spend more time developing better estimates of tasks.
PM Development
self-sufficiency project (building knowledge of old systems).
 Manage the risk of some projects taking longer and what
impact that has on other tasks.
Changes need to be made to testing plan  Define roles (BA, developer, user etc.) for the testing SC/PM Testing
process. Developers should unit test their programs before
 Calculating on ‘expected result’ was time consuming
turning them over.
and inaccurate.
 Allow for parallel testing
 More developer testing should be done prior to
turning over to testers  Data conversion should be done in old system and done
early to allow better testing. Data conversion forces issues
 Pushing to meet deadlines led to more bugs in code.
to surface.
 Conversion was a serious quality problem.
 Break project into phases to allow testing to be done early
 Testing needs to be considered first – providing
and often
programs to convert old data to provide a valid
comparison.

Page 9 of 14
 HRIS Post Implementation Review

Issue Solution Who Category

 Ariba e-forms tested too far in advance of anticipated
implementation.
 Inadequate disk space for testing full sets of data.
 All resources need to be made available (include
hardware/software) to ensure adequate testing.
 Money should be allocated in the budget to allow for disk
space needed for testing.

Technical training was inadequate (i.e. Oracle tools).

 Technical infrastructure too complex, (i.e. Database,
languages, web servers, tools, servers.)
 Tools, technology and architecture were immature,
unproven in core business (at this university).
Prior to any development work, training needs should be PM / Training
identified and schedule for project. Steering Committee should SC
allow for this to be done in order to not encounter problems in the
end. Computer Based Training (CBT) not adequate for most staff.
Need hands-on structured training with staff who have used the
tools before. This offers opportunity for best practices to be
shared.

Better selection of pilot areas
 We used a regional campus for e-forms. The distance
and lack of understanding their processes were
problematic.
Timing of interfaces
 Because Operational Data Store (ODS) work preceded
OLTP, much of the interface work never actually
started.
Pick pilot areas were team is familiar with business processes. If
PD/SC Implementation
pilot areas are needed where business processes are unfamiliar,
then training should occur to familiarize staff with these processes.
Application should be in a frozen state before interface work is PD/PM Implementation
started. This will ensure that while interfaces are being
constructed, the environment is not changing.

 Making decisions to late in design phase – made

interface work hard, because the system was changing.

Not enough time for implementation

Don’t allow schedule compression to take away from time needed SC/PD Implementation
 Workshops for central office staff started too late.
to effectively implement application. /PM
Participants wanted more time in process to
understand software.

 Implementation should have started earlier

 Time was too short to do training and test.

 Deadlines were unrealistic and, consequently, not

met.

 Implementation criteria changed in Nov; for instance,

Page 10 of 14
 HRIS Post Implementation Review

Issue Solution Who Category

added W-2s.
Knowledge transfer to Continuing Support staff was a struggle
and little progress was made.
Need a more coordinated communication approach on next
project.
 Newsletters and showcases too late in process.
Develop plan early on in project for how information will be
SC/PD Implementation
shared with continuing support staff. Time should also be allowed
/PM
in schedule for the transition of project staff into continuing
support roles after the project is complete.
 At the beginning of the project, identify all stakeholders PD Communication
and the person responsible (single point of contact) for
communicating project information to those stakeholders

 Need better communication between functional areas
(developers, implementation team, regional
campuses, etc.)
 Due to time/resource constraints, it was difficult to
meet with knowledgeable staff and solve problems.
 Involve Internal Audit from inception to post-
implementation review. Internal Audit should provide
guidelines up front and provide periodic reviews.
 Not enough time to communicate better with
departments
Time and resources needed for training were under estimated
 Creating training materials takes 20 hours
development for every hour class time. (If you
thoroughly know your materials and data doesn’t
change)
 The number of classes to be offered was staggering.
 Determine early on what needs to be communicated and
to whom.
 Try to use video conferencing for communicating with
regionals
 Newsletters and showcases should occur early on in a
project
 Need to involve IT people from regionals at a much earlier
stage.
 Provide updates on deadlines and project goals
 Don’t lose touch with what others outside the project don’t
know or understand.
Don’t allow schedule compression to take away from time needed
PM Training
to effectively implement application. Allow more time for
development of training materials, training of staff to provide
training.
Need to determine a way to train staff on systems of this
magnitude.

 Training rooms for hands-on classes were difficult to

obtain.

 Training began too late for anticipated

implementation.

 Trainers lacked knowledge to explain ‘why’ things

happened (i.e. Summer Pay). Hurt their creditability.
Cross training for project staff didn’t occur
During project allow time for technical staff to receive some PM/ Training
business process training and business staff to receive some SC

Page 11 of 14
 HRIS Post Implementation Review

Issue Solution Who Category

technical training.
Need to have a better understanding of how new system Future applications should not be modified to the extent that
SC/PD System
‘thinks and feels’. HRIS was. If packages are purchased and implemented with very
Features/Product
 Understand the architecture for application – system few customizations, implementation partners can help with
required mainframe components (Cobol and 1/Sam learning what a system can and can’t do.
on client/server) and we were implementing on a
client server.
Staffing levels inadequate Benchmark with other institutions on staffing levels they used in
SC/PD Other
 Not enough Business Analysts the project. Funding sources for staffing after project should be
identified early on.
 Business Analysts should not be removed from the
operations they represent.

 Not enough IT and client resources available – no

backfill.

 Project team staffing levels not high enough priority.

Improve management of project team
 Project team not co-located.
 Be prepared to change staff when they lose
accountability.
 Need the best people on the project
 Locate project team staff all in one area
PM/SC Other
 Review project team periodically to determine if staffing
change are needed.
 Avoid vacation restrictions at all cost. While the project may
benefit in the short-term, it hurts morale significantly.

 Provide necessary training for new staff added to project; don’t

 Integrating new players to the team was tough – key just expect them to ‘pick-up things’.
concepts about software weren’t easily transferred.
 Dedicate needed staff to project full-time and allow backfill for
 It was difficult for staff who were devoted part-time to their old positions. Develop plan for how dedicated staff will
project and part-time to operational duties to spend transition into other positions when project is complete.
required time on project work. (Operational duties
always seem to take precedence)

 Lost our consultants at important time – tried to work

new hires in at end.

 Vacation restrictions over the course of a year and no

vacation allowed the last three months of the project
caused staff unhappiness.

Page 12 of 14
 HRIS Post Implementation Review

Issue Solution Who Category

 Not enough continuing support during project.
Resources were stretched too thin.

Schedule didn’t allow adequate time for development of Allow project schedule to be adjusted to allow time needed for
SC/PD Other
training materials, interface work, training tasks to be completed or the following should be done: add
resources or adjust scope.
Too many management (staff) changes in Business Services Turnover cannot be avoided, however this is a risk to schedule and
SC Other
and ITaP. should be managed through the risk assessment and contingency
plan.
Had problems with managing versions of software (utilized Document process for how version control software will be used
PM Other
PVCS software). Same problems would occur in new release as and do periodic reviews to determine if process is working to
before. manage risk.
Never try to ‘rewrite’ a package. There are too many Make commitment to buying applications instead of writing or
SC Other
opportunities for scope creep and less impetus to redesign rewriting software.
business processes.
Consultants delayed things and they lacked leadership. Develop plan for managing the consultant relationship. Within
PM Other
that plan, it should indicate what the roles and expectations are of
the consultants.
Improve organization of development process. Have a more Involve project team in developing project schedule and
PM Other
logical flow to development. Let’s figure out how to get people determining the order of tasks.
assigned to positions before we start trying to extract
person/position and pay information for the ODS. When
neither side of the design is complete, guessing and entering
dummy information is misleading to both sides and keeps
issues from being resolved earlier
Improve management of project tasks.  Project methodology should be adopted and followed
PD/PM Development
 Need closer monitoring of progress or lack there of  Lead developers/business analysts should be utilized to
allow schedule to be updated and monitored.
 Development team was disorganized at times.
Opportunity existed for a lead developer to guide or
oversee the development aspects.

Learn from mistakes; don’t keep making the same ones.  Review post implementation reviews from other projects
SC/PM Other
and determine action plans to avoid repeating problems.

 Develop and follow project methodology to ensure scope is

Level of commitment to the project did not appear to be the
same across areas. This caused problems with development
and testing.
Lack Risk Management or contingency plan
managed and key processes are not overlooked.
Future projects of this magnitude should have support from
SC Other
President on down. Steering Committees should be utilized to
ensure that priorities are consistent across the organization.
Develop Risk Management plan early on in project. Plan should
PD/PM Other
outline potential risks, probability of occurring and ways to
mitigate the risk. Review of the plan should be done throughout

Page 13 of 14
 HRIS Post Implementation Review

Issue Solution Who Category

Didn’t understand gaps of what system would do and what
business “requirements” were.
the project and any new risks identified should be documented.
Gap analysis should be prepared prior to purchasing a product.
PM Other
This ensures that staff are aware of what business processes will
have to be changed or what changes will be have to be made to the
system. For areas in which there are gaps, business processes
should be changed.

Page 14 of 14