EMS Migration SRP Info Electric customers end FY

EMS Migration

SRP Info Electric customers, end FY 06 892, 875 ¢ Electric service area, 2900 sq. mi. ¢ Peak retail load, 6599 MW ¢ Customer growth rate, approx. 35, 000/year ¢

SRP EMS Approximately 300 RTU’s ¢ ICCP points imported: over 2, 000 ¢ Using Network Applications ¢

EMS Migration From contract signing to cutover – less than 10 months ¢ How was this accomplished? ¢ What was learned from the experience? ¢

Evaluation of Existing EMS ¢ Legacy system nearing end-of-life Reliable performance overall l Vendor support staff conscientious and helpful l ¢ Review Support requirements including SRP manpower l Customer needs for enhancements l

Business Needs of the EMS Common IT Standards ¢ Acceptable vendor support levels ¢ Minimize operating cost ¢ Minimize support requirements ¢ Disaster recovery and business resumption ¢ Evolve, over time, to newer technologies ¢

Develop List of Potential Vendors ¢ Criteria for Vendor Viability Technical capabilities l Product evolutions l Customer evaluations l

Pre-Qualification of Bidders ¢ Assessment of vendors by SRP Potential bidders track records l Budgetaries provided by vendors l Project team experience including site visits l Ability to support implementation plan l

Evaluation of Costs ¢ Focus on Life Cycle costs Contract cost including vendor supplied “specials” l Cost to utility over life of system l • Maintenance costs • Upgrade costs ¢ Life cycle duration – 6 years

Decision – Sole Source with OSI ¢ Why Sole Source? Technical excellence including architecture l Maintenance manpower requirements l End-user enthusiasm l Unfairness to ask other vendors to bid l ¢ Downside l Must receive SRP Board approval

Decision – Sole Source with OSI ¢ Before Approval by Board Must establish all terms and conditions l SRP’s legal department reviews and approves T&C’s l With T&C’s in place, request goes on agenda l Board meets once a month l

Decision – Sole Source with OSI ¢ While waiting for Board Approval Started project planning/organization l Established Team Assignments l Conference calls to work on planning l Identify data/displays needed for migration l

Project Schedule ¢ 10 Month schedule Cutover target date – April 2, 2007 l Cutover before “Storm Season” ‘ 07 l Other competing projects planned for Fall, ’ 07 l Legacy system – only essential updates/enhancements l Very aggressive schedule l

Project Team

Project Management Staying on Schedule Weekly Progress reports ¢ Weekly conference calls between SRP and OSI ¢ Progress closely monitored ¢

Project Management Staying on Schedule ¢ Project Change Control Enhancement requests required approval of Steering Committee Chairman l Reduced scope creep l Changes for SRP’s business needs did not require review l

Early Training at OSI ¢ Early training given for two key project team members Training program specifically built for SRP’s needs l Preparation to guide and direct others in the project l Given key roles installing/supporting SRP’s Development system l

SRP’s Development System ¢ System installed at SRP August, ’ 06 All RTU’s connected in “listen mode” l Incoming ICCP data sent to system l Software development l Installation/verification of DB’s and displays from OSI l Network Apps tuning l

Staying on Schedule Software Development ¢ Software from OSI sent to SRP l ¢ Concurrently, SRP developed software l ¢ Installed on the Development system Installed/tested on the Development system Version control used to manage updates

Staying On Schedule Data & Display Migration ¢ Coordinated with vendor on specific data and displays needed for migration Vendor had previous project experience with display migration l SRP exported data and displays as CSV files l Every week or so, SRP sent updated files to vendor l DB updates installed on Development system l

Staying on Schedule ¢ As project needs were identified Paid Overtime was approved l Some attended training by day – worked on project assignments during evenings/weekends l

Staying on Schedule ¢ Factory Acceptance Test Moved up from Jan ’ 07 to Dec ’ 06 l Provided more time to fix problems l Not all customs available in Dec ’ 06 l Deferred some testing to Site Acceptance Test l

Staying on Schedule ¢ Factory Acceptance Test Long days for SRP – 11 to 12 hours l Longer days for OSI project team l • Arrived early (before SRP) • Stayed late to prepare for the next day’s tests

Staying On Schedule Within Days Prior to Cutover SRP completed infrastructure upgrade for ICCP link ¢ Completed formal training of dispatchers ¢

Keeping on Schedule At time of Cutover Some operational issues remained l l ¢ Issues were “blessed” by respective dispatching groups Mutually agreed to address these issues after cutover SRP did not have all of its maintenance tools in place

On-line Test and Cutover ¢ 2 -hour On-line Test Monday evening, March 26, 2007 l Test was successful l ¢ Cutover to monarch™ Thursday morning, March 29, 2007 l Target date: April 2, 2007 l

Lessons Learned Tracking Issues ¢ Issues reported/stored in too many different forms: Phone conversations l E-mail l Variances in vendors tracking system l SRP’s problem reporting system l ¢ Needed a consistent, unifying method to track ALL project issues

Lessons Learned Some Success ¢ Throughout the project, version control used to manage updates l Concurrent work going on at OSI and SRP • Great need for a disciplined approach to version management

Lesson Learned ¢ monarch API allowed SRP to build custom applications for SRP’s business needs

Throughout the Project l As one SRP team member stated, OSI “jumped through hoops” • Creating specials needed by SRP • Updating the base product

Project Completed ¢ Contract signing to cutover l ¢ Elapsed time: Less than 10 months Tremendous Effort by SRP and OSI Great Teams l Great Cooperation l