Important Background on the Rapid Prototype Case Study

Understand the context for the Rapid Prototype Case Study.

Overview

The Rapid Prototype methodology was used to build and demonstrate a working pension implementation for a new large state teacher retirement plan implementation in less than four months.

The prototype phase began after an initial scoping and preliminary Fit/Gap assessment. The prototyping phase ran concurrently with the development of a detailed implementation project plan and cost estimate. The prototyping concluded before work started on the implementation project plan.

The new plan implementation was to be integrated into an established, highly customized environment currently servicing other state retirement plans. The 90k new plan members will almost double the number of members administered with PSPA in this state.

This implementation migrates the retirement plan to PeopleSoft from an unsupported older non-browser version of PensionGold using an Oracle database.

The plan introduces some unique plan rule requirements, including a 10-month school year, average full-time equivalent proration for part-time educators, and multiple contribution accounts and annuity election options.

Data Conversion

Some legacy system data needed to be converted.  During the prototype phase, the scope of the conversion was limited to a small segment of the overall member population.  The population was selected to represent a variety of scenarios useful for testing the process functionality.  The emphasis was on member data required for testing and did not include all data available for a member found in the legacy system. 

• Established access to a copy of the legacy system data, loaded into prototype environment staging tables. This copy of legacy system data did not change during the prototype phase.
• Reviewed legacy system data structures, code values, and data to map to PSPA data structures and inform configuration decisions. 
• Learned about data gaps, exceptions, historical differences, and quality issues that informed data cleanup and/or special conversion programming requirements.  
• Collaborated to define criteria for prototype population and mined legacy system data to find specific members for test cases. Identified legacy data structures that include target results for the prototype process, for example, account balance and calculation results.
• Created and executed basic, repeatable scripts to load data into PSPA data structures for the prototype population.  Refined and re-executed these scripts throughout the prototype phase as new data requirements or loading issues were identified.  There were dependencies on prototype configuration setup to inform the development of some prototype conversion scripts.

Concurrently, work began to convert the initial basic prototype conversion SQL scripts into Application Engine programs that call Component Interfaces to efficiently manage the conversion of all required data for a larger population. These programs will be tuned to run quickly and efficiently for the full population of members, perform validations on the data being converted, and provide detailed exception reporting.

Pension Process Configuration

Implementation of Plan Business Rules in PeopleSoft is broken down into a series of ordered steps, known as Function Results in PeopleSoft Pension.  During the prototype phase, these steps were rapidly implemented as complete, partial, or placeholder configurations for all the required steps for end-to-end processing.  The level of completeness initially varied depending on several factors; The clarity/completeness of the business rules to be implemented, whether the configuration capabilities of the delivered or PSPA extension functionality matched the requirements, and the effort required to build out missing functionality to meet the requirements.

Business Rules were implemented at a variety of levels, in order of preference:

• Configuration of delivered PeopleSoft functionality – following existing standards and patterns to maximize compatibility with extensions and make it easier to support.
• Configuration of existing custom extensions to leverage prior development to solve common problems.
• Modification of existing custom extensions to extend functionality to the new plan.
• Development of new custom extensions – ranging from simple to complex.

Detailed Scope

The scope of configuration for the Periodic Process included the following:

• Plan Enrollment, Plan Eligibility, Plan Participation, Eligible Employment, Original Hire Date
• Earnings, Contributions, and Service Conversion and Adjustments
• Earnings Consolidation – Earnings Codes
• Contribution Consolidation – Deduction Codes
• Service Equivalence, Service History, and Vesting for 5 Service Types
• Employee Accounts for 5 Account Types
• Early and Normal Retirement Date Projections
• Pension Statuses

The scope of configuration for the Calculation Process included the following:

• Benefit Eligibility for 5 Retirement Eligibility Tiers
• Full-Time Equivalence Average for 4 Types
• Final Average Salary with 401(a)17 Limits
• Benefit Calculations for 5 Retirement Formulas
• Optional Forms

As time allows during the prototyping phase:

• More data elements can be mapped and converted
• More members can be run through more test scenarios
• More refinements can be made to the configuration
• More gaps can be filled through the development
• Regression testing to validate no impact on non-TRS processing
• Complete configuration and extension specification documentation can be created/started

Some Scope Exclusion:

• Excludes Self-Service Estimates
• Excludes Death and Disability Calculations
• Excludes Earnings and Service Projections
• Excludes Employer Reporting – prototype uses only previously reported data
• Excludes Contribution Validation
• Excludes Service Purchases
• Excludes Billing

Testing

After the preliminary end-to-end configuration was established:

• Test processing (unit testing or end-to-end) can begin using the prototype conversion data, comparing results to the established results targets for the member.  The prototype system will attempt to match various ending balances and status values resolved using the member’s raw data.  Also, benefit calculation results will be compared to output from the legacy system. Test processes can be executed for individual members or groups of members.
• Overrides, Data Adjustments, and Process Selection options can be leveraged to work around steps that are not working completely yet, which makes unit testing possible for individual steps.
• Business Rules steps can then be refined in any order. 
• The extensions required for steps can be developed in any order. 
• Multiple steps can be worked on at the same time.
• The big picture of the required steps and the details and scope of business rules applicable to a particular step become clearer, making it easier for administrators to provide feedback.
• Integrations that leverage the processes can be developed while the core processes are refined.

When prototype testing failures are encountered, a variety of actions may be taken:

• Seek Business Rule clarification
• Alter configuration
• Alter or develop an extension
• Alter or add a gap to Fit/Gap documentation
• Temporarily adjust data, override step results, or skip processing steps to complete unit testing
• Alter or add prototype conversion scripts to add/correct converted data elements or add new test population members. 

Client Resource Requirements

• Provide guidance on legacy system data and data structures.
• Provide guidance on business rule interpretation and provide examples of applicable cases.
• Help define the prototype test scenarios and population, including providing validated expected results.
• Help run test processes, and review results.  Report and help investigate issues.
• Learn about configuration and ask questions.
• Observe prototype demonstrations and provide feedback.

Deliverables

• Prototype population categorized by applicable test scenarios with target results.
• Basic Prototype Conversion Scripts to load the prototype test population.
• Prototype for End-to-End Periodic Process and Calculation, including the system configuration and some custom extensions required to provide a demonstration with satisfactory results for the prototype test population.
• Preliminary Data Conversion Mapping and Design Documentation.
• Refined Process Fit/Gap analysis document with more requirement details, comprehensive solutions, and estimates for future phase planning.
• Implementation and Extension Specification Documentation with a comprehensive inventory and function descriptions of changes made to implement the prototype system, including migration instructions. 

Commentary

While developing the prototype, I attempted to carefully capture my experiences with error messages and what I did to resolve the errors. This information will be included in the knowledge base to provide suggestions for others that encounter similar problems. Even experts make configuration mistakes that can be tricky to resolve.

Also, while developing the prototype, I encountered several bugs and issues with the delivered PSPA application. I have also captured details of these issues and resolutions to include in the knowledge base.

In fact, I have attempted to document many of the configuration and gap challenges here in the knowledge base. Hopefully, this provides a general sense of the type of problems that may be encountered and how to work around them. Or perhaps, by chance, you may encounter the exact same problem and find a tested solution ready to implement.

Additional Resources

Continue reading the details of the case study to understand the rapid prototyping methodology better.

Rapid Prototype Case Study

• Rapid Prototype Methodology
• Outcomes and Executive Summary
• Test Population
• Test Automation
• Configuration Challenges
• Errors/Resolutions
• Prototype Conversion
• Gap Development
• Delivered Application Issues
• Array Sizing Issues
• Design Discussion