HR Front End Time Line 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 Version 4.0 of ECOS included the first production use of OpenEAI messaging for some data elements. The final day that ECOS was used was December 23, 2003. The Electronic Change of Status (ECOS) application was a client/server application that replaced a paper-only process that centered on the multipart “Change of Status Form.” Version 1.0 of ECOS was released in early 1996. Version 2.0 primarily consist- ed of usability and bug-fixes, and was released late in 1996. Version 3.0 of ECOS consisted of several major enhancements that were originally out of scope. It was released in 1999. January 2004 – Banner HR Pay goes live. June 2004 – Due to the complex nature of issues that contribute to the increased end-to-end processing time, it was decided by HR/Pay Leadership to embark on a formal initiative to objectively identify problems and potential solutions. A formal HR/Pay Transaction Processing Improvement Initiative was launched, six months post imple- mentation Banner HR/Pay. This was the conception of the HRFE project. February 22, 2009 – HRFE goes live Pre-Design and Information Gathering 2004 2005 2006 2007 2008 2009 Development of Functional Specification Traditional Design and Development Cycles Quality Assurance Module Development Module Design User Community: 39 sessions Online Survey: 213 participants Joint Campus Advisory Group: 1 session Joint Application Development (JAD): 7 sessions Breakout: 5 sessions Business Team: 17 sessions Prototype Focus Group: 9 sessions – 98 participants Total Participants: Over 350 16 Functional Modules 75 Users in Functional Teams 15 Developers 5 QA Testers 22 Core Team Members Users determine that not all of the requirements have been identified. New business rules delivered. Testing has been done on a module by module basis. Users start to test with combinations of modules. UAT 1 leads to a UAT 2. System is working! A reflective look at the amount of functionality HRFE provides and improvements made after UAT 1 set stage for UAT 2 and implementation commitment. Epiphanies User Test Session Design Develop CA 9 User Test Cycles Quality Assurance Module Development Module Design Quality Assurance Module Development Module Design Testing and Deployment User Acceptance Testing #1 User Acceptance Testing #2 Development Training GO LIVE 1 2 3 1 2 3 Iterative Development and Test Cycles ECOS Client Circa 1999 HRFE Client 2009 Building Really Big Homegrown Enterprise Software from Scratch
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
HR Front End Time Line1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009
Version 4.0 of ECOS included the first production use of OpenEAI messaging for some data elements. The final day that ECOS was used was December 23, 2003.
The Electronic Change of Status (ECOS) application was a client/server application that replaced a paper-only process that centered on the multipart “Change of Status Form.” Version 1.0 of ECOS was released in early 1996. Version 2.0 primarily consist-ed of usability and bug-fixes, and was released late in 1996.
Version 3.0 of ECOS consisted of several major enhancements that were originally out of scope. It was released in 1999.
January 2004 – Banner HR Pay goes live.June 2004 – Due to the complex nature of issues that contribute to the increased end-to-end processing time, it was decided by HR/Pay Leadership to embark on a formal initiative to objectively identify problems and potential solutions. A formal HR/Pay Transaction Processing Improvement Initiative was launched, six months post imple-mentation Banner HR/Pay. This was the conception of the HRFE project.
February 22, 2009 – HRFE goes live
Pre-Design and Information Gathering
2004 2005 2006 2007 2008 2009Development of
Functional SpecificationTraditional Design and Development Cycles
QualityAssurance
Module Development
Module Design
User Community: 39 sessionsOnline Survey: 213 participantsJoint Campus Advisory Group: 1 sessionJoint Application Development (JAD): 7 sessionsBreakout: 5 sessionsBusiness Team: 17 sessionsPrototype Focus Group: 9 sessions – 98 participants Total Participants: Over 350
16 Functional Modules75 Users in Functional Teams15 Developers5 QA Testers22 Core Team MembersUsers determine that not all of the
requirements have been identified. New business rules delivered.
Testing has been done on a module by module basis. Users start to test with combinations of modules. UAT 1 leads to a UAT 2.
System is working! A reflective look at the amount of functionality HRFE provides and improvements made after UAT 1 set stage for UAT 2 and implementation commitment.
Epiphanies
User Test Session
Design
Develop
CA 9 User Test Cycles
QualityAssurance
Module Development
Module Design
QualityAssurance
Module Development
Module Design
Testing and Deployment
User Acceptance Testing #1
User Acceptance Testing #2
Development
Training
GOLIVE
1 2 3
1
2
3Iterative Development and Test Cycles
ECOS Client Circa 1999 HRFE Client 2009
Building Really Big Homegrown Enterprise Software from Scratch
Key Implementation Strategies“The Magic 162” – Have defined units of scope that help identify and divide the work initially and then refocus in on the most critical functions of the system. This was done by first defining the system in terms of “modules” then working within these module areas to refine application functionality. Finally the 162 key scenarios were identified which provided a story of how the modules work together as well as a measuring point as to whether the product was working or not.
Management commitment. Strong commitment from top management to see this project to completion. The drain on resources (developers, analysts, trainers, end users) for this project was substantial.
Flexible and iterative development methodology. The testing cycles and user involvement needed was absolutely critical for defining all of the requirements and keeping the users close to the product throughout the project.
A single source of truth. Have a central repository for tracking changes, defects, and issues. It served as the system of record for requirements in many ways and provided metrics to track progress and how far we still have to go.
Maintain fallback positions. Flexibility and other options were needed to adjust dates, change scope, and provide a safety net for users to feel comfortable in accepting the product along the way and allowing them to move forward.
UIUC Offices:• Applied Health Sciences • Law• Beckman Institute • Library• Civil & Environmental Eng • Medicine• College of Business • Music• Communications Administration • Provost & VC Academic Affairs• Computer Science • Psychology• Division of Campus Recreation • School of Literature, Cultures, Linguistic• Education • School of Chemical Sciences• Engineering • School of Integrative Biology• Facilities & Services • School of Molecular & Cell Bio• Graduate School • Staff Human Resources• Housing Division • Student Financial Aid• Intercollegiate Athletics • Supercomputing Applications• Labor & Industrial Relations • Veterinary Medicine• Liberal Arts and Sciences • Vice Chancellor for Research
IC Offices:• Academic Computing & Comm. Center • Library • Applied Health Sciences • Medicine• Architecture & Art • Medicine - Peoria• Business Administration • Medicine - Rockford• Campus Recreation • Office for Access and Equity• Career Services • Pharmacy• Center for Adv Dist Education Pub Health • Physical Plant• Dentistry • Public Health• Education • Social Work• Engineering • UIC Human Resources• Graduate Medical Education • UIC Medical Center• Institute for Health Research & Policy • University Police• Intercollegiate Athletics • Vice Chancellor for Research• International Services • Vice Provost for Faculty Affairs• Liberal Arts and Sciences
Departments, Units, and Colleges Involved in User Design and Testing SessionsUIS Offices:• Provost and Faculty Affairs• Public Affairs• UIS Human Resources
HR Front End ProjectBuilding Really Big Homegrown Enterprise Software from Scratch
User Testing Session
Project Team Structure
Project Tracking Report
Feature Comparison ECOS, Banner, and HRFESystem Legacy