Rock-Solid Life Insurance Inc

Rock-Solid Life Insurance Inc.:

Auditing Year 2000 Compliance Projects (B)

Prepared by Janis Gogan and Ashok Rao

Introduction

In late October 1997, as Peter King and Ben Scott prepared for the November meeting of the Audit Committee of the Board of Directors, King expressed concern about the status of Rock-Solid’s year 2000 compliance effort:

I’m new to the role of delivering bad news, and I find it difficult. Having just left the management side, I tend to see the glass half full. But the Year 2000 problem gives rise to significant business risks! I think it may be time for the glass-half-empty approach.

In late June 1997 the project managers had been provided with a detailed Strategic Business Unit (SBU) Y2K Planning document (Exhibit B1), based upon which the country offices had submitted new year 2000 project plans on September 1. The September plans, which King would discuss at the November meeting, represented a significant improvement over the documents provided to internal audit in the spring, in his view.[1]

There has been a good effort to develop sound project plans that appear to be adequately resourced. Evidently our Strategic Business Unit Planning Document helped give project managers a more detailed picture of the steps necessary in this project. The plans indicate a greater awareness of significant issues, such as the need for supplier reviews. However, the test plans are not well developed. Everybody will want to use the mainframe in Topeka at the same time, and that will not be possible. And, there is still a need for senior management to ensure that year 2000 projects become a higher corporate priority. Based on the plans I have reviewed, we are at risk of not completing the correction of mission-critical systems by our deadline.

King was also concerned about an apparent reliance on replacement projects. He noted: “Several business units in the U.S. and Canada are so busy developing ambitious new systems that their Year 2000 project is still not a priority.” As the deadline drew near he felt “it may become necessary to renovate some of the older systems that are scheduled to be replaced.” He also worried about systems that share data with external parties, such as banks and corporate customers. “We need to ensure that our systems can talk accurately with other systems.”

King also received a progress report (Exhibit B2) from Don Meyer the Vice President for IS Planning and head of the Worldwide Year 2000 Project Management Office. Although it was supposed to cover all Rock-Solid systems, King wondered if it fully accounted for user-developed applications. “A lot of end-user computing produces management information. Many of our board presentations rely on spreadsheet data, for example.”

If we have problems in January 2000 I don’t want people to look back and say, ‘Internal audit did not do their job.’ As Internal Auditor, my role is to monitor, not direct. But since I want people to succeed rather than fail, we gave them detailed guidelines. That seems to have helped the country offices to get better focused. Now I would like to see Corporate IS take a more proactive role in this. Granted, they have limited authority to dictate what country offices do. Still, I believe they are doing too much monitoring and not enough pushing.

Our external auditors have not asked me a single question about our Year 2000 efforts. I'm a little shocked that they have not been more proactive. Like many managers here at Rock-Solid, they seem to believe that there is plenty of time to deal with this issue. But time is running out!

Exhibit B1

ROCK-SOLID Y2K PLANS AUDIT PROGRAM: Strategic Business Unit Y2K PLANNING[2]

Audit Objectives: The Y2K plans as of September 1, 1997:

1. Properly assign responsibility for effecting Y2K compliance;

2. Properly scope the extent of the Y2K problem;

3. Ensure the acquisition and retention of the resources required to effect Y2K compliance;

4. Establish appropriate target dates and project milestones in order to achieve the corporate-wide goal; and

5. Provide for appropriate management and monitoring mechanisms for the Y2K effort.

The Corporate-Wide goal is that all applications be Y2K compliant by December 31, 1998. Y2K compliance means that all related redevelopment/modifications, testing and migration to production be completed by December, 1998. For an application system to be Y2K compliant, it must:

1. Manage and manipulate data involving dates, including single- and multi-century formulas, without causing an abnormal end scenario within the application or generating incorrect values involving such dates;

2. Ensure that date-related user/data interface functionality includes an indication of the century.

Scope: This audit program reviews the Y2K plans of the business units within each country office and General Services. This includes the plans for mainframe, AS/400, Sun Microsystems, application servers (NT), print and file servers (Novell) and desktop PC business applications.The audit program does not address:

• Corporate-wide project management practices related to Y2K;
• The configuration and management of the Y2K mainframe and environment; and
• Infrastructure/systems software.

Section 1 - Plan Coordination

1.1 Has responsibility for preparation of the Y2K plan for a business unit been assigned to an individual?

1.2 Is the individual required to provide regular status reports to a central coordinating individual within the Country Office or project office based on a common format?

1.3 Has an appropriate process been put in place to ensure that certification of Y2K compliance is obtained for all packaged application vendors, system management vendors, operating system vendors, and business partners with whom electronic commerce is conducted (EDI, EFI, etc.)?

1.4 Determine whether Y2K compliance protection is being built into all future software contracts with vendors and business partners?

1.5 Has an inventory been completed? If YES, complete Section 2.

1.6 Has an initial assessment been made? If YES, complete Section 3.

1.7 Has the impact analysis been completed? If YES, complete Section 4.

1.8 Has a Y2K plan been developed? If YES, complete Section 5.

If an answer to any of questions 1.5 to 1.8 was NO, determine the project manager’s estimate for completion

of the uncompleted project phases that lead up to the development of a plan:

Inventory

Initial assessment

Impact analysis

Plan development

Determine the reasons for failing to have a documented plan (e.g., inventory recently commenced, large number of applications, insufficient resourcing, etc.) by the corporate-wide goal.

Exhibit B1, continued

Section 2 - Inventory Taking

2.1 Have appropriate steps been taken to ensure that all end user applications (including PC/desktop) are identified and included in inventory?

2.2 Do application inventories include the necessary elements that will allow the assessment of risk, cost and time horizons surrounding the Y2K challenge?

Section 3 - Initial Assessment/Scoping

3.1 Have the inventories been segmented into Logical Application Segments? (LAS comprise applications, databases, runtime components and interfaces to be made compliant at the same time. These can be sub-portions of an application, the application itself, multiple applications, etc.)

3.2 Has a time horizon to failure (where LAS no longer conforms to business requirements due to incorrect date handling and date related failures are of such quantity that they cannot be corrected during normal maintenance activities) been determined for each LAS?

3.3 Has each of the LAS been ranked relative to its importance to the business unit’s function?

Section 4 - Impact Analysis

4.1 Have Lines of Code (LOC) estimates been developed for each Logical Application Segment (LAS)?

4.2 Is the estimate of LOC reasonable?

4.3 Has a strategy been developed for each application to make the LAS Y2K compliant?

4.4 For LAS that will be repaired, has a decision been made as to whether:

a logic based approach (windowing) will be adopted (program logic is implemented to reconcile multi-century scenarios that utilize two-digit years); or

a data based approach will be adopted (date elements be expanded to include the century)?

4.5 Have specific plans been developed to assess legacy systems that may not have sufficient documentation or source code to enable their modification to become Y2K compliant?

4.6 Have preliminary estimates of costs been built?

4.7 Have application complexity estimates been made (complex applications are at greater risk of missing conversion target dates)?

4.8 Has a review of maintenance contracts been scheduled with vendors to determine if maintenance will remain in effect should internal customization be required to make a system Y2K compliant …(these changes could render maintenance upgrades irrelevant or impossible to apply)?

4.9 For vendor packaged application software which are to be made compliant by the supplying vendor, has an assessment been made of the extent of interfacing this package has with in-house systems?

Exhibit B1, continued

Section 5 - Y2K Plan

5.1 Does the plan incorporate the results of the inventory, initial assessment, and impact analysis?

5.2 Does the plan assign accountabilities for the following project deliverables?

Test Plans

Redevelopment/Modification

Testing

Implementation

Data Conversion (data bases, master files)

5.3 Have target dates been established for deliverables/project phases that will ensure that the Corporate-Wide goal (Y2K redevelopment/modifications, testing and migration to production completed by 12/1998) will be achieved? If NO, determine estimated completion date for documentation of target dates for remaining project phases.

5.4 Have appropriate standards for certification for each LAS been defined in the plan, i.e., acceptance criteria?

5.5 Does the plan appropriately address how parallel maintenance will be performed?

5.6 Have training requirements for testers, developers, and the project team been identified and planned for?

5.7 Does the plan ensure that LAS are promoted to production to ensure that the number of bridges and interfaces required to make them coexist with noncompliant LAS are limited? The expectation is that bridges and interfaces would be required for a short time period until the last compliant LAS is put into production. Too many bridges and interfaces will cause extra work and may be a source of application failure.

5.8 Does the plan address how to attract, acquire and retain critical testing personnel? The definition of testing environments? Testing target dates?

5.9 Are the planned resources realistic?

5.10 Have resources been allocated to the major phases appropriately?

5.11 Has the plan addressed how it will staff those resource requirements (internal or external staff)?

5.12 If external staff is to be used, does the plan address the budgetary funding for external consultants and temporary help?

5.13 Given requirements and the plan to staff the resource requirements, are the target completion dates realistic?

5.14 Have contingency measures been documented in the plan? Do the resources allocated and milestone target dates reflect the contingency analysis?

5.15 Have “drop-dead” dates been assigned to each system replacement project scheduled to be undertaken to effect Y2K compliance? In the event that the project can not be completed within the required time lines, a date must be established beyond which alternative compliance strategies will be pursued.

Exhibit B2

From:Don W. Meyer, Vice President Information Systems Planning

Re:Year 2000 Project Status (September, 1997)

Project teams in the strategic business units have provided plans delineating their overall year 2000 project schedules. The project plans are the focus of a company-wide report being prepared by Internal Audit for presentation to the Audit Committee of the Board.

A significant number of replacement projects are included in the numbers – that is, instances in which systems are being replaced outright with new systems, as opposed to existing systems that are being fixed. Further information will be provided in next months’ report.

Staff turnover and difficulty obtaining replacements is becoming a pressing issue. The Human Resource areas in the various Offices are engaged in looking for solutions.

Notes on the Status Spreadsheet

This summarizes information provided by each Project Management Office.

Application systems are categorized by three levels of business risk:

• High: mission critical, may have complex coding, face resource constraints, or have many interfaces.
• Medium: important but not critical, few interfaces, not too complex for available resources to correct.
• Low: non-critical application which may be standalone, and may be nearly compliant.

The primary goal is to ensure that all “High” risk applications are addressed as quickly as possible.

The “phase” which is assigned describes a traditional measure of progress in a systems maintenance life cycle:

Phase 0: not started

Phase 1: system inventory

Phase 2: impact analysis

Phase 3: conversion

Phase 4: testing

Phase 5: implementation

In order to summarize progress by business unit, the average of the phases was calculated for all applications within a business risk category (e.g., if a business unit has four systems that fall within a particular risk grouping, the phases of those systems are summed and divided by four to arrive at an average).

Progress is also being tracked by showing variance with previous entries. Initially this will involve showing the comparable progress (by phase) from the previous month. Where there are enough data to show quarterly variance the spreadsheet will do so.

Rock-Solid Life Insurance (B)Page 1

Exhibit B2, continued

August 1997 Year 2000 Status

Business Unit / Total Apps/
Compliant / High Risk/
compliant / Average Progress
by Phase / Med Risk/
compliant / Average Progress
by Phase / Low Risk/
compliant / Average Progress
by Phase
Corporate
Staff / 3 / 0 / 1.2 / 21 /2 / 2.5 / 45 /13 / 2.35
Investment Systems / 1 / 0 / 1.0 / 11 / 0 / 1.9 / 45 / 0 / 0.9
Actuarial & Val. / 66 /0 / 1.8 / 32 / 0 / 1.1 / 92 / 0 / 1.0
Total / 318 / 15 / 70 / 0 / 64 / 2 / 184 / 13
United States
Pension & Savings / 4 / 0 / 2.3 / 9 / 0 / 2.1 / 15 / 0 / 2.0
Finance Systems / 26 / 0 / 2.5 / 28 / 0 / 2.4 / 76 / 2 / 2.4
Individual Systems / 18 / 0 / 2.7 / 12 / 0 / 2.2 / 4 / 0 / 2.0
Investment Systems / 11 / 0 / 2.9 / 5 / 0 / 2.0 / 6 / 0 / 2.0
Information Systems / 88 /1 / 2.1 / 45/0 / 2.3 / 80/0 / 2.3
Other / 0 / 0 / - / 8 / 0 / 2.0 / 23 / 0 / 2.1
Total / 458 / 3 / 147 / 1 / 107 / 0 / 204 / 2
Canada
Group / 9 / 0 / 1.9 / 16 / 0 / 1.6 / 40 / 1 / 1.5
Pension & Savings / 3 / 0 / 3.3 / 10 / 0 / 1.1 / 40 / 0 / 1.0
Staff / 7 / 0 / 2.3 / 9 / 0 / 2.1 / 67 / 3 / 2.0
Individual Insurance / 10 / 0 / 2.7 / 19 / 0 / 2.3 / 41 / 0 / 1.9
Other / 2 / 2 / 5.0 / 17 / 2 / 2.1 / 44 / 10 / 2.6
Total / 334 / 18 / 31 / 2 / 71 / 2 / 232 / 14
Europe
Individual Systems / 20 / 0 / 2.6 / 14 / 0 / 2.8 / 6 / 0 / 2.5
Finance Systems / 16/0 / 3.1 / 7/0 / 3.2 / 2/0 / 2.0
Group Systems / 2 / 0 / 3.0 / 6 / 0 / 2.0 / 1 / 0 / 2.0
Other / 3 / 0 / 2.3 / 0 / 0 / - / 1 / 0 / 2.0
Total / 78 / 0 / 41 / 0 / 27 / 0 / 10 / 0
General Services
M/F infrastructure / 161 / 46 / 3.1 / 82 / 3 / 2.0 / 111 / 9 / 2.3
AS400 infrastructure / 139 / 0 / 1.0 / - / - / 3 / 2 / 4.0
LAN/network / 1 / 0 / 2.0 / 12 / 0 / 1.1 / 37 / 3 / 1.6
Solaris/AIX / 2 / 0 / 1.0 / - / - / 7 / 0 / 2.1
Voice infrastructure / 4 / 0 / 1.0 / 3 / 0 / 1.0 / - / -
Firmware / 27 / 0 / 1.4 / 39 / 0 / 1.1 / 3 / 0 / 1.7
Services desktop / 11 / 0 / 1.7 / 27 / 0 / 1.8 / 43 / 8 / 2.7
Not assigned / 1 / 0 / 4.0 / 7 / 1 / 1.9 / - / -
Total / 710 / 72 / 346 / 46 / 170 / 4 / 194 / 22
Company Total / 1898 / 108 / 635 / 49 / 439 / 8 / 824 / 51

Rock-Solid Life Insurance (B)Page 1

[1] As of the publication date of this case, the company had not released actual project plans for publication.

[2]This is an abbreviated version of a Rock-Solid Insurance Inc. Corporate Internal Audit document with the same title. Discussion of specific evidence that the auditor would seek in support of each numbered item has been omitted.