1. Project Reflection Implement New Open-System Rating Engine
by Ray Kutzer, PMP
Information Technology Division
Erie Insurance
January 18, 2011

2. Could Things Have Been Different Question and Answer
Agenda
Project Overview
Objective
Estimated hours and project completion
Risks and Issues
Initial Key Ones
During Project Key Ones
Deployment Details
Lessons Learned
Could Things Have Been Different
Question and Answer

3. Project Overview - Objective
Implement the New Open-Systems Rating Solution for the four lines of business. The project will use a new technical architecture for the rating components that aligns with the direction of the strategic architecture. The ABC Standing Team will deliver this project through multiple drops (by State groupings) in In addition, dual rating, Homes>$1m will also be delivered with this project.

4. Project Overview – Est hrs & completion
PM 1 – Starts 07/08 – Leaves 12/08
Projected hrs 28,000 – Projected finish 04/09
PM 1 – Starts 01/09 – Leaves 02/09
Projected hrs 34,000 – Projected finish 03/10
PM 2 – Starts 03/09 – Leaves 03/09
PM 3 – Starts 04/09 – Leaves 05/09
PM 4 – Starts 06/09 – Leaves 07/09 (not full-time)
PM 5 – Starts 08/09 – Finishes project 03/11
Projected hrs 52,000 – Projected finish 07/10
Final hrs 55,000 – Finish 03/11

5. Risk and Issues – Initial Key Ones
Risk – Lack of available product knowledge
Risk – Need new infrastructure components
Risk – Dependencies on other teams (priorities)
Risk – Adding requirements to the project
Risk – Volume of testing needed requires automation
Issue – Impact of regulatory projects

6. Risk and Issues – PM5 Project Key Ones
Issue – Need new infrastructure components installed in all environments (readiness effort)
Issue – New architectural components introduced instabilities that were unanticipated
Issue – New arch components introduced need for business rule and data transformations
Issue – Dependencies on other teams (priorities)
Issue – Changed state deployments from a simple one to a complex one months before planned deployment
Issue –

7. Project Overview – Deployments
03/10 – move rating arch components to production and a front-end workaround
06/10 – move special state features – first state done
07/10 – requests and incidents
08/10 – split batch
09/10 – deployed second state
10/10 – deployed one more state
11/10 – deployed two more states
12/10 – requests and incidents
01/11 – requests and incidents
02/11 – remaining states
RED = Actual date and was not the original planned date

8. Impact of the lack of cross program prioritization
Lessons Learned
Impact of the lack of cross program prioritization
Impact of resource contention
Effort needed to implement new infrastructural components into all environments (stage and prod)
Impact on future projects planned fro the same team as the current project delays
Blending of project and production support work within the same team

9. Could Things Have Been Different
What were the drivers that created the issues
Cross program priority impacts did not exist - false
New arch components were simple pass through events - false
Another project would drive the build out of the arch components – they would be ready for this project - false
Primary personnel goal was delivery - false
Team would not deploy unless quality was achieved
Forced a drive all the way to the deployment date before changing
Standing/defined team supports the application - true
Production support always takes priority
Delays the future project work – impacting delivery

10. Questions and Answers