NATL INST OF STAND & TECH

111 'II HI!

AlllDb T7fl3Dfl

of Commerce

National Bureau

of Standards

Computer Science ^ ' ^

and Technology

NBS

PUBLICATIONS

NBS Special Publication 500-105

Guide to Software Conversion

Management
NATIONAL BUREAU OF STANDARDS

The National Bureau of Standards' was established by an act ot Congress on March 3, 1901. The Bureau's overall goal is to strengthen and advance the Nation's science and technology

and facilitate their effective application for public benefit. To this end, the Bureau conducts

research and provides: (1) a basis for the Nation's physical measurement system, (2) scientific and technological services for industry and government, (3) a technical basis for equity in trade, and (4) technical services to promote public safety. The Bureau's technical work is per- formed by the National Measurement Laboratory, the National Engineering Laboratory, and

the Institute for Computer Sciences and Technology.

THE NATIONAL MEASUREMENT LABORATORY provides the national system of

physical and chemical and materials measurement; coordinates the system with measurement

systems of other nations and furnishes essential services leading to accurate and uniform

physical and chemical measurement throughout the Nation's scientific community, industry,

and commerce; conducts materials research leading to improved methods of measurement,

standards, and data on the properties of materials needed by industry, commerce, educational

institutions, and Government; provides advisory and research services to other Government

agencies; develops, produces, and distributes Standard Reference Materials; and provides

calibration services. The Laboratory consists of the following centers:

Absolute Physical Quantities^ — Radiation Research — Chemical Physics —

Analytical Chemistry — Materials Science

THE NATIONAL ENGINEERING LABORATORY provides technology and technical ser- vices to the public and private sectors to address national needs and to solve national problems; conducts research in engineering and applied science in support of these efforts; builds and maintains competence in the necessary disciplines required to carry out this research and technical service; develops engineering data and measurement capabilities;

provides engineering measurement traceability services; develops test methods and proposes

engineering standards and code changes; develops and proposes new engineering practices;

and develops and improves mechanisms to transfer results of its research to the ultimate user. The Laboratory consists of the following centers:

Applied Mathematics — Electronics and Electrical Engineering^ — Manufacturing

Engineering — Building Technology — Fire Research — Chemical Engineering^

THE INSTITUTE FOR COMPUTER SCIENCES AND TECHNOLOGY conducts

research and provides scientific and technical services to aid Federal agencies in the selection, acquisition, application, and use of computer technology to improve effectiveness and

economy in Government operations in accordance with Public Law 89-306 (40 U.S.C. 759), relevant Executive Orders, and other directives; carries out this mission by managing the Federal Information Processing Standards Program, developing Federal ADP standards

guidelines, and managing Federal participation in ADP voluntary standardization activities; provides scientific and technological advisory services and assistance to Federal agencies; and

provides the technical foundation for computer-related policies of the Federal Government.

The Institute consists of the following centers:

Programming Science and Technology — Computer Systems Engineering.

'Headquarters and Laboratories at Gaithersburg, MD, unless otherwise noted; mailing address Washington, DC 20234. 'Some divisions within the center are located at Boulder, CO 80303.
JIAnOKAL BXJREAa Of STANDARDS UBHART

Computer Science

and Technology

dJroClL/60

.uS.1

NBS Special Publication 500-105

Guide to Software Conversion

Management

M. Skall, Editor

Institute for Computer Sciences and Technology

National Bureau of Standards

Washington, DC 20234

Prepared by: CRC Systems, Incorporated

4020 Williamsburg Court

Fairfax, VA 22032

U.S. DEPARTMENT OF COMMERCE

Malcolm Baldrige, Secretary

National Bureau of Standards

Ernest Ambler, Director

Issued October 1 983
Reports on Computer Science and Technology

The National Bureau of Standards has a special responsibility within the Federal

Government for computer science and technology activities. The programs of the

NBS Institute for Computer Sciences and Technology are designed to provide ADP

standards, guidelines, and technical advisory services to improve the effectiveness

of computer utilization in the Federal sector, and to perform appropriate research

and development efforts as foundation for such activities and programs. This

publication series will report these NBS efforts to the Federal computer community as

well as to interested specialists in the academic and private sectors. Those wishing

to receive notices of publications in this series should complete and return the form

at the end of this publication.

Library of Congress Catalog Card Number: 83:600589

National Bureau of Standards Special Publication 500-105

Natl. Bur. Stand. (U.S.), Spec. Publ. 500-105,220 pages (Oct.1983)

CODEN: XNBSAV

U.S. GOVERNMENT PRINTING OFFICE

WASHINGTON: 1983

For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, DC 20402

Price $6.50

(Add 25 percent for other than U.S. mailing)
TABLE OF CONTENTS

SECTION DESCRIPTION PAGE

ABSTRACT 1

1 INTRODUCTION 2

1.1 OVERVIEW 2

1.2 GUIDE QUALIFICATIONS 3

1.3 HISTORY OF SOFTWARE CONVERSION 5

1.4 SOFTWARE CONVERSION IN THE

INFORMATION SYSTEM LIFE CYCLE 7

1.5 PROJECT INITIATION PHASE 9

1.6 CONVERSION REQUIREMENTS PHASE 11

1.7 CONVERSION PLANNING PHASE 11

1.8 CONVERSION PREPARATION PHASE 12

1.9 CONVERSION PHASE 12

1.10 POST-CONVERSION PHASE 12

1.11 APPENDICES 13

2 PROJECT INITIATION PHASE 14

2.1 REASONS FOR CONVERSION 14

2.2 PROJECT INITIATION OBJECTIVE 16

2.3 PROJECT INITIATION ACTIVITIES 16

2.4 PROJECT MANAGEMENT APPOINTMENT AND

PROJECT TEAM ESTABLISHMENT 16

2.5 INFORMATION SYSTEM USER

AND TOP MANAGEMENT INTERFACE 19

2.6 PROJECT REPORTING AND CONTROLS 20

2.7 PRELIMINARY PLANNING 21

iii
TABLE OF CONTENTS

SECTION DESCRIPTION PAGE

2.8 ACCOMPLISHING THE FEASIBILITY

STUDY AND COST ANALYSIS 26

2.9 PROJECT INITIATION

MANAGEMENT DECISIONS 30

2.10 ECONOMIC CONSIDERATIONS 30

2.11 PROJECT INITIATION

MANAGEMENT CHECKLIST 30

3 CONVERSION REQUIREMENTS PHASE 32

3.1 REQUIREMENTS PHASE OBJECTIVES 32

3.2 CONVERSION REQUIREMENTS ACTIVITIES 33

3.3 PROJECT TEAM STAFFING

AND ORGANIZATION 33

3.4 APPLICATION SYSTEMS AND PROGRAMS

INVENTORY EXTENSION AND ASSESSMENT 35

3.5 DATA FILES INVENTORY

) EXTENSION AND ASSESSMENT 39

3.6 CONVERSION TOOLS

IDENTIFICATION AND SELECTION 42

3.7 WORKLOAD ESTIMATION REFINEMENT 45

3.8 DISTRIBUTED AND TELEPROCESSING

REQUIREMENTS DEFINITION 46

3.9 SYSTEMS SOFTWARE

REQUIREMENTS DEFINITION 46

3.10 PERSONNEL REQUIREMENTS DEFINITION 47

3.11 SECURITY REQUIREMENTS DEFINITION 47

3.12 CONVERSION FACILITIES

REQUIREMENTS DEFINITION 48

3.13 SOFTWARE CONVERSION

STUDY PREPARATION 49

IV
TABLE OF CONTENTS

SECTION DESCRIPTION PAGE

3.14 REQUIREMENTS PHASE

MANAGEMENT DECISIONS 50

3.15 COST AND ECONOMIC CONSIDERATIONS 51

3.16 REQUIREMENTS MANAGEMENT CHECKLIST 52

4 CONVERSION PLANNING PHASE 54

4.1 PLANNING OBJECTIVES 54

4.2 - DECISIONS IMPACTING PLANNING 55

4.3 CONVERSION PLANNING ACTIVITIES 56

4.4 ORGANIZATION OF THE

PROJECT TEAM FOR PLANNING 58

4.5 CONVERSION STAFFING PLAN 58

4.6 PLANNING FOR CONTRACTUAL

ASSISTANCE/AUTOMATED CONVERSION TOOLS 61

4.7 PLANNING FOR TRAINING 64

4.8 PLANNING THE SOFTWARE CONVERSION

SCHEDULE AND DEVELOPING PLANNING

TRACKING MECHANISMS 66

4.9 SOFTWARE PREPARATION PLANNING 73

4.10 FUNCTIONAL USER AND

EXECUTIVE INVOLVEMENT 76

4.11 HARDWARE ACTIVITIES 77

4.12 PLANNING FOR LOCATING

THE CONVERSION TEAM 78

4.13 PLANNING FOR DOCUMENTATION

OF CONVERTED PROGRAMS 78

4.14 CONTINGENCY PLANNING 78

4.15 SECURITY/ PLANNING 79

4.16 TELECOMMUNICATIONS PLANNING 80

4.17 FORMAL CONVERSION PLAN 80

V
TABLE OF CONTENTS

SECTION DESCRIPTION PAGE

4.18 PLANNING DECISIONS 82

4.19 ECONOMIC CONSIDERATIONS 82

4.20 PLANNING MANAGEMENT CHECKLIST 83

5 CONVERSION PREPARATION PHASE 856

5.1 OBJECTIVE 85

5.2 DECISIONS IMPACTING

SOFTWARE CONVERSION 87

5.3 CONVERSION PREPARATION ACTIVITIES 87

5.4 BUDGET APPROVAL 89

5.5 DEVELOPMENT OF WORK PACKAGES 89

5.6 ASSEMBLE CONVERSION TEAM 90

5.7 TRAINING 90

5.8 OBTAINING CONTRACTUAL ASSISTANCE

AND AUTOMATED CONVERSION TOOLS 91

5.9 LOCATING CONVERSION

TEAM/OBTAINING EQUIPMENT 93

5.10 CONVERSION FACILITIES 93

5.11 DEVELOPMENT OF TEST FILES AND DATA 93

5.12 PROGRAM MODIFICATION AND

INCORPORATION OF USER

ENHANCEMENTS INTO SOFTWARE 94

5.13

I DOCUMENTATION 95

5.14 i HARDWARE PROCUREMENT 95

i 5.15 ' USER AND TOP

MANAGEMENT INVOLVEMENT 95

5.16 TRACKING PROGRESS 96

5.17 DEALING WITH UNFORESEEN PROBLEMS 96

vi
TABLE OF CONTENTS

SECTION DESCRIPTION PAGE

5.18 CONVERSION PREPARATION

MANAGEMENT DECISIONS 100

5.19 ECONOMIC CONSIDERATIONS 100

5.20 CONVERSION PREPARATION

MANAGEMENT CHECKLIST 101

6 THE CONVERSION PHASE 103

6.1 OBJECTIVE 103

6.2 CONVERSION PHASE ACTIVITIES 103

6.3 MANAGEMENT, ORGANIZATION

AND STAFFING 105

6.4 EXTERNAL INTERFACE AND COORDINATION 107

6.5 TRAINING 109

6.6 SECURITY CONSIDERATIONS 109

6.7 THE SOFTWARE CONVERSION 109

6.8 UNIT AND SYSTEMS TESTING 111

6.9 PARALLEL TESTING AND CROSSOVER 114

6.10 DOCUMENTATION 114

6.11 CONVERSION MANAGEMENT DECISIONS 115

6.12 ECONOMIC CONSIDERATIONS 115

6.13 CONVERSION PHASE

MANAGEMENT CHECKLIST 116

7 THE POST-CONVERSION PHASE 118

7.1 OBJECTIVES 118

7.2 POST-CONVERSION ACTIVITIES 118

7.3 CONVERSION TERMINATION/TRANSITION

ACTIVITIES 121

vii
TABLE OF CONTENTS

SECTION DESCRIPTION PAGE

7.4 COST TRACKING 123

7.5 POST-CONVERSION ANALYSIS

AND ASSESSMENT 124

7.6 PLANNING AND INITIATING ACTIONS

TO IMPROVE FUTURE CONVERSIONS 129

7.7 POST-CONVERSION

MANAGEMENT DECISIONS 133

7.8 ECONOMIC CONSIDERATIONS 133

7.9 POST-CONVERSION

MANAGEMENT CHECKLIST 134

APPENDIX A BIBLIOGRAPHY 136

APPENDIX B CONVERSION DIRECTIVES, STANDARDS 141

AND REFERENCES

APPENDIX C SOFTWARE CONVERSION COSTING 145

APPENDIX D CASE STUDIES 179

APPENDIX E GLOSSARY OF TERMS USED IN

IN THIS GUIDE 206

viii
LIST OF FIGURES

FIGURE DESCRIPTION PAGE

1-1 Software Conversion Organization 6

1-2 Software Life Cycle 8

1-3 Software Life Cycle 8

1-4 Software Conversion Life Cycle 8

1-5 Software Conversion Phase Relationships 10

2-1 Project Initiation Phase Activities 17

2-2 Prepare and Finalize Feasibility Studv 28

3-1 Conversion Requirements Phase Activities 34

3-2 Sample Program Worksheet 37

3-3 Complexity Table 38

3-4 Sample File Worksheet 41

4-1 Conversion Planning Phase Activities 57

4-2 Sample Matrix Management Planning 60

4-'* Sample Reporting Hierarchy 62

4-4 Sample Application System Schedule 69

4-5 Sflmnlp Annliofltion Propram Sphpdulp 69

4-6 Sample File Conversion Schedule 70

4-7 Sample Personnel Assignment Schedule 71

4-8 Project Management Tracking Packages 72

4-9 Sample Weekly Program Status Report 74

4-10 Sample Weekly Status Timeline 75

ix
LIST OF FIGURES

FIGURE DESCRIPTION PAGE

4-11 Sample Outline of Conversion Plan 81

5-1 Phase Interaction 86

5^ Conversion Preparation Activities 88

6-1 Conversion Phase Activities 104

6-2 Software Conversion Team Skills 106

and Numbers Over Time

6-3 Unit and Systems Testing 112

7-1 Post-Conversion Activities 119

C-1 Cost Development Process 149

C-2 Software Conversion Cost Element Detail 152

C-3 Software Conversion Function Detail 158

C-4 Relationship of Phases and

Cost Elements to Conversion Functions 162

C-5 Economic Considerations by Phase 173

X
GUIDE TO

SOFTWARE CONVERSION MANAGEMENT

John J. Mayers

Neil Katz

Larry Hoover

ABSTRACT

This guide was developed to help Federal ADP managers

understand the entire process of software conversion and manage that

process more effectively. Software conversions have life cycles with

distinct phases. A better understanding of the conversion process and its

associated costs, should help managers to plan and execute more

software conversions more efficiently, effectively and with minimum

operations disruption to Federal agencies. Although extensive references

were consulted in preparing this guide, the most important sources were

interviews conducted at fourteen Federal agencies that had completed or were involved in software conversion projects.

Keywords: Conversion costs; conversion planning; project management;

conversion requirements; conversion preparation; conversion execution;

documentation.
SECTION 1

INTRODUCTION

1.1 OVERVIEW

Previous studies of Federal conversions conducted by the

General Accounting Office and the National Bureau of Standards revealed

that there were management-related problems in the planning and

execution of software conversion (23, 42, 43). In preparing for this guide

interviews were conducted at fourteen Federal agencies. Managers were

consulted who were involved in planning, preparing for, executing, or

assisting in software conversions. These interviews revealed that the

management problems addressed by GAO and NBS persist, because:

o The total software conversion process is not well

understood)

o This lack of uiKlerstanding leads to inadequate planning,

preparation and a failure to apply practical management

procedures at the right time to control the conversion

process,

o Software conversion costs and resources are not totally

understood, considered or applied.

The goal of this guide is to provide information which can be

used by Federal ADP system mane^ers to resolve management problems

and to accomplish all aspects of a software conversion in a more

expeditious and cost-effective manner. Specifically, this guide is to

provide assistance in the following areas:

) o Understanding software conversion, o Planning, o Project control, o Scheduling, o Staffing, o Application of resources.

There are many references which apply to software

conversion. However, no reference treats the entire software conversion

process from start to finish. In this regard, this guide is unique. It provides managers a perspective and description of software conversion,

from project initiation through post conversion. It facilitates better

understanding of the conversion process and thus, better management. It

is not intended for this guide, however, to replace

2
other obligatory or useful directives and references. This guide serves as a supplement to other references and facilitates their application to

specific agency conversions.

Software conversions in the Federal government range from

very large projects taking upwards of five years to complete to very small

projects lasting a matter of months. The conversions, which involve

both code compatible machines and non-code compatible machines,

vary in complexity. Further, Federal agencies differ considerably

in size, organization and function and in their use of ADP. It is not

feasible to develop a guide which covers every software conversion

possibility. Consequently, this guide does not dictate a single method for

accomplishing software conversion; rather it describes a broad range of

procedures, techniques, considerations and activities, which if selectively

implemented, will assist managers in minimizing the negative aspects of

software conversion upon an agency's ADP organization, information

systems and system users. It should provide managers the insight

necessary to tailor conversion planning and execution to actual agency

needs.

Additionally, the guide stresses many of the problems common

to conversion efforts. These include not only ^ort term problems

specific to a conversion such as inadequacies in project management, but

also longer term problems which have an impact on conversion and other

software management considerations as welL An example of the latter is failure to use stemdardized languages. Use of non-standard languages, not

only increases difficulty in conversion but also limits the ability to

transport that software to another agency which might desire its use.

1^ GUIDE QUALIFICATIONS

1.2.1 SOFTWARE CONVERSION-HARDWARE REPLACEMENT

Most software conversions result from the need to replace

hardware systems because of processing saturation or equipment

obsolescence. While there are other reasons for software conversion (e.g.,

transfer of a mission from one agency to another with a concomitant

transfer of information systems), this guide is oriented towards conversion

stemming from hardware replacement. Further, this guide assumes a non-code compatible conversion since this conversion condition produces

the most problems and thus the most management lessons.

Users of this guide are cautioned that hardware replacement

has only been addressed to support discussion of software conversion.

From a total agency ADP standpoint there are many more hardware issues

of interest to memagement. While this guide provides a limited discussion

of some hardware replacement problems, a manager who is interested in

both software conversion and hardware conversion must consider sources

of information other than this guide.

3
1.2.2 SOFTWARE CONVERSION LEVEL OF EFFORT

This guide is oriented towards a medium- to large-scale effort

converting non-data base management systems (DBMS), business

applications. Since Federal system conversions range from very small to

very large and include other types of software such as DBMS, scientific,

modeling, and operating systems, managers may need to modify this guide

to apply to specific agency requirements.

1.2.3 LEVELS OF MANAGEMENT

There are essentially four levels of management involved or interested in software conversion.

o External Management - This management is at the

appropriations or approval level, e.g.. Office of

Management and Budget.

o Top Management - Internal management at the

department level exercising broad approval and policy,

and program roles.

o Technical - Middle management involved with

overall data processing, planning, and operations, e.g., manager of a data processing activity or ADP manager.

o Technical Supervision/Staff - That management

responsible for specific data processing operations, e.g., the supervisor of systems analysts and programmers.

This guide focuses on management activities at the technical

management and technical supervision/staff levels. These are the levels

where exceptional management skills must be applied to achieve

successful conversions.

This guide assumes a hypothetical agency structure (see

Figure 1-1).

o Top managers are those whose day-to-day interests concern overall agency functions and who exercise broad

approval and policy and program roles. Nevertheless

their support and understanding of software conversion

issues are important to the success of any conversion

1.2.4 AGENCY STRUCTURE

(18).

o Functional users are the users of agency information

system (e.g., personnel, finance). They assist in software

conversion, particularly in parallel testing.

4
o The ADP manager is the manager of all agency data

processing activities - both hardware and software.

o The hardware and operations manager is responsible for

day-to-day machine and communications operations.

o The software manager is responsible for day-to-day

applications, programs development and maintenance as well as systems programming. During software

conversion this manager has an added, paramount

interest in conversion activities. In the post-conversion

phase this manager also ensures that post conversion

plans and activities are accomplished. Thus, this

manager has a strong coordination function with the

conversion project manager.

o The conversion project manager is assigned full-time

during the software conversion process. After

conversion is completed the project manager returns to

normal duties associated with day-to-day

responsibilities. On a large conversion project there may

be a full-time project management team.

Many conversion problems result because of lack of

understanding of conversion management issues on the

part of upper level management. It is to a software

conversion mcmager's advantage to achieve as much

software conversion project visibility as possible in order

to effectively compete for management attention and

resources. In this regard the software conversion project

m€uiager has been placed directly under the ADP

manager in order to illustrate the need for high level

visibility.

1.3 HBTORY OF SOFTWARE CONVERSION

Software conversion is generally viewed in the Federal ADP

community as a traumatic and disruptive experience, to be avoided as

long as possible, endured when necessary, and forgotten as quickly as

possible. However, software conversions are common in the Federal

government Hardware systems are replaced on an average of every

seven to eight years (23). The information systems processed on this

hardware system commonly have a much longer life span, particularly

major applications supporting such functions as finance and accounting,

personnel, and payroll This means that conversion is a historical step

rather than an aberration in an information system's life cycle. If it is viewed «is a recurring, historical event, management practices can be

applied to improve conversion as they are applied to improve other

software processes in the life cycle.

5
COo ^ S =

Systems

Programming

Applications

Programming

—

ations 3mming

Applic

Progri

so c a CD ? CO 00

•o »-i CO

<D

C

CO £X CO O S 2O<Z<oozo>zou

ba<HbO

CO

DC 6
1.4 SOFTWARE CONVERSION IN THE INFORMATION SYSTEM

LIFECYCLE

The traditional and well understood model of an information

system's life cycle is depicted in FIPS PUB 38, Guidelines for

Documentation of Computer Programs and Automated Data Systems and

FIPS PUB 64, Guidelines for Documentation of Computer Programs and

Automated Data Systems for the Initiation Phase (22, 25) (see Figure 1-2).

If conversion is acknowledged as part of the information system's life

cycle, it couki be placed in the software life cycle's operations phase (see

Figure 1-3).

Examination of the activities or processes which constitute

software conversion reveals that there is a conversion life cycle imbedded

in the overall information system's life cycle. This software conversion

life cycle, itself, has distinct phases (see Figure 1-4).

o Project Initiation - The phase in which management

acknowledges software conversion is a distinct possibilty

in the near term. Managers determine if conversion

must be accomplished or if feasible alternatives exist

(e.g., improving the existing hardware system capacity,

shifting workload to another computer, or improving the

efficiency of existing software).

o Conversion Requirements - The phase in which, after

determining that conversion must be accomplished,

studies and analyses are conducted to identify all agency

conversion requirements and cost estimates in detaiL

o Conversion Planning - The phase in which conversion

details are translated into detailed conversion plans.

o Conversion Preparation - During this phase all

preparation activities leading to actual software

conversion, itself, are conducted.

o Conversion Process - The phase during which software is actually converted.

o Post Conversion - During this phase the conversion

project, per se, ends. Long-range planning is conducted

for the next conversion. Management also has the

opportunity to improve the next conversion by

implementing practices and measures which are conducive to efficient conversion. The later stages of

the post conversion phase eventually lead to the next

project initiation phase.

7
8
The phased approach of viewing software conversion provides

the structure for this guide. However, in an actual conversion many of

the activities associated with each phase proceed in parallel (see

Figure 1-5). For example, this guide treats planning as a phase although

planning is a continuous process. Likewise, while conversion requirements

are being developed, preparation activities can be ongoing. Similarly,

some software conversion may commence before preparations are

finished. The reader or user of this document is asked to keep in mind

that the sequential, or phased approach to this guide presentation must be

tempered with the understanding that different activities also proceed in

paralleL

1.5 PROJECT INrriATION PHASE

This is the phase in which management determines that

software conversion is a distinct possibility in the near term. A

conversion project manager is appointed and a small project team is assembled. A feasibility study is accomplished to determine if alternatives to conversion exist. If the most feasible alternative is procurement of new hardware, preliminary planning commences. In addition to the feasibility study other studies may be performed (e.g., to

satisfy the requirements of Office of Management and Bucket (0MB)

Circular A -76, Policies for Acquiring Commercial or Industrial Products

and Services for Government Use and 0MB Circular A-1 09, Major

Systems Acquisition).

There are two management pitfalls to avoid in this phase:

failure to appoint a full time project manager with the authority and

responsibility to complete the initial planning and manage the conversion

effort from start to finish, and failure to start studies and planning early.

Many conversion projects are delayed while inadequate plans are strengthened or experience slippages later in conversion due to planning

oversights.

Key top management decisions are appointment of a project

manager, approval of feasibility and other studies as required (e.g.,

OMB Circulars A-''6 and A-109).

9
10
1.6 CONVERSION REQUIREMENTS PHASE

After approval of the feasibility study, the project manager

and project team develop the details necessary to completely plan the

conversion. Alternatives to many conversion activities (e.g., choosing

specific automated conversion tools) (jje decided on a cost-effective

basis.

The project manager also develops a software conversion study

in this phase which is used to support an agency procui>ement request

(APR) submitted to the General Services Administration (GSA) for

hardware procurement. This study must be well constructed and carefully

costed. It is particularly important to examine software conversion costs

from a standpoint of converting to code compatible versus non-code

compatible hardware. Generally, cost avoidances can be high in a code-compatible conversion, but this approach must be fully justified and

supported.

In addition to the software conversion study, other studies

initiated in accordance with OMB Circulars A-76 and A-109 may be

ongoing and require input.

It is important to address security and privacy requirements in

this phase. These tend to be overlooi<ed from a systems standpoint but

are extremely important. Incorp>orating security and privacy features into

software during conversion is relatively straightforward if considered and

planned well in advance.

The major maneigement issue in this phase is maintaining

continuity of the project manager and project team to allow them to

develop the software conversion study and the details necessary for

thorough planning.

The key management decision is approval of the software

conversion study.

1.7 CONVERSION PLANNING PHASE

As the detailed requirements are developed, they are converted into conversion plans to support staffing, acquiring conversion

contractor support, locating the conversion project team, acquiring

necessary conversion facilities such as terminals, training, and

accomplishing the actual conversion. Tracking mechanisms are also

developed to keep management apprised of conversion progress. If a fully

competitive hardware selection is in progress, planning must remain

flexible until the target hardware is known. The conversion project

manager maintains close coordination with agency personnel involved in

hardware acquisition in order to gain early insight of planning impacts

stemming from acquisition decisions.

The key management decision in the conversion planning phase

is approval of all conversion plans necessary to complete the conve^v^on.

11
1.8 CONVERSION PREPARATION PHASE

After conversion plans are developed, preparations are made

for concentrated conversion of software. Preparations should be

complete prior to conversion to preclude interruptions and wasted effort.

Major preparation activities include assembling and training the

conversion team, developing or obtaining conversion tools, installing

equipment, obtaining conversion facilities, developing test data and

contracting for conversion support. Tracking of conversion preparation

plans ensures that schedules are met.

A major management concern in the conversion preparation

phase is dealing with unforeseen problems such as unanticipated personnel

losses and outside impacts such as budget cuts. Plans must remain

flexible to accommodate these problems.

The key management decision in this phase is approval to

proceed with the conversion.

1.9 CONVERSION PHASE

During this phase software is converted. Unit, system and

parallel testing is conducted and operational systems are accepted by the

information system users.

The critical management issues are dealing with unforeseen

problems to keep the conversion on track, monitoring contractor

performance for compliance with Statements of Work and ensuring that

established agency software standards are met and documentation is produced.

The conversion phase ends when the last converted system is accepted by the functional user. A key management decision in this phase

deals with accepting software which may not have completed parallel

testing (e.g., it may not be practical to parallel test year-end reporting).

Considerable risk is removed if the agency has developed and maintained

good test data, and unit and systems tests have been successfuL

1.10 POST CONVERSION PHASE

The first activities of the post-conversion phase involve

disbanding the conversion project team and reorganizing the agency

software operations into a normal, day-to-day environment. The project

manager should conduct a post-conversion study and assess and record the

entire conversion experience. Completion of activities to settle the staff

in a normal software environment and the post-conversion analysis and

assessment complete the conversion project. This post-conversion

analysis and assessment has much utility in that it provides a historical

reference of lessons learned, that may be applied in future conversions. It also facilitates planning for the next conversion. This planning should

begin immediately and should continue until the next conversion.

12
In addition to planning, agency software standards should be

enforced during the post conversion phase. Use of these standards will

make the next conversion easier. Software security and privacy

requirements, applied in a routine systematic fashion, will reduce the

chance for oversight in a crisis conversion environment.

The critical management issues in post conversion are completing the post conversion analysis and assessment, developir^ and

maintaining conversion planning, and ensuring that software is developed

and maintained to high technical standards.

The key management decision in the post conversion phase is approving the post-conversion plan. This terminates the conversion

project.

1.11 APPENDICES

The remainder of this guide follows the phases of the

conversion life cycle presented above. Appendices to the guide include:

BIBLIOGRAPHY

Appendix A is the bibliography which was used in developing

this g^ide.

CONVERSION DIRECTIVES STANDARDS AND REFERENCES

Appendix B contains a list of directives and references that are applicable to software conversion. They are recommended to be part

of any software conversion manager's library.

SOFTWARE CONVERSION COSTING

Appendix C contains a costing methodology that managers can

use to develop software conversion cost estimates. It can be used in the

feasibility study during the project initiation phase, the software

conversion study to support the agency procurement request, agency

budgets, and to support any other cost requirements.

CASE STUDIES

Appendix D contains software case studies that were

developed from actual c^ency experiences. They provide additional

insight into software conversion's management issues.

GLOSSARY

Appendix E contains a glossary of terms used in this guide.

13
SECTION 2

PROJECT INITIATION PHASE

A point is reached in every information system's life cycle

where conversion is considered in detaiL The causes of conversion vary

but are usually related to a real or perceived need to replace hardware.

Eventually managers realize that software conversion is no longer an

event to be faced at some undetermined time in the distant future, but a

condition that is likely to occur and that requires initial but definitive

consideration and planning.

Prior to any extensive commitment of resources to support a

full scale software conversion, a feasibility study is required by General

Services Administration 41 CFR Part 1-4 , to firmly establish the need for a conversion effort. There may be viable alternatives to a conversion,

such as keeping the present computer system running for longer periods of

time (e.g., 3rd shift, weekends), reducing the workload by identifying and

cutting nonessential processing, or distributing some of the workload to other computers.

In addition to providing decisive information on whether or not

a conversion is necessary, preliminary plannir^ provides management

early insight on the magnitude, direction, resource requirements, and cost

of the software conversion project.

The time associated with project initiation activities,

especially the planning, the estimating and statistical development, and

conduct of the feasibility study should not be underestimated. Two to

three person years of effort over six months could be required for a medium to large scale conversion.

A positive attitude toward conversion siiould be developed in

the software staff. Rather than viewing conversion as a disruptive

process, conversion can be approached as professionally challenging, an

opportunity to broaden professional skills, and to exercise initiative in a dynamic environment. Conversion also offers an opportunity to upgrade

the status of agency software to high technical standards. For example,

old inefficient programs can be rewritten in standard languages using

modern software engineering techniques. Documentation can be updated

and made current. Unnecessary or outdated code can be eliminated.

2.1 REASONS FOR CONVERSION

There are many reasons for software conversion. Each reason

has different effects on agency software conversion processes and

management involvement.

14
o Hardware Processing Limits: Computer systems'

saturation is the normal cause of software conversion.

Hardware systems are commonly installed and

continually upgraded to accommodate fi^ency

information systems as they are designed, implemented

and enhanced. Eventually the point is reached where the

hardware capacity for expansion no longer exists,

information systems no longer are responsive to

functional user needs, and little or no hardware

resources are available for new application program

development. In unusual cases, primarily due to poor

plannir^, hardware systems upon installation, are expanded to capacity in a matter of months. Commonly,

however, hardware systems last approximately eight

years before capacity limitations cause replacement. In the normal case, software managers ^ould be able to

anticipate conversion well in advance through analysis of

trends and have ample time to take all actions necessary

to initiate conversion in an orderly fashion.

o Change in Missions and Functions; Federal agencies

operate in a dynamic environment. Missions and

functions can change as a result of new Federal laws and

programs, and as a result of agency consolidations and

reorganizations. As established agencies gain additional

missions and functions, their information requirements

increase. These increased information requirements

result in new demands for information systems which

ultimately lead to hardware saturation. However, in the case of hardware saturation caused by mission and

function changes, conversion can be precipitated in a much more dramatic and Sorter time frame than as a

result of saturation due to normal systems growth. Thus,

when mission and functions change, software managers

usually have less time to initiate software conversion

projects.

o Operational Requirements: Retaining existing

application system software may no longer be

operationally viable. For example, vendor software may

no longer be supported by the vendor. The existing

software, without vendor maintenance support, may not

be useful for new systems development and existing

system enhancements. Rather than retain obsolete,

unsupported software for some systems and introduce

new software for new systems, with attendent

requirements for increased and different training and

documentation, agencies may convert all software to a

viable language. Another example of conversion caused

by operational requirements has to do with old software

15
running in an emulation mode. Long-term emulation

processing is generally inefficient for software that is frequently used. Managers may decide from a cost

effective, as well as operational standpoint, to convert

software running in an emulation mode.

o Technology: Some Federal computer systems do not

become saturated and are useful for many years.

Eventually, however, their age or lack of technological

sophistication dictate their replacement. Vendors or manufacturers eventually discontinue maintenance and

other support to old hardware. In other cases, even

though support is still available, operating costs

associated with operations' staff, power, and air

conditioning may be unacceptable. Modem hardware and

software may support the same functional applications

at considerably reduced operational cost.

2JZ PROJECT INITIATION OBJECTIVE

The objective of the project initiation phase is to conduct the

preliminary planning and studies to determine whether a conversion should

be undertaken.

2.3 PROJECT INITIATION ACTIVrriES

The following activities occur durii^ the project initiation

phase (see Figure 2-1):

o Project manager appointment and project team

establishment,

o Information system user and top management interface,

o Project reporting and control,

o Preliminary planning and estimating,

o Accompli^ing a feasability study and cost analysis,

o Management decisions.

2.4 PROJECT MANAGEMENT APPOINTMENT AND PROJECT

TEAM ESTABLBUMENT

Of prime importance to a successful conversion is the

appointment of a project manager with the requisite technical/managerial

background and the tenure and authority to manage the conversion

project. Concurrently, a project team should be formed with the skills

and experience necessary to accomplish the studies and analyses

associated with the project initiation phase.

16
PROJECT MANAGEMENT APPOINTMENT

PROJECT TEAM APPOINTMENT

USER & MANAGEMENT INTERFACE

REPORTING & CONTROL

ESTABLISHMENT

PRELIMINARY PLANNING

FEASIBILITY STUDY PREPARATION

MANAGEMENT DECISION T

PROJECT INITIATION PHASE ACTIVITIES

Figure 2-1

17
The establishment of the project manager and project team

should include provisions for adequate logistical and administrative

support and a sufficient operational budget.

To be effective, there should be a separation between previous

responsibilities and the conversion effort. The project team, as a unit,

should work in a separate physical location. This location will serve as the focal point for the conversion. Distractions and interruptions will

then be minimized, allowii^ the team to concentrate on the conversion

activities.

The appointment of the project manager and project team

usually signifies the beginnir^ of software conversion cost expenditures.

At this point direct costs can be identified to a particular project. Also,

the assignment of a project manager is accompanied by accountability for

project cost as part of the management responsibilities.

2.4.1 PROJECT MANAGER APPOINTMENTS

A full time project manager should be selected and apT^ointed

who will have experience and tenure to manage software conversion from

project initiation to project completion. While this may appear self

evident, a sigfnificant number of Federal conversion projects have

experienced difficulties because:

o Conversion project management duties were assumed as additional responsibilities by fully committed software

stfiff members.

o Project management was not exercised continuously

through the different conversion phases. This lack of

continuity disrupted and impeded conversion.

The qualifications to be considered in selecting a project

manager should include:

o Planning ability,

o Ability to organize and manage resources,

o Project management and software conversion experience

- Six to ten years of experience is recommended,

o Ability to deal effectively with people, particularly

personnel in agency elements external to ADP, such as the functional users of information systems,

o Ability to react to problems and redirect efforts to

resolve issues before they get out of hand.

18
While conversions should have only one project manager, it is conceivable that very large conversions might have a full-time project

management team appointed for the duration of the project.

The project manager *ould be formally appointed and

chartered in writing. The appointment should be approved by top agency

officials. This provides project visibility and acknowledgement that the

project manager has the authority to receive support and assistance from

other organizational elements within the agency.

2.4.2 PROJECT TEAM ESTABLISHMENT

The composition of the project team for this phase will depend

upon several variables, which include project complexity, timeframe,

budgetary and personnel constraints.

Since project initiation activities are planning oriented, the

project team should include one or more systems analyst(s), with three

years minimum analytical and planning experience preferred. Team

members must be familiar with the current ADP environment and

applications, and be able to collect and evaluate workload statistics.

Preference should go to selecting those personnel with previous

conversion experience. Although the team during this phase may be very

small, additional members can be added or reassigned as needs arise.

Many managers use their most experienced personnel to assist in project

initiation activities and continue to employ them in other subsequent,

conversion activities.

2.5 INFORMATION SYSTEM USER AND TOP MANAGEMENT

INTERFACE

Software conversion can be a lengthy and complex process

dealing with an important tigency asset — its information base. Software

conversion alters this data base. Problem-ridden conversions can result in

considerable harm to an agency and its operations. Conversely, efficient

conversions can improve the information processing posture of an agency.

Therefore, it is extremely important that the functional users of

automated information systems and top agency executives understand the

issues of software conversion and support the conversion effort.

Experience has shown, however, that full functional user and top

management understanding and support are frequently not achieved. To overcome this, at project initiation, the project manager

can employ a variety of techniques to develop and maintain user's and

management's interest and involvement in the conversion effort. These

include:

19
o Briefings. Scheduled briefings are recommended to keep

users and top agency executives apprised of project

initiation activities. These briefings need not be formaL

Short presentations as part of staff meeting agendas can

be quite effective, especially since these meetings

provide an opportunity to inform many managers and

executives at one time of the conversion project status.

Such briefings are of particular importance to top

management. During the project initiation phase,

agency executives will decide on conversion as a result

of a feasibility study developed by the project manager

and the project team. Regular briefings reduce the

chance of surfacing surprises in the feasibility study, a

point appreciated by management. Study issues can be

raised well in advance for executive level attention.

Once scheduled briefings are established, they should be

continued throughout the conversion effort until the

project is complete.

o Memoranda. Informal memoranda with general

information of ongoir^ and planned activities might be

employed.

o Management Staff Involvement. If it is difficult to

directly inform top level managers of progress, it may be

possible to inform or involve subordinate members of

his/her staff who have immediate access and are charged

with keeping top level managers informed of significant

issues or potential problem areas.

o Articles in Agency Newsletters. Frequent but short

articles can keep top managers and users informed of the

software conversion project.

2.6 PROJECT REPORTING AND CONTROLS

Effective reportir^ and controls must be established and

adhered to during a software conversion. Without some mechanism for

accounting for work in progress, work completed, and work to be started,

the project manager will have great difficulty in project tracking and

monitoring.

2.6.1 REPORTING

At project initiation, reporting procedures can either be

separate from, or merged with, other on-going, related actions (e.g.,

hardware replacement). These procedures should provide reports required

by the project manager as well as higher levels of management. The

initial framework for internal and external reporting should be formulated

for the entire conversion effort.

20
2.6.2 PROJECT HISTORY

A project history should also be started during the project

initiation phase. Thereafter it should be maintained by the project

manager throughout the entire software conversion effort. The history

should reflect significant project actions, events, costs, problems and

means of problem resolution. It should also contain thoughts and

observations of how subsequent project activities or future conversions can be improved. This history can be recOTded in a journal or 1<^ or be

contained in a project reference file. Ultimately the history log, if maintained, will be an invaluable reference in developing conversion plans

and a post conversion analysis and assessment.

2.6.3 PLANNING AIDS

Project planning aids exist and include PERT, GANTT, and

Work Breakdown Structures (WBS). Project planning aids selected for use

are largely a matter of individual preference on the part of a project

manager. However, at a minimum it is recommended that some visual,

time d^endent, planning aid ^ch as bar charts be used. Although bar

charts do not depict a critical path, they identify concurrent activities to

alert the project manager of resource constraining areas that require

special attention. They also visually portray starting and ending points of

project activities and important milestones.

2.7 PRELIMINARY PLANNING

Adequate ADP project planning is one of the most critical

factors of a successful software conversion. Federal procurement

regulations require a feasibility study to be accomplished before any

conversion to determine if other alternatives can resolve an agencies'

information processing problems.

Additionally, other related studies are often required in the

same approximate time frame as the feasibility study. Software

conversion results in a change to agency operations. 0MB Circular A-76,

Policies for Acquiring Commercial or Industrial Products and Services for

Government Use, requires examination of ADP operations at a time of

significant change to determine if (derations can be effectively turned over to a contractor. Also, an agency may consider hardware

replacement and software conversion to fall under the provisions of 0MB

Circular A-109, Maior Systems Acquisition. The project manager must

have the planning and statistical base to accomplish the feasibility study

or provide input into these other related conversion studies, as required.

Unfortunately, software conversion preliminary planning is

frequently postponed to a point where it has an adverse effect on

conversion schedules, or is conducted inadequately and without sufficient

detail, ultimately leading to project slippage. To overcome this

management issue and to provide a firm foundation for the feasibility

study and other related studies for which input might be required, early

21
preliminary plans should be developed to provide managers insight into the

probable magnitude of the conversion project, gross resource requirements and the probable length of time conversion will take. This can be accomplished byJ

o Current procurement and acquisition regulations and

policy review,

o Current ADP hardware and system software inventory,

o Preliminary systems and applications program inventory,

o Data file inventory,

o Preliminary workload estimation,

o Levels of effort and resource estimation,

o Preconversion/conversion cost methodology

development.

These activities accomplished by the project team during

project initiation will provide a statistical and planning base for aU

subsequent conversion phases and activities.

2.7.1 CURRENT PROCUREMENT AND ACQUISITION

REGULATIONS AND POLICY REVIEW

Along with agency policy regulations, there are many

pertinent Federal procurement regulations and directives promulgated by

GSA, OMB and Congress, as well as standards and guidelines promulgated

by the National Bureau of Standards, that pertain to software conversion.

The project manager and the project team should review this pertinent

documentation. Of particular importance are the following three areas addressed by these documents:

o Hardware/software planning and acquisition, o Software conversion, o Timesharing and remote computing services.

Appendix B to this guide contains the most important

references that will assist in policy and regulation review.

2.7.2 CURRENT ADP HARDWARE AND SYSTEM SOFTWARE

INVENTORY

The purpose of this activity is to document all currently

existing ADP equipment and system software in order to establish the

current environment, and identify any potential vendor's unique problems

if converting the application programs to noncompatible, target hardware

is necessary.

22
2.7.2.1 Hardware Inventory

A hardware inventory is necessary to understand the

environment in which the software operates. Also, costs associated with

hardware influence software feasibility studies. The project manager or the project team will be furnished the hardware inventory by the

hardware staff. If not, the project team will have to establish it. The

hardware inventory and equipment configuration should describe and

display all ADPE components and peripherals, located either on-site or at

remote locations. At a minimum, this inventory should identify each

component by:

o Component name,

o Model number,

o Name of manufacturer,

o Location.

Although primarily focusing on computer center equipment,

such as CPU, disk components, tape drives, printers, card reader/punch,

and consoles, the inventory should also include such items as RJ£ stations,

graphics equipment, data entry equipment, and other user-oriented

hardware. Memory and storage capacity should also be identified.

Additionally, an inventory of all commmunications equipment and network

configurations should be acquired if data communications are employed.

2.7.2.2 System Software Inventory

The system's software inventory must encompass not only the

operating system, languages, compilers, link editors, spooling and

teleprocessing software, but also identify and describe utilities, software

and hardware monitoring packages. The software inventory ^ould include

at a minimum:

o Name of software or language,

o Product number,

o Manufacturer,

o Version, o Release/level number,

o Version/release date, o Date installed, o Local modifications,

o Documentation available, location, and condition,

o System software lease, purchase or cost information.

Care must be taken to document special conditions such as user exits and local modifications, where present.

23
The software inventory will be relatively straightforward if current system software documentation has been maintained. Where

little or no documentation exists, the problem is magnified, but the

inventory can and must be accomplished To develop communications

between the project team and the system programming staff, and to

develop familiarity with systems software, it is recommended that one or two system program mmers temporarily augment the project team and

provide systems software data.

2.7.3 PRELIMINARY SYSTEMS AND APPLICATION PROGRAMS

INVENTORY

A preliminary inventory of application programs and systems

currently in use serves a number of purposes:

o This inventory is required to estimate the magnitude of

the conversion.

o It serves as a starting point in identifying those programs

and applications that should be converted, if a

conversion is approved. A more comprehensive and

ind^th inventory is undertaken once the conversion

requirement phase starts.

o Should a conversion not be justified as a result of a

feasibility study, the inventory will serve as baseline

documentation by the ADP staff during any future

conversion studies.

The application program inventory is facilitated if one or more

of the team members are familiar with the applications. Additional and

supplemental information can be obtained from user groups.

The inventory ^ould include at least the following

infOTmation:

o Name of system and brief description,

o Numbers and programs within the system; lines of code

per program and language; complexity of programming,

o Interfaces with other systems,

o Data bases accessed by the system.

While extreme levels of applications software detail are not

required for project initiation activities, as much additional detail as

possible should be devel(^d, resources permitting. This will save time

later, during the software conversion study conducted during the

conversion requirements phase, when more extensive details are needed.

Cognizant functional users should review and verify the

inventory and identify any applications that may have been missed.

24
2.7.4 DATA FILE INVENTORY

The project team should identify and document data files that are generated and processed by each program, and files that are shared by

multiple programs and systems. This inventory contributes to the

determination of the scale and complexity of the current software

environment. The inventory is accomplished by one or more members of

the project team through review of current program/system

documentation, developed from workload statistical data and, where

necessary, interviewing the appropriate users (39).

The inventory should include at least the following

information:

o File name.

o Accessing system(s) name(s),

o Medium (i.e. tape, disk, cards, etc.),

o Data organization (e.g. sequential, random, indexed,

etc.),

o Code (e.g. BCD, EBCDIC, ASCII, etc.),

o Estimated size.

2.7.5 PRELIMINARY WORKLOAD ESTIMATION

Summary statistics are then developed to reflect the basic

total system workload (e.g., percent CPU busy, mean turnaround, number

of jobs processed, etc.) and a profile established of future workload

requirements. Since time is relatively limited during this phase, resource estimates should be based primarily on available or easily derived data.

Most workload data is usually available from system operating statistics

(e.g. IBM System maintenance Facility, "SMF") and accounting, billing

and history data. The accumulation and summarization of detailed, resource workloads from hardware/software monitors is usually too time

consuming at this point in conversion planning. However, some

consideration should begin regarding methods to develop a more extensive

assessment and collection of workload data which is required in the

conversion requirements phase.

2.7.6 LEVELS OF EFFORT AND RESOURCE ESTIMATION

Personnel requirements are identified for each conversion

activity and levels of effort are estimated for the entire software

conversion project. While there are many methods for estimating

resources, a common software conversion management method is judgement based upon experience. The intent of this guide is not to

25
develop or recommend a particular estimating technique or methodology,

but rather to identify various techniques or methodologies that will lead

to reliable estimates. Appendix C describes and discusses in detail two

popular estimation techniques, which include the Navy's PMCS model and

the Federal Conversion Support Center's Hybrid Model (45). These should

be assessed first before any other models are considered.

2.7.7 DEVELOPING PRECQNVERSION/CQNVERSION COST

METHODOLOGY

A software conversion cost methodology is described in detail

in Appendix C. A methodology should be adopted or developed durir^

project initiation to provide a consistent basis for cost decisions

throughout the project as well as for the feasibility study required during

this phase. This cost methodology will be refined during the project as more detail is developed and more accurate cost estimates can be

prepared. The cost methodology must be used to track project costs. In

this manner, the software conversion cost methodology can assist project

management by:

o Providing the ability to audit cost estimates,

o Identifying the major cost related efforts,

o Providing a consistent cost information base for

recording and projecting software conversion costs.

2.8 ACCOMPL6HING THE FEASIBILITY STUDY AND COST

ANALYSIS

The purpose of the preliminary feasibility study and cost

analysis is to determine if there are alternatives to software conversion

and provide top management with adequate decision-making information.

The study will be developed by the project manager and project team. If study input is readily available, it should take approximately two months

to complete. This study, to be effective, must address:

0 The objectives, assumptions, constraints, and background

of the current environment,

o The background and status of the current system(s),

o Projected or anticipated future requirements,

0 Identification of alternative approaches,

o A summary of findings and recommendation(s) along with

supporting costs/benefits/risks analysis.

26
Unless there are agency standards, it is suggested that FIPS

PUB 64 be used as a guideline in completing the feasibility study and cost

analysis (22). The following discussion is derived from that reference.

Figure 2-2 shows the relationship of the various activities of the

feasibility study which are:

o Define Objectives. Scope, and Background

This is the first step in a feasibility study and is to

define the objectives and scope of effort.

o Identify and Define the Current System

The second step is to define the existing environment,

organization, constraints, priorities, and technical and

operational (workload) considerations on which this study

is based.

o Identify Alternatives

This is the key stage where creative and intuitive

thinking are employed. Viable alternatives and solutions are identified and described.

Besides the status quo, possible alternatives might

include increasing the hours of computer system

operation, reducing non-essential or non-productive

work, distributive processing, or conversion to larger

hardware.

o Assess Technical and Operational Feasibility

The technical and operational feasibility (i.e., satisfying user requirements) of each alternative is assessed to

determine if they are suitable technologically and

operationally.

o Estimate Costs of Alternatives

AH relevant costs (i.e., recurring, and non-recurring and

present value) of each alternative must be estimated.

Cost estimates developed using the software conversion

costing methodology should be based on the full cost of

each alternative, and defined in sufficient detail to allow

cost comparisons of individual elements of cost among

alternatives.

27
Define

Objectives

,

Scope, & Background

Identify

& Define

the Current

em

Estimate

Costs of

Al ternatives

IZZ

Identify

AT ternatives

Assess

Technical

& Operational

Feasibil ity

Define

& Describe

Benefit

Compare

Al ternatives

Analyze

Sensitivity

& Risk

Recommen

Impl emen

PI

dation & tation

an

Prepare & Finalize Feasibility Study

Figure 2-2

28
Define and Describe Benefits

Identify and define any quantifiable and non-quantifiable

benefits or their estimated values for each alternative.

Do not overlook the intangible benefits. While these

may be more difficult to estimate or assign values, in

many cases they may carry more weight in the final

analysis and decision-makir^. These costs are

reflected in each alternative, including the status quo

alternative. Care must be taken to avoid double

counting of costs or benefits.

Compare the Alternatives

Compare the feasibility of each alternative in terms of

desirability and advantages/disadvantages. The

comparison is based upon the technical, cost and

operational factors identified above.

Analyze Sensitivity and Risk

A useful tool in feasibility studies, is sensitivity analysis

which is a method few determining the impact of changes

in assumptions on the total cost of the alternatives.

Sensitivity analysis should address the range of values

for assumptions such as workload, inflation factors,

salaries, number of programs, complexity and conversion

productivity. In this manner the least cost alternatives can be identified for any given range of assumption

values and used with risk analysis to determine the

preferred alternative.

Recommendation and Implementation Plan

At this point, based upon the various cost/benefit and

sensitivity analysis results, a recommendation or summary of findings is prepared, along with a proposed

schedule for implementation.

Finalize Feasibility Study

When prepared objectively and with adequate

information, the feasibility study will provide

management with the necessary data to make a decision as to the proposed recommendation.

29
2.9 PROJECT INITIATION BIANAGEBiENT DECBIONS

At the conclusion of the feasibility study and cost analysis, the ADP

manager presents study results to top management for decisions. If there

is no feasible alternative to resolve the agency data processing problem

other than software conversion, management will likely be faced with

another large issue: hardware replacement.

Once the software conversion decision is made, additional

management decisions are required to support:

o Software conversion resources, o An extended conversion schedule, o Authority to begin the conversion requirements phase, o Project fundii^.

It is recommended that the project manager present a decision

briefir^ to top management and cover all decision requirements and

recommendations as an entire package. This provides for efficient

transition to subsequent software conversion phases.

If software conversion is not selected as a feasible alternative,

project personnnel revert to normal operational roles. Care should be

taken to preserve the results of all project initiation phase, statistical

data and study results since this will prove useful in any future conversion

planning.

2.10 ECONOMIC CONSIDERATIONS

During the project initiation phase, personnel will be the

largest cost component. Included in this cost could be significant

expenses required for establi^ing the project team including new hire or relocation expenses, initial project training courses, and office set-up

expenses.

The software conversion cost methodology described in Appendix C should be initiated during this phase. A cost structure should

be developed that represents the characteristics of the environment being

costed and contain a level of detail that is sufficient to provide cost

information for management use in the succeeding phases. The cost

estimates developed during this phase will be based on summary levels of

cost detail and may be provided through the use of software conversion

cost estimation models, two of which are described in Appendix C.

2.11 PROJECT INITIATION MANAGEMENT CHECKUST

o Appointment of full time project manager

o Charter approved by top management

o Ongoing project costs tracked

30
Project team established

Top management and information system user interfaces

established

Interface with hardware acquisition project members

established

Project reporting and project controls established

Regular reporting in progress

History log established

Planning aids selected and used

Impact of Related Studies Determined

A-76

A-109

Other

Applicable acquisition and procurement, policy

regulations and directives that affect software

conversion identified and reviewed

Hardware inventory conducted

System software inventory conducted

Data files inventoried

Preliminary workloads estimated

Conversion resources (personnel) estimated

Cost methodology developed

Project costs tracked

Feasibility study and cost analysis conducted

Management decision to proceed/not proceed with

conversion

Reorient efforts to proceed to next conversion

phase

Plan for and pursue efforts to accomplish other

alternative(s)

31
SECTION 3

CONVERSION REQUIREMENTS PHASE

The conversion requirements phase results in detailed

identification and assessment of the scope, requirements, and

complexities of the conversion effort. This phase is the transition

between "what" is to be done (project initiation) and "how" it is to be

accomplished (conversion planning).

Once the decision to convert has been made, the conversion

project team must identify all of the details necessary to plan and

execute the conversion. This requires an analysis of the current

environment to include identifying feasible alternatives to various

conversion processes and activities. Management decisions can then be

made to choose the most cost effective method of accompli^ing the

conversion activities. In addition to the planning details, during the

requirements phase a software conversion study is required to determine

if the users needs are met at the lowest overall cost (13).

During the conversion requirements phase, the hardware

procurement activities are interrelated and dependent on software

conversion activities. For example, workload analysis is used to determine the magnitude of the software conversion project. Workload

analysis also serves to help size the target hardware needs. Most

importantly, the software conversion study, with its supporting cost

analyses can identify procurement options which differ considerably in

cost and time to implement. The software conversion study should

address conversion to code-compatible as well as none ode-compatible

hardware and the respective costs and operational impacts carefully

developed. Code-compatible conversions are usually much less costly and

disruptive to agency operations. While approval of code-compatible

) conversions cannot be guaranteed due to Federal competetive

procurement policies, the likelihood is improved if code-compatible

conversion hardware procurement requests are supported by reliable and

thorough cost analyses.

3.1 REQUIREMENTS PHASE OBJECTIVES

The primary objective of this phase is to provide the

information necessary to accomplish detailed conversion planning. An

additional objective of this phase is accomplishment of a software

conversion study which, in turn, supports preparation and submission of an Agency Procurement Request (APR) to the General Services

Administration.

32
3^ CONVERSION REQUIREMENTS ACTIVITIES

The following conversion requests phase activities (shown in

Figure 3-1) must be conducted:

o Project team staffing and organization,

o Application systems and programs inventory extension

and assessment,

o Data file inventory extension and assessment,

o Conversion tool identification and selection,

o Workload estimation and refinement,

o Distributed and teleprocessing requirements definition,

o Systems software requirements definition,

o Personnel requirements definition,

o Security requirements definition,

o Conversion facilities requirements definition,

o Software conversion study preparation.

The full-time project manager appointed during project

initiation will continue to manage the conversion project during the

requirements phase. The project team requires systems analysis skills

and planning experience to develop requirements; the same skill base

needed for project initiation. Since requirements definition and

development of the software conversion study are analogous to activities

in project initiation, the same team members should be adequate except

for very large conversions. As a guideline however the following table is offered to aid in team staffing:

3^ PROJECT TEAM STAFFING AND ORGANIZATION

3.3.1 PROJECT TEAM STAFFING

Lines of Code

To be Converted Team Size

Less than 100 K

100 K to 500 K

over 500 K

1-2

4-5

33
TEAM STAFFING & ORGANIZATION

APPLICATION SYSTEMS INVENTORY

DATA FILE INVENTORY

CONVERSION TOOL SELECTION

WORKLOAD ESTIMATION

TELEPROCESSING REQUIREMENTS DEFINITION

SYSTEMS SOFTWARE REQUIREMENTS DEFINITION

PERSONNEL REQUIREMENTS DEFINITION

SECURITY REQUIREMENTS DEFINITION

FACILITY REQUIREMENTS DEFINITION

SOFTWARE CONVERSION STUDY PREPARATION

MANAGEMENT DECISION T

CONVERSION REQUIREMENTS PHASE ACTIVITIES

Figure 3-1

34
These figures are derived, in part, from an Army estimate (39)

and from case studies described in Appendix D.

During the requirements phase the project team might be

augmented by consultants, by guidance provided by the Institute for

Computer Sciences and Technology (ICST), or by support from the Federal

Conversion Support Center* to assist in developing special requirements

such as security and teleprocessing or to accomplish the software

conversion study.

3.3.2 TURNOVER CONSIDERATIONS

A key issue that management should anticipate, and plan for,

is personnel turnover. The longer the project, the higher the turnover

rate. According to Tripp and Wahi (34), multi-year projects should plan for

up to 25% turnover in staff per year. The implications of this apply to

lengthy requirements phases as well as entire conversion projects.

Managers must be prepared to replace project team personnel and possibly

project managers.

Problems in turnover may be reduced by team organization

and assignment of duties. Primary responsibilities for conversion

requirements can be assigned to individual team members. Other team

members should be assigned secondary or back-up responsibilities. If one member leaves unexpectedly, the corporate project memory is not lost.

Regularly conducted project discussions and reviews to keep

all team members apprised of project status also contribute significantly

to reducir^ the effect of project team personnel losses.

3.4 APPLICATION SYSTEMS AND PROGRAMS INVENTORY

EXTENSION

The purpose of this activity is to extend the application

system and project inventory conducted during the project initiation phase.

The details of the systems and programs in terms of complexity and

construction are added to the inventory.

This inventory will also identify specific systems and programs

to be converted or dropped. The inventory will permit the project team

to group and assess the agency application software inventory from

various perspectives. For example, the inventory can be considered from

a standpoint of complexity, applicable conversion technique (e.g.,

automated tool, line-for-line coding, etc.), or lar^age. Estimating of

Federal Conversion Support Center

Software Development Office

General Services Administration

Two Skyline Place, Suite 1100

Falls Church, Virginia 22041

35
levels of effort and identification of the best techniques to accomplish

ct^nversion are considerably aided by this inventory. Additionally, the

project team will develop insight into many potential conversion problems

and means to accomplish problem resolution.

Catalog worksheets printed on large paper will assist the

project team in inventorying and assessing application software. For very

large conversions it is recommended that this worksheet be automated.

Automation will assist the project team in easily analyzir^ the software

inventory from various aggregate perspectives (e.g. language, lines of

code, environment, or complexity). The following information

corresponds to a suggested worksheet (Figure 3-2) developed from Federal

sources (39, 47). It should be modified according to specific agency needs.

o PROGRAM ID ; Specify a unique identifier for each

prc^ram.

o SOURCE LANGUAGE & VERSION; Specify the programming language and version in which the current

program is written.

o LINES OF CODE; Enter the number of lines of code in

the program. Indicate number of vendor extensions, if known.

o MODULES AND EXTERNAL CALLS; Specify the

number of segments, calls to external subroutines, and

macros which are copied.

o COMMUNICATION INTERFACES; If the program interfaces with communication drivers or special telecommunication interfaces, indicate interface name and

function, e.g., 3270 protocol/screen format.

o SOURCE PROCESSING ENVIRONMENT; Specify the

mode of processing such as batch, remote job entry

(RJE), interactive, or real-time for the source program.

o FILES ; Specify the name and number of input, output and

input/output files processed by this program. Temporary

files should not be included.

o DOCUMENTATION; Indicate the level of documentation

available for this program using the foUowir^ codes;

0 = None available; 1 = Insufficient for conversion;

2 = Satisfactory.

o COMPLEXITY; Specify the code that best reflects the

level of prc^ram complexity. Refer to Figure -3.

o TARGET LANGUAGE AND VERSION; Specify expected

language and version if target hardware is known.

36
J»c

Oi «

0. a

H

ean

X

GO

cso

»o

o

<

<

u

>•s

o

H

Z

H

Z

z

<

s

o

o

K

1

C

B

* c

O 0)

a o < w

O

U

S

e

ea

s 3. 5 I

U3

O H

u

o

Q

> I

CO o 2 1

^

o

. o

a S o z u c

GOa

o

CB 3 t-i ee o C >

1^

5 <3 S

CD|a

0.

O

37
Complexity Factors A B C D

Language

ANSI FORT.,

ANSI PLI,

ANSI BASIC

COBOL

BASIC, other

high level

High Level

w/some

Assembler Assembly

Structured Design Extensive Moderate Some None

Lines of Code Less than

500

500- 999 999 -2K Over 2K

Number of External

Calls Used Less than 4 4-8 9-15 Over 15 Number of Segmentation

Overlap Routines Less than 5 5-9 10-20 Over 20

Operating Environment Batch Batch with

RJE

On-Line ^eal-time

Embedded Documentation Extensive Moderate Some None

Access Method Sequential Index Seq. Direct Access Other

Number of Data Files Less than 5 5-7 8-1 1 Over 1 1

No. of Control Stream

Language Statements Less than 5 5-10 1 1-25 Over 25

Number of Utilities to be Converted Less than 3 3-5 6-10 Over 10

Complexity Code

A+B+C+D

// X 1 = A =

X X 2 =

B =

// X 3 = C =

# X4 = D = LEGEND

up to \k Simple (1

)

15 to 24 Average (2) 25 to 30 Complex (3) 31 to 40 Verv Complex (4)

COMPLEXITY TABLE

Figure 3-3

38
o TARGET PROCESSING ENVIRONMENT; Indicate

whether the target program processing environment will

be batch, remote job entry (RJE), interactive, or realtime.

o COMMENTS; Enter any comments or information such

as justification, primary user contact, regulatory authorization, etc. If one or more automated tooKs) is applicable, enter name of package, if known.

o CONVERSION STATUS; Indicate the action to be taken

for this program. C = Convert; P = Purge;

R = Redevelop.

Other statistics which should be summarized for the entire

conversion effort include:

o Total number of programs by application system,

o The total number of lines of job stream language by

application system,

o The number of job streams by application system,

o Major systems applications by complexity, e.g., payroll,

financial, personnel

3.5 DATA FILES INVENTORY EXTENSION AND ASSESSMENT

Although this activity ^ould have been completed in project

initiation, it is of sufficient importance to conduct a review (and

refinement where necessary) prior to use in the software conversion

study.

In particular this activity should concentrate on a reexamination and assessment of the data files in terms of determining if they can be converted as is, converted with minor changes, or require a major

conversion due to architectural incompatibilities. One of the major

technical management considerations in assessing file conversion

requirement is knowing and understanding the differences in data

conventions (e g., XS3, ASCII, EBCDIC, BCD). Other items which must be

addressed as file requirements definitions include the collating sequences

of the different character sets and the internal character representation

such as packed decimal, hexadecimal, or octaL The implications with

respect to sorting, file maintenance, and their effect on report listings are well known.

File inventory information may also be used to determine the

priority or order of programs to be converted within a system and, to a greater or lesser extent, the order of systems depending upon file

interrelationships and interdependencies between programs and application systems.

39
Using the sample file worksheet (39, 47) (shown in Figure 3-4),

the following information should be included in the inventory:

o FILE ID; Specify a unique identifier for each file.

o FILE MEDIUM; Indicate the storage medium, e.g., 9 -track tape, removable disk, high speed drum.

o CODE TYPE; Select the appropriate code to indicate

the code data is currently stored in:

1 = ASCII 5 = Binary

2 = EBCDIC 6 = Packed decimal

3 = BCD 7 = Floatingpoint

4 = XS3 8 = Bit level

9 = Other

o NUMBER OF VOLUMES; Indicate if more than one tape

reel or disk pack is required for this file.

o ACCESS METHOD; Identify the appropriate file either

sequential, direct access, or index sequential,

organization which applies. If none of these file

organization techniques are applicable, specify the type

of organization used.

o RECORD FORMAT; Specify whether the record format

is "FIXED," "VARIABLE," or "OTHER." If "OTHER,"

describe under COMMENTS.

o RECORD SIZE ; Specify the size (in characters) for each

file (use one line for each record type). Enter the

number of records for each record format in the file.

o BLOCK SIZE ; Specify the size (in characters) for length

of the record block size. If file is unblocked, enter

record size.

o SECURITY/PRIVACY; Indicate whether special procedures will be necessary to protect the contents of the

file or to limit read/write access to the file or parts of

the file. Indicate whether "R" - Read or "W" - Write

restrictions apply to the file.

o COMMENTS; (optional). Enter any comments or additional information about the file. Use this column to

further describe RECORD FORMAT (if necessary) or applicable automated tools, if known.

o CONVERSION STATUS; Indicate the action to be taken

for this file. C = Convert; P = Pui^e, R = Redevelop.

40
cflf-<E-Ow

5^i t

•ooD

O.

O

CU

Q

usKOao<<Ou

COH2uSoo WJOoXHWuoo<

CQ

—

Q

a

Q < n

Soa z

E-Cna.

w 8

b3Xo

-3U

1-9 CU<

CO 3

DO 00T< r

00

>-<1

41
The file inventory data should then be summarized by access method with the followir^ information provided for each method:

o File medium, e.g., disk, tape or card,

o Total number of files,

o Total number of characters,

o Percentage of the total number of files which have data

stored by code type,

o Percentage of the total number of files which have fixed

and variable length records,

0 Percentage of the total number of files which require

privacy or security protection.

As with the applications and programs inventory, automation

of the file inventory for very large conversions will help summarizing and

analyzing file conversion parameters as they affect conversion

requirements.

3.6 CONVERSION TOOLS IDENTIFICATION AND SELECTION

Once the application systems program and file inventories

have been completed and associated with an appropriate conversion

technique, review of suitable and available automated tools should begin.

Most agencies have some resident conversion tools. However, the

screening should be expanded beyond this base. A reference of particular

usefulness is the Federal Conversion Support Center Conversion

Products/Aids Survey (46).

) 3.6.1 TYPES OF TOOLS

For the purpose of this guide, three basic types of automated

tools are addressed:

o Translators

Translation is the process of automatically converting

computer programs from one language to another or from one hardware configuration to another. It is rare

that 100% translation is achieved, and inevitably manual

final adjustment is required.

42
o Emulators

It may not be practical to convert a program if a total

redesign was planned immediately following a conversion

or conversely, convert a program that will be terminated

in the not too distant future. Operating the old

programs using an emulator feature or package to

represent the source machine on the target machine may

offer a feasible alternative. However, other factors

such as possibly degraded performance need to be taken

into consideration before a decision is made to emulate.

o Conversion Aids

This category encompasses all other types of automated

tools. These include file converters, test data

generators, source program directories, optimization

routines, standardization auditors, operating system

converters, operation control stream language

conversion, flow charting aids and benchmark

generators.

3.6.2 SELECTION AND OPTIMIZATION

Feasibility study techniques should be used to select tools.

For example, manipulation of program and file inventories will reveal areas where tools may be feasibly used. Alternative tools can be

compared with manual methods and costed to determine the most

effective approach.

Each tool has its inherent advantages and disadvantages

depending upon the circumstances and environment involved. Moreover,

it should be recognized that selection and implementation of any of these

tools is but a part of the conversion effort. Use of these tools can enhance the actual program and file conversion effort, but they will not

produce completely automated conversion. Some form of additional

manual effort is required for efficient program and file operation on the source system. The need for this manual effort, and related costs, have

to be considered when analyzing use of automated tools. Unless other

estimates are known, estimate 20% manual effort — 80% automated tool.

Case study research associated with this guide uncovered one automated conversion where the target system consumed 20 hours of run time compared to three hours execution time on the source system. This

is an extreme example but it illustrates that subjective human judgement

of conversion results and manual refinement of application programs

converted with automated tools are necessary to optimize and fine-tune

converted software.

43
3.6.3 CONVERSION TOOL EVALUATION FACTORS

Candidate conversion tools ^ould be weighed against the

following considerations:

o Availability

Establish whether the tool is a well established "off-theshelf" package or a new but untested one; determine

whether it should be leased or purchased; determine how

soon it can be delivered.

o Documentation

Determine if the package is fully documented; if documentation includes updates and revisions.

o Support

Ascertain if the vendor will stand behind the product;

determine the history of the vendor and the package;

judge whether the in-house staff can handle the package.

o Operating Efficiencies and Costs

Compare the tool to other similar tools in terms of

purchase or lease cost, maintenance fees and support

availability, hardware resources required, operator

training required, and the availability and cost of such

training. In terms of performance determine how the

converted program(s) compare to the source program.

Identify past users to verify this performance, and

determine if the vendor would adhere to such performance claims in a contract.

o Agency Needs

Any particular considerations that apply to an agency.

For example, will agency hardware handle the tools

being considered.

The Federal Conversion Support Center or contractors can

assist in selection of automated tool(s) should resources, time, or experience preclude an in-house effort.

44
3.7 WORKLOAD ESTIMATION REFINEMENT

The aggregate workload analysis conducted during project

initiation should be further refined. This will require an in-depth analysis

of not only production workloads but expected systems' enhancements and

new systems' developments that will place a demand on the target

hardware.

The associated hardware capabilities, operating systems, and

communication requirements complete this analysis. Factoring in

historical workload and projected user's requirements, future workload

requirements can be extrapolated and summarized. This workload profile can then be analyzed as a complete, integrated entity. The profile

picture will depict the operational environment that must be accommodated by the target system.

3.7.1 WORKLOAD PARAMETERS

The most common information (40) used to determine

workload are itemized below. Utilizing hard ware/software monitors (e.g.,

PLAN/4, TSOMON, etc.) facilitates obtaining the raw workload data.

o JOBS PROCESSED - Number of batch jobs started.

o TRANSACTIONS PROCESSED - Number of on-line

transactions processed.

o CPU TIME - Number of hours of total program

CPU time (both batch and on-line).

o DISK EXCP - 1/0 executions for all direct access

devices, in thousands.

o TAPE EXCP - I/O executions for all magnetic tape

devices, in thousands.

o LOCAL PRINT - Number of lines spooled for local print,

in thousands.

o REMOTE PRINT - Number of lines spooled for remote

print, in thousands.

o CONNECT TIME - Connect hours for terminals and RJE.

o TAPE MOUNTS - Number of tape mounts, in thousands.

After investigating the make-up of the jobs, transactions and

connect times (if any), an analysis can be made of the effect of this

workload on the system. Equipment resource utilization is a measure of

work units needed to process the current workload on the source system.

The main descriptive data elements for measuring resources used are CPU

time, jobs processed, disk EXCEPS top EXCPS, and print volume. An

additional element describing percent CPU busy time should also be

included since it is a key indicator of maximum resource utilization.

45
3.7.2 WORKLOAD ESTIMATION

While numbers of jobs, EXCPs and print volumes are useful

data in the workload analysis, they provide no yardstick to determine the

total workload. The mere fact that 401,053 batch jobs have been run in

the past 12 months does not provide much insight into workload levels.

Further, to state that this represents a monthly average of 50,088 or an approximate 1,670 jobs per day or 70 jobs per hour, does not measure the

demands on the system. The same logic holds true for EXCPS and print

volume. What is important are processing demands per hour in the day

and hours for each shift. These demands are further influenced by

systems down time and systems and application programming hours that

must run in unbroken sequences. Resources should be examined closely

with the view in mind of ascertaining where and when saturation occurs.

3.8 DISTRIBUTION AND TELEPROCESSING REQUIREMENTS

DEFINITION

Because of evolving technology the hardware environment will

likely change during conversion. While from an information system user's

standpoint automated support remains the same, changes may be planned

in the hardware configuration. The agency may be considering centralization of multiple site processing or distributing currently centralized

processing. These potential changes in the hardware environment and the

related teleprocessing requirements have to be assessed.

The systems and applications and data file inventories identify

distributed and teleprocessing requirements for the source system. The

workload analysis identifies gross processing requirements. An analysis

should be made of the processing requirements for hardware configuration

alternatives being considered by the agency. If the staff involved in

hardware procurement do not accomplish this analysis, it must be done by

the software conversion staff.

Each conceptual hardware configuration should be analyzed

with respect to software processing requirements. This accomplishes a number of purposes:

o It assists in verifying that considered hardware configurations are feasible, o It improves the specificity of the hardware RFP,

o It identifies distributed, multiple site, and teleprocessing

software requirements.

3.9 SYSTEM'S SOFTWARE REQUIREMENTS DEFINITION

Requirements have to be developed for systems software

which support applications software and data files. Included are

compilers, spooling, utilities and hardware monitoring packages.

Requirements should be developed as mandatory or desirable by the

46
project team. This serves two purposes: It assists developing the

hardware procurement RFP and in software conversion planning. Early in

the planning phase the hardware configuration will be unknown. Planners

must be cognizant of systems software that they can be assured of and

that which may or may not be supplied by the hardware vendor.

3.10 PERSONNEL REQUIREMENTS DEFINITION

Application system and program, file, conversion tool and

teleprocessing requirements will be used by the project manager to

identify the conversion resource requirements.

In assessing resources the project manager must weigh internal resources available against the total workload to determine the adequacy

of the in-house staff. Once the initial level of effort is estimated and

outside resources (i.e. contractor assistance) is deemed necessary, cost

effective determinations will have to be made regarding where to apply

external assistance (i.e. planning preparation, conversion, etc.)

Finally, if preliminary requirements indicate need for outside

assistance, requirements should be developed for the RFP for software

conversion assistance (e.g. type of procurement, deliverables, milestones,

duration, etc.) which will be prepared in the conversion preparation phase.

3.11 SECURITY REQUIREMENTS DEFINITION

Security and privacy are often overlooked during software

conversion. A project team review of all agency information systems for

agency and Federal security and privacy requirements will assist in

engineering security features into sensitive software data files and

software processing during conversion and avoid costly modification later.

The basic Federal security requirements are contained in the

Office of Management and Budget (OMB) Circular A-71, Transmittal

Memorandum No 1, Security of Federal Automated Information Systems

(July 1978). In general this regulation requires design and approval of

agency software of security specifications, security design reviews and

security testing to comply with A-71 or other applicable Federal policies

(e.g., DOD security regulations). These policies are pertinent to software

conversion. If software support is to be acquired commercially, either as general purpose packages or converted by a contractor, security

specifications have to be developed. Additionally, a risk analysis is required whenever an agency undergoes a significant software change.

Agency software security requirements have to be compared with this risk

analysis. The project manager should enlist the support of the

information system users and the agency information system's security

officer in developing security conversion requirements. If an agency has

extensive sensitive information systems, assistance from an outside

information system's consultant as an advisor to the project team is recommended.

47
3.12 CONVERSION FACILmES REQUIREMENTS DEFINITION

3.12.1 CONVERSION PROCESSING FACILITIES

The requirements of accomplishing software conversion on

systems running production applications have to be developed. This

applies to conversion associated with hardware replacement as well as conversions that are not associated with hardware replacement.

The key requirements are to provide conversion processing

time and convenient and nondisruptive hardware systems access,

regardless of whether it is source or target, and nondisruptive production

support to information system's users. Note: If sensitive processing is accomplished on agency computers, security must be carefully considered

for all alternatives considered.

Any use of excess capacity on a source target computer for

conversion will likely be cost effective. Additional advantages include

convenient location and conversion team familiarity with the source system Disadvantages could include inconvenient access time. Final

determination of conversion processing facilities will depend upon a requirements analysis to determine if additional operators have to be

hired and if production schedules can be adjusted to provide time

convenient to the conversion project team. Otherwise, alternative

choices such as commercial time sharing, use of leased, off site,

production facilities, or use of surplus capacity at another government

agency should be investigated.

If software conversion activities must be accomplished on the

same system used for production and there are no feasible, cost effective

alternatives for avoiding contention between production and conversion

activities, negative impacts must be minimized The project manager

should consider:

o Reexamination of application systems to determine if some unnecessary systems have been overlooked and can

be eliminated to provide for additional processing time,

o Soliciting the cooperation of information system users and agency executives to determine if some information

systems degradation can be accepted,

o Examining information systems to determine if modifications can produce required information with less

processing.

The key management issues here are achieving cooperation

and support by users and top managers and havir^ sufficient time to

explore alternatives to any possible hardware contention problems. If

contention is not resolved, the project manager can expect slippage in the

conversion and inefficient use of project team resources.

48
3.12.2 CONVERSION TEAM FACILITIES

Conversion resource assessments will result in estimates of

the conversion team size, the extent of contractual effort, and whether

contractors should be located at the agency or their own facilities.

Conversion team facility requirements can then be developed.

3.13 SOFTWARE CONVERBON STUDY PREPARATION

The culmination of this phase is the preparation of a software

conversion study. This study, mandated by FPMR Regulation F-492, and

amended by F-496, provides the justification for the conversion and

development of the Agency Procurement Request (ADP) for submission to

GSA for hardware acquisition. There is no specific format presented in

the software conversion study. However, it is recommended that the

project manager acquire a conversion study checklist from the Federal

Conversion Support Center. This guide is useful in structuring a study to

meet agency requirements and to insure completeness. In general, the

study should include:

o Problems

Describe the agency ADP problems which result in the

need for hardware replacement/software conversion.

o Current ADP Environment

Describe the existing systems to provide a basis for

determining the economic and technical advantages of

the proposed new system or change. This description

should include the following information:

Equipment - Itemize all equipment used by the

existing system.

Software - Itemize all system and applications

software including all data files.

Other Systems Software - Identify all other

software to include operating systems, utilities

general purpose software.

Personnel - Identify skill categories and number of

personnel required to operate/maintain the existing

system.

49
o Workload Analysis An analysis of the existing system

workload should provide a baseline for determining trade

offs and advantages of the target system. Processing

and system requirements should also be described.

o System requirements (i.e., the proposed ADPE

Environment)

Describe the requirements and objectives of the

proposed target system.

o Procurement Alternatives

Describe each alternative system in detaiL State

reasons for consideration. Alternatives should include

fully competitive (noncode-compatible). Limited

competitive (code-compatible), and sole source. Include

projected procurement schedules.

o Cost/Benefit Analysis

The purpose of the cost/benefit analysis is to provide

management with adequate cost and benefit information

to analyze and evaluate the alternative (target) systems.

Describe the cost of procurement, training, site

preparation, benchmark, contractor assistance and

conversion for each alternative. State benefits in

quantifiable terms. Non-quantifiable benefits should

address organizational objectives, user's satifaction and

improved missions and goals. Describe the risks in terms

of cost for each alternative considered.

o Recommendations and Implementation Schedule

State the reasoning and justification to support the

recommendation of the selected procurement alternative over the other alternatives with an indepth discussion of

cost to benefits. Identify consequences of not taking

action. Include a schedule and milestones for each major

phase of the recommended system and conversion.

3.14 REQUIREMENTS PHASE MANAGEMENT DECISIONS

At the conclusion of the conversion requirements phase the

ADP manager submits the software conversion study for agency executive

approvaL This study will normally accompany and be approved with other

hardware/procurement related actions, primarily the Agency Procurement

Request.

50
Other agency executive decisions that will be required during

the conversion requirements phase will be approval and funding support

from:

o Federal Conversion Support Center,

o Outside resources which might be required to assist in

security requirements or the software conversion study.

3.15 COST AND ECONOMIC CONSIDERATIONS

In the conversion requirements phase, project personnel costs

will comprise a significant portion of operational costs incurred.

Additional areas of cost which may be incurred include consultant fees

such as security assistance or in preparing the software conversion study.

If operating personnel are used to assist in the software inventory or workload analysis, their costs should be assigned to the conversion

projectThe software conversion project cost estimates developed

during project initiation will be refined using the workload, data file and

program data that is developed. Personnel cost estimates can be

improved by using the actual salaries of personnel currently assigned to

the project, and those proposed in the future. At this stage in the cost

estimation process, cost may still be estimated at a summary level of

detail, however, as specific cost areas can be identified, (e.g., project

personnel salaries) this detail should be incorporated into the costing

information.

In determining the conversion requirements, a major area of

cost input will be in the assessment of in-house personnel resources, and

the feasibility of using conversion tools. The assessment of the current

staffs ability to perform the conversion must address factors such as the

availability and cost of current staff, potential new hires, and contractor

personnneL The assessment of staff adequacy should be based upon the

full cost of the project. In this manner the use of higher cost, contractor

personnel may be justified if the project duration can be shortened.

Similarly, the feasibility of conversion tools should address the full cost

impact on the entire project, and not just the cost of completing one task

in the project.

Cost input will also be required in the completion of the

software conversion study where the project budget is detailed by cost

element, phase, function and year, and a cost-effectiveness analysis of

the proposed course of action is provided. This study will require a close

coordination between the cost included in the hardware acquisition

estimates and the conversion project estimates to assure that all costs are

reflected, and none are counted twice.

51
REQUIREMENTS MANAGEMENT CHECKLIST

0 Full-time project manager continues

o Project team staffed with skills for requirements

definition

o Project briefings to top management continued

o Special assistance/skills identified

Security

Telecommunications

Software Conversion Study

o Project team augmentation provided

FCSC

Consultant

o Application system and program inventory extended

o Data files inventory extended

o Potential conversion tools selected, information

requested

o Workloads estimated and refined; future workloads fully

projected

o Requirements analyzed from distributed processing

perspective

o Requirements analyzed from teleprocessing perspective

o Systems software requirements developed

o Conversion personnel requirements developed

In-House staff

Contractors

o Security requirements defined

Compared with new risk analysis

Information system user input

Agency information system office input

Processing requirements doublechecked

o Conversion hardware facilities requirements defined

52
Conversion team facilities requests defined

Software conversion study completed

Code compatible alternative carefully costed

Non-code compatible conversion alternative

carefully costed

Executive approval of software conversion study

53
SECTION 4

CONVERSION PLANNING PHASE

During the conversion plannir^ phase, the project team will

develop the organization and the schedules to be followed in preparation

for and during the conversion.

Economic considerations associated with these activities must

be addressed. The cost information previously developed for budget

estimates, cost-benefit analyses and feasibility studies and the software

conversion study will become more refined as conversion activities are planned in more detail. This information can support the preparation of

future budgets and conversion plans.

The importance of planning cannot be overstated. It is, in

fact, the most important phase. Proper planning, early in the software

conversion process, will prevent many problems from occurring, and will

prepare management for handling the unforeseen contingencies that may

occur (23, 39).

The case studies presented in Appendix D reiterate the

importance of proper planning. Managers who experienced fairly smooth

conversion efforts had prepared detailed plans, schedules and milestones,

and tracked performance. On the other hand, for those conversions that

had experienced difficulties, the major problems could usually be traced

directly to inadequate planning. Managers, when queried as to how they

could improve future conversions, emphasized the need to plan early and

in detaiL

This section describes the activities related to compiling a conversion plan. Associated planning costs can be developed in

accordance with the methodology in Appendix C. The impacts of this cost

information on management decisions are discussed as they occur.

4.1 PLANNING OBJECTIVES

The objective of this phase is to prepare a conversion plan

which encompasses aU subordinate plans and schedules to prepare for and

complete the conversion. Conversion plan development requires a thorough examination of all activities that must occur prior to, during,

and after the conversion efforts.

To meet this objective, the following results must be achieved:

o Planning must be detailed, and flexible, o Personnel must be assigned, o Facilities must be planned, o Schedules must be developed,

o A reporting hierarchy must be developed,

o A project tracking mechanism must be developed.

54
4.2 DECISIONS IMPACTING PLANNING

During the planning phase there are three major decision areas which have the most affect on conversion and that will be made by top

agency executives or external organizations:

o Budget decisions by top management, or external

organizations (e.g., Office of Management and Budget),

o Procurement decisions by external organizations

(e.g., GSA),

o Schedule decisions by agency executives.

4.2.1 BUDGET

Conversion cost estimates made during the project initiation

phase feasibility study and the requirements phase software conversion

study will have been entered into agency's budgets and submitted to OMB

and to Congress for approval and appropriations. Cost estimates

developed during the conversion requirements phase will have also been

submitted to GSA for review and approval (14, 15). The project manager

should continually review the status of conversion fiscal decisions to

determine if the conversion is approved and any fiscal constraints

applicable to planning.

4.2.2 PROCUREMENT

The conversion planning will also be impacted by the selection

of the target machine. Cost evaluations. Federal regulations and statutes

(e.g., the Brooks Act) may require a competitive procurement (14, 15).

This could result in selection of non-code compatible hardware, creating a more difficult conversion hardware environment.

At the initial stages of the conversion planning phase the

target hardware will be unknown. The project manager must initially

formulate plans to cover conversion on both code compatible and non- code compatible target hardware. There is no way to avoid planning for

both contingencies. However, the software conversion study completed in

the requirements phase should provide insight into a probable procurement

alternative that wiU be chosen. If there are significant cost savings or avoidances in a code compatible conversion, initial planning emphasis can

be focused in that direction. If cost savings are ambiguous, the most

difficult conversion, non-code compatible, can be assumed.

Sometimes in the mid to late stages of the conversion planning

phase the target hardware procurement alternative will be known. If code

compatible hardware will be acquired (even though competitive selection

has yet to take place) detailed plans can be formulated. If a fully

competitive acquisition is pursued, much planning will have to wait until

55
the procurement process is completed and the target hardware is identified. This condition often places pressures to complete detailed

plans in a short timeframe, prior to target hardware installation. The

project manager has to anticipate this contingency. It is extremely

important for the project manager to maintain continuing interface with

the hardware selection staff to gain knowledge of hardware selection

decisions as early as possible.

4.2.3 SCHEDULE RESTRICTIONS

The time frame for the conversion effort may be affected by

management decisions. Contractual arrangements or budget decisions

may dictate seemingly arbitrary installation times of the target

equipment or removal of the source equipment. To meet overall agency

needs, management may require the conversion to be completed by a

certain date. The software conversion plans are thus additionally

constrained. Application of additional agency resources may have to be

planned to meet the completion schedule, or outside contractors with

appropriate expertise may have to be used. These actions may affect

operations and/or the cost of the conversion effort.

4.3 CONVERSION PLANNING ACTIVITIES

Figure 4-1 illustrates the activities that occur during the

software .conversion planning phase. During this phase the project

manager must organize the project team for developing detailed plans for

the software conversion. Thereafter, the project manager and project

planning team will:

o Develop a staffing plan to accomplish the software

conversion,

o Develop a training plan,

o Plan a conversion schedule and mechanisms to track

conversion plan execution,

o Plan for software program preparation,

o Involve functional users and top management in

conversion plans,

o Plan for use of conversion hardware facilities,

o Provide for location of the conversion team,

o Plan for documentation of converted software,

o Plan for contingencies.

56
ORGANIZING THE PLANNING TEAM

STAFFING PLANNING

CONTRACTUAL ASSISTANCE PLANNING

TRAINING PLANNING

SCHEDULING AND PROJECT TRACKING

SOFTWARE PREPARATION PLANNING

USER AND EXECUTIVE INTERFACE

HARDWARE FACILITY PLANNING

TEAM LOCATION PLANNING

DOCUMENTATION PLANNING

CONTINGENCY PLANNING

SECURITY PLANNING

TELECOMMUNICATIONS PLANNING

CONVERSION PLAN APPROVAL

MANAGEMENT DECISION T

CONVERSION PLANNING PHASE ACTIVITIES

Figure 4-1

57
4.4 ORGANIZATION OF THE PROJECT TEAM FOR PLANNING

Before detailed planning can begin, personnel who will

participate in the planning must be assigned (47). Project team staff

members who participated in the project initiation and requirements

phases will normally continue in planning roles since planning requires indepth understanding of the requirements.

Additionally the project team skills should be extended by

augmenting the team with:

o Systems Programmers to provide planning details or systems processir^ impacts,

o Application Programmers who have insight in the

construction of agency information systems,

o User's Representatives who will assist in the conversion

(e.g., durir^ parallel testing),

o Operational Personnel who will also assist in the

conversion (e.g., assisting in system testing planning

schedules),

o Communications Staff to provide assistance in

teleprocessing planning,

o Security Personnel to assist in security and privacy

plannir^ details.

These personnel may participate at different times, and at

different levels, but their planning input is needed. Where in-house

specialist skills are lacking, external assistance (e.g., Federal Conversion

Support Center; consultants, etc.) can be effectively used to shorten

planning schedules and to develop more detailed, comprehensive plans.

4.5 CONVERSION STAFFING PLAN

One of the initial steps is the development of a plan for

organizing and structuring the conversion project team, (i.e., determining

personnel to participate in the conversion, identifying responsibilities and

developing a management hierarchy).

4.5.1 TEAM COMPOSITION DURING ACTUAL CONVERSION

Members of the project team during the conversion phase

should include (3^0: ' *

o Task Leaders - Senior-level personnel with senior level

analyst and programming skills at the leadership level,

preferably with some conversion experience.

58
o Senior Systems Analysts/Programmers - Personnel with

senior level programming skills, preferably with some

conversion experience. These personnel should be able

to assist programmers with conversion programming

problems.

o Senior Programmers - These report directly to their Task

Leaders and perform the actual program conversions.

o Operational Personnel - Staff members responsible for

operation of source and target equipment.

o Vendor/Contractor Support Personnel - Personnel who

will train and assist agency personnel during the

conversion effort.

The size of the conversion project team is dependent on the

software conversion workload estimated during the conversion

requirements phase.

Selection of personnel is dependent on a number of

considerations, including:

o Conversion Experience - prior conversion experience is important. Even if conversion experience has been in a

different hardware/software environment, conversion

insight is valuable.

o Skills - Extensive selection of entry or low-skill level

people will lead to delays, conversion slippage and

increased costs. For this reason, many agencies assign

their most experienced personnel to conversion duties.

It is preferable to assign personel who know both source and target hardware and languages. If this is not

possible, personnel with knowledge of target hardware

and languages should get priority.

o Availability

Experience indicates that personnel assigned to

conversion efforts should remain on the project until

their part is completed. Plans should provide that each

staff member be dedicated to the conversion effort

during the time assigned.

A matrix management approach can be applied to resource

planning. Matrix management can assist by identifying conversion

personnel skills and applying them to conversion tasks with maximum

effectiveness. Figure 4-2 illustrates how this can be accomplished. This

also assists in defining conversion responsibilities.

59
NAME APPLICATION SKILLS AVAILABILITY

Smith Payroll COBOL, CSL 6 months

Jones Personnel COBOL. CSL 6 months

Butler Modeling FORTRAN, CSL 2 months

Brown Personnel COBOL a months

Green Personnel COBOL. FORTRAN 3 months

Laxkins Modeling FORTRAN 3 months

Donnley Payroll COBOL, CSL 4 months

APPLICATION

PERSON

MONTHS

EFFORT

ASSIGNMENT COMMENT

Payroll 3 Smith 4, Donnley 4

Personnel 18 Jones6, Brown6, Green3. Smith2, short 1

Models 4 Larkins2, Butler2. Larkins over 1

SAMPLE MATRIX MANAGEMENT

PLANNING

Figure 4-2

60
4.5.2 ASSIGNMENT OF RESPONSIBILITIES

Plans should be developed for assignment of responsibilities to

all members of the conversion team. This will increase understanding of

conversion duties and reduce the possibility of duplication of effort or omission of important conversion tasks at critical times.

4.5.3 MANAGEMENT HIERARCHY

A management hierarchy (see Figure 4-3) should be included

into the conversion plan for control and project reporting.

4.6 PLANNING FOR CONTRACTUAL

ASSBTANCE/AUTOMATED CONVERSION TOOLS

An assessment of automated tools and the need for

contractual assistance was made during the requirements phase.

Decisions to use automated tools or to obtain contractual conversion

assistance were based on a number of factors, including:

o In-house expertise, o Cost effectiveness, o Internal resource availability, o Conversion time frame.

During the planning phase it is important to plan for the use of

contractors or automated tools. Planning details should specify:

o When to employ them,

o Who will use them,

o How they can be acquired, o Where to acquire them,

o Training needs.

The requirements for and identification of conversion tools

will have already been made during the requirements phase using

guidelines such as those provided by the Federal Conversion Support

Center (40). The emphasis will be on planning the use rather than

selection. Final selection will only be determined when the target

hardware is identified. Likewise, planning details for employment of

conversion contractors can only be made after target hardware

identification and full assessment of the cost benefits of use of in-house resources vis-a-vis contractor support can be assessed.

61
AGENCY

EXECUTIVES

INFORMATION

SYSTEM

USER

ADP

MANAGER

r

PROJECT

MANAGER

EXTERNAL

SUPPORT

TASK

LEADER

TASK

LEADER

r

STAFF STAFF

I

SAMPLE REPORTING HIERARCHY

Figure 4- 3

62
4.6.1 PLANNING FOR A SOFTWARE REQUEST FOR PROPOSAL

IRFP^ ^

If a decision was made to obtain the services of a contractor

to assist during the conversion, plans have to address (47):

o What goes in the RFP,

o When it is to be issued, o How it is to be released (i.e., competitive, sole source), o Type of contract (i.e., fixed price, cost plus, fixed fee).

The experiences of Federal agencies interviewed indicated

that the following should be included in a software conversion RFP plan:

o Number of lines of code to be converted, o Number of programs, files, applications to be converted,

o Conversion schedule, o Average effectiveness level and efficiency of code, o Documentation,

o Provision for test data, o Vendor evaluation criteria.

Programs, files and lines of code are known from data

developed during the requirements phase. Cost is generally based on fee

per line of code converted. Most agencies contacted in developing this

guide, that used an outside contractor, based their fee schedule on this

scheme.

It is important to plan a conversion schedule for inclusion in

the contract. Planning the schedule is described in Section 4.8. An

agency should consider including incentives and/or penalty fees in the

contract. Any penalty fees should reflect the total cost impact to the

agency of the increased costs of continuing current operations beyond the

scheduled software acceptance date. A warranty clause may also be

included. This clause would require the contractor to provide personnel

after conversion completion for troubleshooting purposes.

Agencies commonly specify that a contractor must deliver

programs that execute a certain percentage of code using test data (e.g.,

70%). This alone does not assure production of efficient or effective

code. The agency should consider stating in the RFP an average operating

efficiency level expected for each program converted. A number of

Federal agencies did not include this in their contracts, and they

experienced many programs running much longer on target machines than source machines, despite the fact that the target machines had faster

processing times.

The RFP plan should also state what documentation the

contractor must provide. These should be in accordance with agency

standards or FIPS PUB 38 or 64.

63
Provision of test data should be defined in the planning. Most

agencies choose to develop and provide the data to test contractually

converted code since agencies have the best insight regarding information

system processing requirements. If an agency chooses to let a contractor

develop test data, plans should be developed for agency verification prior

to test data use and acceptance of converted software.

Planning should allow all statement of work and evaluation

criteria to be continually refined up to the point of issuances of the RFP.

Evaluation criteria should be summarized but developed in detail so that

contractors will know the exact terms expected for acceptable

performance. In this regard it is useful if RFP plans are developed in

looseleaf notebook form in a format corresponding to a statement of work

and evaluation criteria. This will facilitate translation of plans into

contract formats.

It is advantageous for the project team planning the use of

contractors to have contractual experience. If this experience is not

resident, it must be gained somehow. One agency, inexperienced in

managing a software conversion contract, gained experience by releasing a preliminary, short-term software conversion RFP. The RFP required

that the selected contractor convert one application system from the source to the target system. This small contract effort served a number

of purposes. It surfaced a number of conversion problems in converting to

the target system, provided the management team experience in

conducting a conversion, and also provided the experience in managing a software contract. Additionally, this approach produced insight into

additional performance criteria and schedules that were translated into

planning the major software RFP.

4.6.2 CONTRACT MONITORING

During the planning phase, a mechanism should be developed

for monitoring the contract. If the contract is lai^e enough, the project

manager should be assigned as, or have assigned on the project

management team, a full-time Contractir^ Officer's Technical

Representative (COTR).

4.7 PLANNING FOR TRAINING

A training schedule for the project team as well as the entire

software staff should be developed. Training itself should begin and end

prior to the conversion. However, if carefully planned, training can

extend into the conversion phase. Proper training of personnel and

adequate training schedules are of major importance in keeping the

conversion process on track (33). The impact of training conducted too

late is apparent - staff is being trained when they should be converting

software. What is not well understood is that training can be conducted

prematurely. The time lapse between training and conversion degrades

effectiveness.

64
Following is a checklist of conversion training plan

requirements. Based on this checklist, the project planning team should

develop a detailed training outline, the content of each subject area and a

training schedule. Training should include all conversion and operational

personnel, and functional users. The project manager should coordinate

training plan schedules with all concerned to ensure that the content and

schedule meet agency requirements.

Training Requirements

o Conversion aids/automated tools

o Target system software

Compiler differences

Disk file management

New peripherals

Utilities

o Target hardware

Operation

I/O procedures

Data format

o Program changes (programming conventions, code and

I/O differences)

o Data

Collating sequence

Logical compare differences

o Program job control language

o Instructors

o Training facilities

Training planning will require coordination with contractors.

The hardware vendor should be made responsible for training personnel on

use of the new equipment (operations, procedures, software) and

describing differences between source and target equipment. Instruction on use of automated tools may require training by the supplying vendor or,

if developed internally, by in-house personneL

65
4.8 PLANNING THE SOFTWARE CONVERSION SCHEDULE AND

DEVELOPING PLANNING TRACKING MECHANISMS

A schedule of system and program conversions must be

established. An inventory of all applications and programs was made

during the project initiation and conversion requirements phases. This

established the number of programs, files, and number of lines of code by

language and the level of conversion effort (in terms of man-hours) each

program or system will require. Using this inventory, the project planning

team should establish the schedule for converting these programs,

whether done in-house or by an outside contractor.

4.8.1 SOFTWARE CONVERSION PRIORITY

The first step in scheduling is to determine the order of the

files and programs to be converted and results expected in a chronological

list.

Top management or functional users may require some

systems to be converted earlier than others because of future agency

plans. Users may also request that their systems be transported to target

hardware as soon as possible to take advantage of its capabilities. Based

on these parameters, plans must be developed around resource

availability.

4.8.2 RESOURCE PLANNING AND RESPONSIBILITIES

Plans must permit conversion to coincide with the availability

of resources, including personnel, equipment, funding, and processing

time. This precludes inefficient situations from developing which

contribute to slippage and cost overruns, such as:

o Hardware available but files and programs not being

^ converted,

o Files and programs in a state of conversion but no or

insufficient processing resources.

This will prevent potential future problems in terms of

overlappir^ responsibilities and provide accountability for the various

systems, programs and files earmarked for conversion.

4.8.3 SCHEDULE PLANNING

A detailed schedule of applications, programs, and files to be

converted should be established regardless of whether conversion is performed in-house or by an outside contractor. A number of methods

can 6e»used to do this, but they all have common features.

66
o Identify personnel responsible for application program

file conversion.

o Establish time frame for conversion.

o Establish deliverables or results (e.g., code translation,

unit, system and parallel tests).

o Establish a progress reporting mechanism and tracking

system.

Four types of schedules should be maintained, and tracked.

These schedules serve as cross-references to each other (33). They are:

o Application system conversion schedule, o Application program conversion schedule,

o File conversion schedule, o Personnel schedule.

Figures 4-4 through 4-7 are sample forms that may be used

for scheduling activities.

4.8.4 REPORTING MECHANISMS - TRACKING AND MONITORING

To maintain control and awareness of project status the

project manager will want to establish a mechanism by which project

status is tracked and reported laterally and upward. At the project team

level reporting is most detailed and should contain:

o Program/application/file name,

o Individual's name responsible for conversion, o Start date/completion date, o Current status, o Expected completion date, o Problems.

The detailed information at the project team level will be

supplied by the task leaders for each activity for which they are

responsible. For higher level reporting the project manager will

summarize project status information and disseminate to top management

in regular reports.

As shown in Figure 4-8 a number of tracking mechanisms are

available, both automated and manual Selection of a method should be

based on requirements and policies of the particular organization, and by

the project manager's management style. The important point here is to

establish this mechanism and integrate it into software conversion

planning.

67
68
69
70
p*

rN

aIn

O

a< meCM

_

u

In

CO

e»5

«-(

CO

es }1

S5

fmw

>,

In

CS

In3

X) o

CM

ULE

n

f-H 1* t '

NMENT

SCUED o

NN

CO

rt o JI CO

CM i

DISS

>v

In

eo3

CO

gi < g

03 1

SONN CM

PER

Application 1 VVi +

Staff

Member :^i 3 M

hJ3QMX

COHZUzoM

CO< I MZzo

CO

cc

o.cu

•-] <

CO o

In3

00 co

OB

In

03 2 & 3 OO B I • CO^ ou

Ix3O

CO

71
TRACKING/PERFORMANCE

MEASUREMENT

MODIFICATION

OF

PLANS

TREND

ANALYSIS

Nichols PMS

(N5500)

X X

ASA-PMS X

MSGS X

X X X

r>PTi MA linn X

Projacs X

IBM 5110 PCS X X X

MCS X

COPES X X

Navy Conversion PMS X X X

PROJECT MANAGEMENT TRACKING PACKAGES

Figure 4-8

72
The tracking mechanism should also provide cost performance

information for each activity such as estimated budget, actual expenses

to-date, and variance between estimated and actual costs. Variance

criteria could be established that would flag potential cost overrun

conditions for early, management attention.

Figures 4-9 and 4-10 illustrate sample tracking charts that

may be used by project managers. Figure 4-9 is a periodic (weekly,

biweekly, etc.) report indicating the status for each program (application,

file). The chart is completed at regular intervals by the project manager

for a summary overview of the entire conversion. Figure 4-10 is an

application tracking chart that can be used by task leaders and the project

manager to keep track of each program within the application.

4.8.5 MULTIPLE SITE CONVERSION SCHEDULES

Management of conversions at multiple sites (e.g., in a

distributed processing environment) presents additional problems. If centralized control cannot be exerted, tracking and monitoring progress

for a multiple site conversion will be difficult. In multiple-site conversion

planning it is essential that top executives assign responsibility for

maintaining schedules and reporting conversion progress.

4.9 SOFTWARE PREPARATION PLANNING

The condition of software and data files, prior to conversion,

might be such that they cannot be efficiently or effectively converted.

Preparation activities have to be planned (27, 39) includir^ procedures to:

o Update documentation,

o Remove obsolete programs and code, o Develop test data, o Modify programs, as required, prior to conversion.

During the conversion requirements phase, documentation was

reviewed for completeness and accuracy. Since poor documentation

directly affects conversion effectiveness, corrective action must be

planned and tracking mechanisms should be developed to ensure documentation requirements are met.

Plans to allow for the removal of obsolete programs and code

should include notification of users that their asistance is required and

solicited in a positive, participatory role and obtaining support from top

management.

Test data development planning is extremely important. It affects the accuracy and effectiveness of the converted programs and

considerable developmental lead time is often required. This is discussed

in more detail during the conversion preparation phase.

73
WEEKLY

PROGRAM

STATUS

WEEKOF:J<v^

lU

Costs

1

^•^

o - («» -*

« ?^ J

003

a

CO

I d

•t

itc1

6

ii

c3

5

Complete

Date « — «

"> 4

Sch

Date

Complete

<s -

< d

v*^

CO p

IHa -D

TASK

LEADER:

Smart

E

o

E

<MaM

I

^3 3

i

i

M

DOo

l-l QU

rl

1-

• 3

•Hr

Application «^

P

-if

r

3 i

o

Oo 4^
75
Program modification activities should be included in the

conversion plan. These activities are listed below.

o Language Translation

The experience of some Federal agencies indicated that

language translation should occur prior to conversion, if possible, (e.g., Assembly languages to COBOL for a COBOL to COBOL conversion)

o Enhancements

If new user enhancements and functional redesigns are

required, they should preferably be scheduled prior to or after conversion, and not during the actual conversion.

o Removing Vendor Extensions.

All programs should have been examined for vendor

specific extensions during the requireVnents f^ase.

These should have been identified and documented.

Conversion planning should allow time for the removal of

vendor specific extensions and coding, if possible.

However, vendor extensions may provide capabilities

that standard languages do not. It may not be possible to

remove these extensions and still provide the same

output. Redesign activities may be required.

o Optimization

Programs should be examined for efficiency. If optimization is warranted, plans should be developed to

streamline code prior to conversion. This reduces actual

conversion time and ensures production of efficient

software.

4.10 FUNCTIONAL USER AND EXECUTIVE INVOLVEMENT

Functional users should be involved throughout this phase,

since their cooperation is essential for a smooth conversion effort. Users

should be included in planning for schedulir^ and testing (47). The cost of user committee or work group should be included in the total cost of

conversion, and the size and involvement of this group should be

determined partially on cost considerations.

It is unlikely that agency executives will wish to be involved in

the conversion planning detaiK However, the project manager should

76
ensure that agency executives are continually apprised of planning

progress. This level of management can lend significant support and

assistance in resolving many planning conflicts that will occur outside the

authority of the project manager or ADP manager.

4.11 HARDWARE ACTIVITIES

The project team must stay abreast of all activities relating to

the hardware procurement, since these activities will affect the

conversion plans.

The hardware procurement decisions will impact planning and

conversion costs according to the selection of the target environment

equipment, and the availability of the target equipment for installation,

testing, and operations.

It is recommended that agency staff involved in hardware

acquisition regularly participate in software conversion planning

conferences.

The project manager must plan for production and conversion

processing. A number of options are available for conversion and should

have been identified on an operational and cost-effectiveness standpoint

during the requirements phase:

o On target hardware colocated with source hardware,

o On target hardware located in another facility,

o Through time sharing on hardware provided by the target

vendor,

o A combination of the above alternatives.

If the target hardware is not installed prior to the start of the

conversion, time sharing arrangements on a compatible machine will be

required. The hardware RFP may require the vendor to provide these

services, or a commercial timesharing service may have to be used.

The target hardware may have to be initially installed in

another location if source hardware is still required for production and the

current computer facility is too smalL This will require providing another

facility and all appropriate services, e.g, air conditioning, power, raised

floors.

The selection of production and/or conversion facilities is dependent on a number of variables, including cost, availability, and time

frame. Preparing another computer room is expensive, requiring detailed

planning and contract work. If the target computer is placed in another

facility, the conversion team may have to relocate.

77
Use of a time sharing service may result in two additional

costs:

o Equipment (terminals, modems) required to interface

with the service,

o Computer time.

4.12 PLANNING FOR LOCATING THE CONVERSION TEAM

Plans must be prepared for providing facilities to house the

conversion team. Sufficient space may be available to house the planning

team as a group, but not be large enough to accommodate the conversion

team. If members of the team are located in a number of different

places, it will be advantageous to move them to one location during the

conversion effort to increase management control. If converted programs

are to be run on hardware located external to current facilities, it may be

advantageous to temporarily relocate the conversion team to or near that

facility.

4.13 PLANNING FOR DOCUMENTATION OF CONVERTED

PROGRAMS

Plans should specifically require the conversion team to

produce documentation in accordance with FIPS standards or guidelines.

Additionally, plans should provide sufficient resources and time for

documentation production. If contractors are to be used for software

conversion, RFP planning should be reviewed to ensure documentation

requirements are addressed. Documentation improves software

maintenance on a day-to-day basis and significantly aids programmers and

analysts in software conversion.

4.14 CONTINGENCY PLANNING

To reduce the likelihood of problems occuring during

conversion, continuous review of plans for potential problems can assist in

early identification and resolution of many otherwise disruptive influences

before they occur. No conversion will be problem-free, however. The

project manager should expect problems and develop a plan to handle

those contingencies as they occur.

During conversion most unanticipated problems occur due to:

o Failure to Maintain Conversion Schedules Schedule

slippage can be significantly reduced if plans provide

adequate resources in terms of personnel and time to

accomplish conversion activities. Problems are further

reduced if specific staff capabilities and limitations are considered in developing schedules and assignments.

However, the project manager must anticipate that some

personnel wiU fall behind schedule.

78
o Personnel Changes Unexpected losses of personnel will occur due to sickness, extended vacations, transfers and

termination.

o Scheduling Deficiencies Because requirements can never be perfectly defined, some schedules will be developed

that are too rigid or unrealistic.

o Contractor-Related Problems Contractors frequently

fall behind schedule or converted programs may require

more optimization than anticipated.

o Hardware Delivery and Installation Delays Hardware

installation may be delayed due to contractual

difficulties, transportation delays due to strikes,

manufacturing difficulties or problems in site

preparation.

Plans should provide a "reserve" of personnel resources and

time to permit the project manager the flexibility to adjust schedules and

levels of effort to meet contingencies on a case-by-case basis and still accomplish conversion by the established end date. Task order contracts can also be negotiated prior to conversion to apply contractors on a quick

reaction basis in resolving conversion problems.

The use of a detailed costing structure as described in

Appendix C can assist the project manager in contir^ency planning and

execution. Potential and actual problems can be analyzed and

alternatives selected at the lowest overall cost to the agency.

If contractors are going to be used to convert software the

potential for problems can be reduced by detailed planning of the RFP in

terms of expected deliverables, documentation, and software

performance. Penalties or awards in the contract are recommended to

provide incentive for the contractor to stay on schedule and perform

effectively.

4.15 SECURITY/PLANNING

Security plans should be developed to meet requirements

developed during the requirements phase. Specific areas which require

planning attention include:

o Identification of security software features which meet

the needs of the risk analysis and assignment of

conversion team responsibilities for inserting security

features into software and procedures during conversion,

79
o

o

o

o

o

o

o

o

o

NBS FIPS PUBS 31, 41, 48, 65, and 73 address security and risk

management considerations which may be helpful in dealing with security

needs during the planning stage. These FIPS PUBS are described in

Appendix B.

4.16 TELECOMMUNICATIONS PLANNING

^

Plans and schedules must be developed to assure that the

converted software and data files can interface with or be supported by

teleprocessing hardware and software environment.

4.17 FORMAL CONVERSION PLAN

All the activities described in this section should be

incorporated into a formal conversion plan which will serve as the guide

during the conversion process. Figure 4-11 is a candidate outline of a conversion plan that can be used as a guide by project managers.

The conversion plan should answer the questions of:

o Who shall participate and conduct the conversion? o When will the conversion take place? o Where will the conversion take place?

o How much will the conversion effort cost?

It is recommended that the plan be developed in draft form

and coordinated with the hardware acquisition staff and information

system users prior to presentation to agency executives for approval.

Access control to sensitive software, databases, system

libraries and documentation.

Isolating software testing and the use of non-sensitive

data from the operational environment,

Software security assurance and certification.

Conversion team security training.

Personnel clearances to include contractors and

consultants,

Operational procedures during testing and cut over.

Facility requirements for sensitive software conversion

products (e.g., locked cabinets, safes for sensitive

listings, etc.).

Security specifications in the RFP that must be

addressed by the contractor.

Teleprocessing, multi-site and distributed processing

security.

80
Section Description

1 Background

2 Summary of Workload Analysis

3 Budget Summary

4 Personnel Resources

- Management Team

- S/W Conversion Team

- Availability

5 Conversion Schedule

- Responsibilities

- Schedule

6 Project Reporting and Tracking

7 Conversion Aides

8 Software Contract

9 Training Plan

- Security Plan

- Telecommunication Plan

10 Facilities Plan

- Production

- Conversion

- Team Location

- Equipment Resources

11 Contingency Plans

Appendices Budget Schedule

SAMPLE OUTLINE OF CONVERSION PLAN

Figure 4-11

81
4.18 PLANNING DECISIONS

At the conclusion of the planning phase the conversion plan

will be presented to agency executives for approval to proceed with

preparation and conversion activities. It is recommended that the plans

be presented as part of a formal briefing where the entire plan can be

explained and an appreciation gained by top management for planning

ramifications and impacts on overall agency operations.

Once plan approvals are gained other management decisions

will involve approving conversion preparation and conversion budgets and

implementation procedures associated with conversion preparation, the

next phase.

4.19 ECONOMIC CONSIDERATIONS

During the conversion planning phase, personnel costs should

continue to be the major element of cost. Outside consultant services

may also contribute to the cost of this phase if these services are used to

assist in the planning effort in areas such as developing the conversion

plan, reviewing the conversion plan or actually preparing the formal

conversion plan for submission to upper management. Expenses may also

be incurred in the acquisition of automated project planning, tracking and

reporting aids.

In this phase, the cost estimates developed for the software

conversion cost structure will be refined as conversion activities are defined in more detail. Cost information should be developed at the most

detailed level that is anticipated to be required. The accuracy of

individual cost estimates at this level may not be great; however, the

overall accuracy of the total cost of conversion should improve due to the use of more detail and the ability to estimate future project costs using

the actual costs incurred during the previous phases.

Conversion cost information will be used during this phase to

assist project management in developing the conversion schedule and

resource assignments. Scheduling decisions should be based on total cost

considerations that include the entire procurement action, not just the

software conversion effort. The detailed costing methodology given in

Appendix C can assist in the assignment of resources to the conversion

effort by allowing a cost-benefit analysis regarding the use of outside

personnel resources for conversion functions. Also, the conversion cost

information will assist the preparation of the formal conversion plan by

providing detailed cost information for budget planning by developing

budget schedules by function, phase or year; developing alternative cost

justifications for the use of outside contractors and conversion aids;

providing continued justification for the conversion effort; and ensuring

the cost-effectiveness of contingency plans.

82
4.20 PLANNING MANAGEWffiNT CHECKLIST

0 Planning team assembled

o On-going costs being tracked

o Team augmentees identified

System programmers

Security

FCSC

Consultants

Telecommunications

Others

o Coordination and interface on-going with hardware

acquisition staff

o Budget available to support planning

o Project planning constraints identified

Budget constraints affecting conversion

Hardware procurement

Time and schedule limitations

Others

o Conversion staffing plan developed

In-house staff

External conversion resources

o Training plan developed

o Plan for use of contractual assistance and conversion

tools during conversion completed

RFP planning

Tool acquisition, training and use planning

Contract monitoring

o Software conversion schedule planned

Priorities considered

Conversion responsibilities assigned

Schedule developed

Information system user input

Multiple site schedules considered

o Conversion plan tracking mechanism developed

83
Software preparation plan developed

Documentation updates

Removal of obsolete programs and codes

Test data

Preconversion program preparation

Optimization

Continuous interface with agency executives and

information users

Conversion facilities planned

Locating conversion team planned

Documentation production planned

Contingency planning accomplished

Security plans developed

Telecommunications and distributed processing plans

accomplished

Conversion plan drafts

Internal agency coordinationor

Agency executive approval

84
SECTION 5

CONVERSION PREPARATION PHASE

This phase is a direct continuation of conversion planning in

that many of the plans made during that phase are acted upon. At the end

of this phase, the project manager will have accomplished all activities

that are required to begin actual conversion (23).

On a timeline of conversion activities, the preparation phase

may be significantly overlapped by conversion planning on one side, and

the conversion phase on the other. This is illustrated in Figure 5-1.

However, the activities or functions that occur during preparation are

distinct from planning or actual conversion activities. Thus, preparation

is discussed as a separate phase.

While preparing for the conversion, the project manager must

continue to monitor project cost performance relative to the initial

budget established during project initiation. The preparation activities

may require significant expenditures over a short time period as the

conversion staff is acquired, facilities and equipment obtained and

conversion tools developed. Due to the change in magnitude of conversion

related expenditures, the project manager may find it necessary to track

project costs closely and report regularly (e.g., monthly) to top executives

to assure them that cost controls are being used. By comparing software

conversion preparation costs estimates against actual costs incurred, the

project manager will be able to refine cost estimation data and

procedures. This will permit more accurate projection of conversion costs

in future phases and future conversions.

During this phase the project manager will begin to see areas

in the conversion plan that need improvement or revision. The conversion

plan, however, should have the flexibility to allow for changes, and

modifications by the project manager when needed.

5.1 OBJECTIVE

The objective of this phase is to complete all activities

necessary for the project team to commence conversion. This objective is accomplished by following the conversion plan and conducting all

activities that, if not accomplished, would interfere with or impede the

conversion effort. These include assembling the staff, training, obtaining

software tools, obtaining contractual assistance, and obtaining facilities

and necessary equipment.

85
86
5.2 DECBIONS IMPACTING SOFTWARE CONVERSION

The project manager must be aware of, and prepared for,

decisions made by top management and external organizations. New

decisions may be made that affect the conversion effort. The conversion

plan and schedule will have to be modified based on these new decisions.

For example, the budget may be changed, forcing the project manager to

change conversion schedules. The target machine may be changed,

forcing a change in scheduling, staffing, and training.

By continually addressing the full cost of the conversion

effort, the project manager will be in a position to correctly relate the

conversion cost impact of these external decisions to agency executives

and involve this level of management in the total conversion effort.

5.3 CONVERSION PREPARATION ACnVmES

Figure 5-2 illustrates the major activities that occur during

the preparation phase. They provide the framework for the subsequent

portions of this section, and include the following:

o The conversion budget must be approved,

o Work packages must be developed,

o The project team must be assembled and assignments

disseminated,

o The training staff must be assembled and training must

start,

o Contractual support, if needed, must be obtained,

o Software tools must be obtained or developed, and team

members trained in their use,

o Equipment must be obtained and located with

appropriate users (e.g., terminals),

o The project team should be located in the facilities to be

used during conversion effort,

o Test data and files must be developed,

o Program modifications should be started,

o Documentation should be updated,

o Hardware procurement should be monitored.

87
CONVERSION BUDGET APPROVAL

WORK PACKAGE DEVELOPED

PROJECT TEAM ASSEMBLED

TRAINING INITIATED

CONVERSION SUPPORT ACQUIRED

EQUIPMENT OBTAINED

TEAM LOCATED IN FACILITY

TEST DATA DEVELOPED

PROGRAMS MODIFIED

DOCUMENTATION UPDATED

HARDWARE PROCUREMENT

MONITORED

USER & MANAGEMENT INTERFACE

PROGRESS TRACKED

PROBLEMS RESOLVED

CONVERSION DECISION

MANAGEMENT DECISION

CONVERSION PREPARATION ACTIVITIES

Figure 5-2

88
o Users' and agency executive's conversion responsibilities

must be coordinated,

o Progress must be tracked throughout the phase,

o Problems as they arise must be addressed and the

conversion plan modified as needed.

5.4 BUDGET APPROVAL

It is imperative that prior to beginning costly preparation

activities, project management obtain final approval for the budget. This

final approval should reflect any recent budgetary changes and financial

reporting requirements desired by management. In previous conversion

phases, costs were primarily related to personnel Costs will climb during

the preparation phase as the larger conversion team is being assembled,

contracts are awarded, and equipment and facilities obtained.

5.5 DEVELOPMENT OF WORK PACKAGES

The project manager and team leaders will develop and

assemble comprehensive conversion work packages to facilitate

conversion (45).

Work package preparation includes the effort to physically

assemble all work packages and to establish an inventory and control

system for the work packages. Each work package should contain enough

information to enable the converter to adequately define what is to be

converted (programs, files, control stream language, etc.), to ascertain

the system/subsystem functions, to identify all system/program

documentation needing to be redocumented, and to execute and test the

converted system/subsystem to guarantee conversion was successful. A

work package should be large enough to encompass a functional area (a

system or subsystem) and should be made up of information describing the

overall package (system/subsystem) and its individual components

(programs, files, etc.). The content and makeup of individual work

packages should be determined for each conversion, but will typically

consist of such items as:

o Work package transmittal sheets. o System/subsystem descriptions,

0 System/subsystem test data and descriptions.

0 System/subsystem control stream language job streams,

0 System/subsystem run documentation,

0 Program inventory forms.

0 File inventory forms. o Program descriptions,

0 Source and compile listings.

0 File descriptions,

0 Program test data. o Program documentation. o File documentation.

89
5.6 ASSEMBLE CONVERSION TEAM

Conversion team members who will work on the conversion

must be assembled or notified during this phase (47). Each person must be

informed of:

o When their conversion work will begin, o To whom they will report, o Other members of the project team,

o Reporting mechanisms to be followed,

o Areas of responsibility, o Schedule for completion of tasks, o Priority ranking of assignments,

o Training schedule, o New work locations, if applicable, o Equipment available.

Project managers may find it helpful to notify the conversion

staff members and inform them of their responsibilities using a form or written format. This will improve understanding and ensure all pertinent

information is conveyed to team members. An initial group meeting is recommended to discuss the overall goals and objectives of the conversion

effort. Thereafter task leaders can then meet with their respective staffs

and disseminate detailed information to each individuaL Project team

members should be made aware of the fact that they will be dedicated to

the conversion until their particular duties are completed.

Task leaders should hold regular meetings with their staff to

discuss progress and review any problems which may arise.

Project team members will be furnished work packages as part

of tasking. Project team members should review their particular tasks,

and notify their task leaders if they foresee any problems (e.g., not

enough time scheduled for a particular program conversion). The

problems that surface may require modification of the conversion plan.

5,7 TRAINING

The project team members should be scheduled for any

training that is required. If on-the-job training is to be used in lieu of

formal training courses, some initial productivity loss can be expected as

the learning curve is gained. If on-the-job trainir^ was not considered

during the requirements phase, the conversion plan and schedules will

require adjustment. In addition to the conversion staff, training will be

provided operational personnel, functional system users, and other

members of the ADP staff, not involved in conversion, but who will

ultimately perform software-related work on the target system.

The project manager must acquire and provide the instructors

to train the conversion staff and ensure that training plan objectives have

been met (33). Except for very large conversions, one to two

90
instructors should be sufficient. Multiple-site conversions may require

more trainers if software conversion is decentralized or if a constricted

conversion schedule requires concurrent training at two or more locations.

System programmers should make special training

presentations, as required, to inform the conversion team of systems

programming impacts on application software. Also, any security-related

training should be accomplished.

5.8 OBTAINING CONTRACTUAL ASSISTANCE AND

AOTOMATED CONVERSION TOOLS

5.8.1 PREPARATIONS FOR OBTAINING CONTRACTUAL

ASSISTANCE

Any planned outside assistance must be obtained during this

phase. The project manager will have to provide assistance in or accomplish:

o Preparing the software conversion RFP,

o Releasing the RFP,

o Evaluating proposals, o Selecting a contractor.

Plans for these activities were made during the conversion

planning phase including planning the specific content of the RFP.

However, contractual procedures in obtaining software conversion support can take from four to six months from, time of issuance of the RFP. The

contract must be solicited, evaluated and responded to by vendors,

negotiated and awarded. The potential for time delays is great. It is essential that contractual assistance be obtained on schedule because

slippage in this area may force slippage of the whole conversion effort.

The selection of a contractor to assist in the conversion

process is critical since the contractor's ability will affect the outcome of

the entire conversion effort. Contractual evaluation factors applied in

this phase include, but are not limited to:

o History of Company

Specifically how long has the vendor been in business;

financial standing; soundness of corporate management

practices; background of corporate management.

o Experience

Types of conversions the vendor has been involved in; success; problem resolution methods; familiarity with

the agency target hardware environment.

91
o Personnel

The skill and experience level of the employees; turn over rate.

o Cost, Deliverables and Responsibilities

The proposed deliverables and schedule; responsibilities

assumed by the contractor; contract cost.

o Testing

Ability of the contractor to meet test objectives;

proposed alternatives; acceptability of alternatives.

After selecting a software contractor, meetings should be

held with their representative. It is important that lines of communication be kept open and that misunderstandings be quickly detected and

resolved. Since a contract statement of work can never completely

address all contingencies that occur during the conversion, it is important

to develop and maintain a professional, cooperative working relationship

with the contractor.

The contractor should thoroughly understand how progress is going to be monitored, and how performance penalties or awards will be

determined. This includes identifying to the contractor which staff

members responsible for specific areas of the conversion are contractual

points of contact.

5.8.2 AUTOMATED TOOLS

Automated tools, if used, must be obtained or developed

during this phase. If they are to be obtained from a commercial source,

another RFP may have to be released. (Note that the decision to develop

the tools in-house or obtain them from an outside source was made in

earlier phases.) Potential contractors should be required to perform a live test demonstration on a sample program prepared by the project team.

Results should be evaluated for accuracy and efficiency and based upon

the full cost impact of each proposal on the total software conversion

cost. The cost of the automated tools should be compared to original

estimates and, if significantly greater than the estimates, their costeffectiveness should be reevaluated.

If the tool is to be developed in-house, a staff must be

assigned to develop the tool as well as tool verification data. Data

processing resources must be made available to the developers. After

tools have been acquired or developed, the conversion team members

must be trained in their use.

92
5.9 LOCATING CONVERSION TEAM/OBTAINING EQUIPMENT

Project team members ^ould be located in their team

facilities. New offices should be equipped with adequate furniture -desks,

chairs, lights, telephones. The project manager should ensure that

adequate resources are available to those team members who require

moving assistance (e.g., boxes, transportation etc.) (4).

Relevant data processing equipment that project team

members may require (e.g., card files, terminals, modems, and telephones)

must also be obtained. These should be in place and tested prior to

starting the actual conversion process.

5.10 CONVERSION FACILITIES

Management must obtain conversion facilities, and develop

procedures for use. Information distributed to the project team prior to the conversion should include:

o Location of facilities, o Operational procedures,

0 Hours available.

0 Points of contact. o Access and security issues.

0 ADP communications, telephone numbers.

0 Logon procedures.

0 Protocols and passwords required to log on hardware.

0 Troubleshooting procedures.

5.11 DEVEL0PB4ENT OF TEST FILES AND DATA

Good test data should be developed prior to code conversion.

If the conversion is to be done totally in-house, project team members

will have to develop the test data. A management question arises,

however, when a software contractor is used. Who should develop the test

data, the contractor or the organization? All of the organizations

interviewed in preparation of this guide developed their own test data.

However, it may be feasible for the contractor to develop the test data

for agency review and validation. Deciding who should develop test data

will have been accomplished during the requirements phase. Whether test

data is developed by an agency or contractor, it is important that

information systems users have the opportunity for input and review.

Test data preparation and generation includes all creation,

preparation, and generation of test data sets to validate the converted

programs, files, and systems (45). It should ensure that unit test data

93
sets are small enough in volume to minimize testing costs, but thorough

enough to exercise at least 70% of the logical paths of the program.

Several studies have Independently shown that typically a system will

spend 50% of the run time in 4% of the object code; and 10% of the code

typically will account for 90% of the run time. The implication is that

90% of the testing may only be exercising 10% of the code. Thus,

ensuring that about 70% of the logic paths are executed may still be

inadequate. The 70% tested must include the code that is typically the

most frequently used. Preparation of test data for execution of the

programs following clean compilation should stress the use of data that

will execute a maximum amount of the program logic with a minimum

amount of input data. Because test data are usually prepared and

generated on the source computer, their preparation and generation

should include the conversion or transfer of the test data files to the

target computer so file comparisons can be performed.

5.12 PROGRAM MODIFICATION AND INCORPORATION OF

USER ENHANCEMENTS INTO SOFTWARE

Any additional modification of programs should occur during

this phase. Project team members should:

o Remove any obsolete programs and code. This will

require team members to interact with users.

o Program desired user enhancements into the system in

advance of conversion. It would be preferable to do this

after the conversion. However, if time allows or enhancements are mandatory, changes should be

accomplished during this phase.

o Remove vendor extensions from the code. However,

this may not be possible because the extensions may

meet a requirement that cannot be provided by standard

lar^^es, or by target vendor extensions. Project team

members should familiarize themselves with these

extensions, reprogram where possible, and develop

alternative plans for extensions that cannot be removed.

o Optimize software to shorten conversion time and ensure

efficient code is converted.

At some point immediately prior to a system conversion,

software development should be frozen. This will help ensure that outputs on source and target systems are the same during parallel testing.

However, the experience of many conversion managers indicates that this

is more difficult in practice than in theory. Functional users often

require modifications at some point during the conversion, and some

systems cannot be frozen. Established and enforced systems change

94
procedures can reduce problems of simultaneously converting software

that is under development. Change control procedures permit

identification of a software version configuration and a continuing record

of all changes as they are applied to specific versions. A version can be

selected for conversion and the recorded changes added later. If an agency does not have good change control procedures in effect, the

project manager should enlist the support of the ADP manager to

establish and implement change procedures prior to actual conversion.

5.13 DOCUMENTATION

The project manager will have to ensure that documentation is updated. Documentation should be brought to a current state for all

software that is not going to be completely redeveloped (33). For

software documentation that is in a poor state of maintenance or is nonexistent, the project team will have to do considerable research and

writing. Some training may be necessary, particularly for newly assigned

personnel or contractors, in agency documentation standards or FIPS PUB

38 and 64. Managers will have to arrange for administrative support in

documentation production and perform quality reviews as documentation

is produced. It is advisable to produce documentation on automated

equipment (eg, word processing) to facilitate revision and maintenance.

If user documentation revision or update is required (i.e , users manuals) managers will have to coordinate with functional users and

achieve their cooperation in the documentation effort.

5.14 HARDWARE PROCUREMENT

The project manager must keep informed of all activities

relating to the hardware procurement. The project manager of one agency interviewed did not stay abreast of hardware procurement

activities, and was surprised when target hardware was switched midway

through the conversion effort. This forced abrupt, disruptive changes in

planning and conversion preparation.

5.15 USER AND TOP MANAGEMENT INVOLVEMENT

As in all other phases, functional users should be involved

throughout conversion preparation. Users have to keep the project team

informed of any new functional requirements that impact on software to

be converted, particularly those that occur from outside the agency.

User's cooperation is also needed in modifying programs, freezing the

software, and in obtaining documentation.

95
5.16 TRACKING PROGRESS

The tracking mechanism, developed during the conversion

planning phase is implemented during this phase. After assignments are

disseminated, management must track the progress made by the project

team as it prepares for conversion.

At the project management level all preparation activities

will be tracked in detaiL The project manager must have immediate

access to information on a daily basis concerning progress in:

o Program modification, o Program preparation, o Documentation,

o Test data development,

o Facilities - staff and conversion, o Equipment installation, o Software conversion contract, o Automated tools development.

The project manner cannot develop the project details alone.

The project team leaders will assist in compiling and reporting on assigned

project responsibilities (e.g., specific program modifications,

documentation, etc.). Project status should be displayed on visual

tracking aids selected for use. Bar charts are commonly used since they can display the status of all project activities and whether objective enddates have been reached. Regularly-scheduled project team meetings (at

least to the team leader level) are recommended, no less than on a weekly

basis, to allow team members to surface potential problems and to keep

the entire team apprised of progress.

At levels above the project manager, project status

information should be summarized and regularly reported no less than on a monthly basis. Graphics (e.g., bar charts) displaying status of major

preparation activities are equally useful in reporting project status to

agency executives as the more detailed charts are to the project manager.

Scheduled project status briefings maintained since the project initiation

phase will continue and assist in keeping top management informed.

Exception reports of significant problems, beyond the capability of the

project manager to resolve, should be immediately provided.

5.17 DEALING WITH UNFORESEEN PROBLEMS

Unanticipated problems begin to surface during this phase. As

problems are identified, they must be addressed. This is a key

management issue. Postponement of problem-solving, no matter how

minor the problems appear, may result in having to cope with larger,

compounded problems durir^ actual conversion.

96
Common problems that may arise during conversion

preparation can be associated with the following list. Comments are offered on how the occasion of these issues may be reduced or avoided.

o Unexpected management decisions

Budget modifications

Change in target machine

Schedule change forced on project management

Comment: Continuing coordination with agency staff

members and regular executive level project status

briefings may provide advance information to plan

and execute schedule changes.

o Project team

-~- Personnel losses

Poor personnel morale

Skills don't meet expectations

Personnel cannot be dedicated to project

Comment: Regular team briefings can improve morale. Quick

reaction task order contracts can be executed to acquire additional staff and skills needed.

o Training

Inadequate training

Poor attendance

Conversion environment changes (target hardware

or software is changed)

Comment: Training plans should have provisions for remedial

training and additional classes. Each absence

should be challenged. Training schedules published

well in advance reduce conflicts with leaves, etc.

o Contractual assistance

Delays in preparing RFP package

No vendor bids

Vendors cannot meet requirements of RFP

Poor customer/contractor communications

Comment: Accumulate RFP input in looseleaf form as it is developed in the requirements phase. This eases RFP preparation. Advertise well in advance an

intent to issue an RFP and what the scope of work

will be. On large projects insist on a full-time

contractor project manager and have the COTR on

the project management team.

97
o Automated tools

No commercial tool available to meet agency

requirements

No vendor bids

Delays in development in-house

Tools inefficient and/or inaccurate

Comment: Assessment of automated tool requirements early

in the requirements phase should preclude this

issue

o Project team facilities

Delays in obtaining equipment, e.g., office

furniture, telephones, modems, terminals, etc. Facilities are unavailable

Delays in moving personnel

Comment: Identify requirements early; obtain budget.

o Conversion facilities

Low priority given to project team personnel

Facilities are inadequate or inconvenient

Data communication problems

Unreliable hardware

Comment: Maintain ongoing coordination with hardware staff.

Anticipate problems early and explain

ramifications at executive level project reviews.

Identify backup hardware and communications in

contingency planning.

o Test data

Developed test data is inadequate

Delays in developing test data

Comment: Solicit early user input in developing test data.

Stress continuous agency maintenance of test data

packages.

o Program modification

Users continue to enhance their programs, or re- quest enhancements

Modification more difficult than anticipated

98
omment: Established change control procedures, good

documentation, and use of standard lar^uages, and

restricted use of vendor unique utilities during

normal software operations should ease problems in

this area.

o Documentation

Additional documentation not available

Users do not cooperate

Development or modification of documentation

more difficult than anticipated

Comment: Establish and enforce documentation standards at

all times.

o Hardware procurement

Target hardware charges

Delays in obtaining target hardware

Comment: Continued and close coordination with hardware

acquisition staff is a must.

o User involvement

Users do not cooperate: additional enhancements,

modifications requested

Users fail to provide documentation

Users react negatively to freezing of software

Comment: Maintain regular reporting to top agency officials

to gain their support and cooperation. Continue

user interface. Involve users in project planning.

o Tracking progress

Project team members fail to maintain records

Project team members fail to use reporting

hierarchy

Tracking mechanism does not adequately track

progress

Project management fails to use tracking

mechanism adequately

Costs not tracked

Comment: Assign reporting responsibilities; review plans and

tracking for flexibility and ease of use. Plans

should be "looseleaf" in nature. Rely on visual

tracking aids.

99
5.18 CONVERSION PREPARATION MANAGEMENT DECISIONS

At the conclusion of the preparation phase, agency executive

approval will be given to proceed with conversion activities. In an actual

conversion environment conversion will commence before all preparation

activities are completed. The actual conversion decision will be based on

a determination that conversion can commence with minimum disruption

due to uncompleted preparations

5.19 ECONOMIC CONSIDERATIONS

Preparation for conversion may require large, one-time

expenditures to activate the software conversion plans. As a result, cost

elements other than personnel may become significant. These include

one-time expenses for the purchase of conversion tools, ADP equipment,

and office furniture and fixtures to accommodate additional conversion

team resources (e.g., contractors). Rentir^ these items may reduce the

magnitude of these costs; however, certain nonrecurring expenses for

freight, installation and site preparation may still occur. Personnel costs

and related occupancy costs will increase during this phase as the project

team is assembled. Items such as moving expenses, new hire expenses,

and office space renovation expenses should not be overlooked.

The software conversion life cycle cost information should

continue to be defined at the same level of detail used during the previous

phase. The cost information should be updated as actual expenses are

incurred. Cost estimates prepared for the conversion phase should be to

reflect the actual expenses of the conversion team assembled during this

phase, and refined to incorporate any changes in project scope or schedules.

The primary use of the software conversion cost information

during this phase is the comparison of actual expenses to cost estimates.

Significant cost variations identified should be reported to top management for early resolution of potential budgetary problems. Equipment,

facilities and conversion tool acquisitions should be evaluated using the

total project cost of the conversion effort to determine the lowest cost

alternative. During this phase minor adjustments in the decision plans

may be made. These adjustments should also be evaluated on the full cost

impact of each alternative to assure the cost-effectiveness of any

changes.

Communication with management and users during this phase

should include cost considerations, such as expenses to-date, projected

budgets, and evaluation of the continued cost-effectiveness of the

proposed conversion effort.

100
CONVERSION PREPARATION MANAGEMENT CHECKLIST

o Conversion preparation budget adequate and approved

o Costs being tracked

o External impacts affecting preparation and conversion

assessed

Conversion project budget changes

Target hardware changes

Other

o Project team reorganized for conversion preparation

o Staffing schedules prepared

o Training plans in effect

o Software conversion RFP

Prepared

Issued

Negotiated

Contractor selected

Contractor/project management coordination

o Automated tools acquired

Contractor developed

In-house developed

o Staff trained in tool use

o Conversion project team

Notified

Briefed

Responsibilities assigned

Assembled and located

Trained

o Conversion facilities obtained

Computer support

Terminals

Team informed of procedures

101
Test data and files available and tested

Information system user input

Software development frozen (if possible)

Change control procedures in effect

Programs modified as required prior to conversion

Documentation completed

Continuous and ongoing coordination and reporting with

Top management

Information system users Hardware staff

Plan tracking in effect

Contingency plans reviewed for effectiveness, remedial

action taken

Costs being tracked

Cost estimates refined for future use Extraordinary costs reported to agency executives

Conversion budget and preparations reviewed

Agency decision to convert

102
SECTION 6

THE CONVERSION PHASE

During the conversion phase the adequacy of planning,

organization, and project management is revealed. The conversion phase

also provides the opportunity to develop a software posture which will

directly affect the success of any future conversions.

6.1 OBJECTIVE

The objective of the conversion phase is to complete the

conversion as effectively as possible in the time provided, and within

authorized budget limitations. While the objective is simply stated, the

decisions, organization, and activities that relate to attaining this

objective are complex and wiU require continuing and involved project

man^ement attention throughout the effort.

6.2 CONVERSION PHASE ACTIVITIES

Figure 6-1 illustrates the major activities that occur during

conversion. These are:

o Team management, organization and staffing, o External interface and coordination, o Training, o Security considerations, o Software conversion, o Unit and systems testing, o Parallel testing and crossover, o Documentation.

These activities will be discussed in subsequent portions of this section.

The purpose of the discussion is not to provide managers minute, technical

details associated with the various functions, e.g., software testing. Many

technical references exist to provide this information if the experience is lacking in the project management or project team staffs. Rather, the

intention is to provide managers an understanding of the functional

relationships and the management considerations that apply to preclude or reduce problems during conversion and achieve the goal of an efficient

and effective software conversion.

103
MANAGING CONVERSION TEAM

COMPOSITION AND ASSIGNMENTS

EXTERNAL INTERFACE & COORDINATION

TRAINING

SOFTWARE CONVERSION

SYSTEMS TESTING

PARALLEL TESTING - UNIT TESTING

DOCUMENTATION

CONVERSION TERMINATION DECISION T

MANAGEMENT DECISION

CONVERSION PHASE ACTIVITIES

Figure 6-1

SYSTEMS TESTING - UNIT TESTING

104
6.3 MANAGEMENT, ORGANIZATION AND STAFFING

Managing the skill mix and composition of the project team

will be the biggest management challenge during the conversion phase.

There are multidimensional variables of skills, numbers of personnel, and

time requirements. See Figure 6-2.

6.3.1 TEAM COMPOSITION

During the software conversion phase the project team will be

composed of analysts and programmers augmented or assisted by systems

programmers, training personnel, system operators, security personnel and

information systems users. The skill mix is usually made up of in-house

personnel as weU as consultants and contractors in levels of effort

established during the requirements phase and applied accordir^ to conversion plans and schedules.

Initially the project team consists primarily of analysts and

programmers. As unit testing is implemented, systems operators and

programmers will assist.

Midway through the conversion, information systems users wiU

be assisting in system and initial parallel testing. Security personnel and

information systems users will be assisting in software verification and

validating achievement of security and privacy software requirements.

Input from data entry personnel, tape and disk libraries and input/output

staff members wiU permit the project manager to develop efficient

procedures during parallel testing and refine user and operator manuals.

In the later stages of the conversion, as applications on the

new system complete parallel testing and are accepted by users, the need

for analysts and programmers converting code diminishes. Project team

activities are primarily associated with parallel testing, software security

certification, user acceptance and documentation. As people are no

longer required in conversion activities, they revert back to normal

duties.

6.3.2 PROJECT TEAM ASSIGNMENTS

Assignments and schedules for the conversion project team

will have been issued during conversion preparations. However, new staff

members, including contractors, will most likely be required to replace

personnel losses or applied to resolve unexpected problems as a result of

contingency planning. Providing these new additions written instructions on their project duties, responsibilities and reporting procedures will

facilitate their integration into the project effort.

105
KH>O

V)Sa

COsDZQZ<

CO

•J

•J

CO

<.HHZo

CO

o;>ZouHB<HhO

CO

CMI COo9

DO

COM c O o

"S *J"1c

cn cQ >

>. »H

4-' c 2 o

"c oo < Oi

106
6^.3 PROJECT TEAM INTERNAL INTERFACE

During conversion, project meetings are particularly important

to keep the entire team appraised of status. On large conversions the

total staff involvement at any one time can be 30-40 personnel Team

meetings of this size are impractical on a day-to-day basis. Periodically

(e.g., on a weekly basis) the team should be apprised of progress or status.

The project manager should hold more frequent meetings, probably daily,

with task leaders to coordinate conversion activities.

The press of conversion activities will create tendencies to

cancel or postpone meetings with the team or task leaders. This should be

avoided. Besides keeping the project staff informed of status, meetings

assist in developing a team spirit and sense of belonging to an

organization in an otherwise ad hoc assembled group of personnel. Most

importantly, since management commonly assigns hi^h quality talent to conversion team duties, meetings can focus considerable talent and

experience on means to resolve problems that may arise.

Conversion team leaders and designated specialists working on

specific conversion tasks should be inputting status to tracking

mechanisms established for project controL There will be a tendency for

members to delay this input due to the press of business. Project

managers wiU have recurring needs for status information quickly in order

to respond to top management requests or to respond to inquiries

originating outside the agency (e.g., GSA). Project managers should

therefore monitor the degree of currency of project status information

and discipline or revise the tracking procedures if information currency

slips.

Graphics, such as bar charts, should be used at the team level

since they visually aid the project mane^er and the team in deter minir^

status. Conversion task leaders and other specialists (e.g., security) also

will be inputting status and historical information into a history log. This

log should be in looseleaf form but organized in some fashion which wiU

support the post conversion analyses. The format described in Section 7 for the analysis report is suggested. In addition to its historical

significance, this log will be useful to newly-assigned team members in

gaining an overview and understanding of project objectives and status.

6.4 EXTERNAL INTERFACE AND COORDINATION

During conversion regular and continuous interface is required

with agency executives, functional information systems users, hardware

operations personnel and any contractors employed for software

conversion.

107
6.4.1 AGENCY EXECUTIVES

Regular project briefings and other status reporting

mechanisms, established and ongoing from project initiation, are critical

during the conversion phase. Although contingency and other planning

should have precluded many problems arising during the conversion phase, no conversion will be 100% devoid of problems. Significant, unforeseen

problems ^ould be expected due to influences outside the control of the

agency, ADP or project manager. Prime examples which have affected

Federal conversions include budget cuts and hiring freezes. If contingency planning has not provided the project manager the flexibility to deal with these problems, support of top management will be required.

6.4.2 INFORMATION SYSTEMS USERS

Close and continuous interface will be required with functional

information system users during conversion. Their support to conversion

efforts is critical during this phase.

Information systems users will assist the project team in

system and parallel testing. Additionally, if security or privacy features

have been engineered into software, users will have to assist in security

verification and software accreditation procedures. Project managers can

expect that busy users will experience some inconvenience as a result of

conversion activities. Their continuing support will be directly related to rapport established prior to actual conversion.

User interface is most important in freezir^ new software

developments during conversion. Frozen software reduces many problems

for the project manner. User and top managment support in freezir^

development will have been achieved during prior conversion phases.

However, since the time of actual conversion can be quite ler^thy,

extending over a year in large conversions, project managers can expect

impatience and some support to wane for postponing new enhancements.

Attention to developing conversion priorities and schedules, approved by

users during the planning phase and adherence to these schedules during

conversion will build confidence among users that their inconvenience in

obtaining new enhancements will be minimaL If new enhancements

cannot be avoided, change control procedures can reduce the trauma of

converting dynamic systems and programs.

6.4.3 HARDWARE AND OPERATIONS STAFF INTERFACE

Considerable support will be required from the operations

staff particularly during testing. Although testing can be planned and

scheduled, actual testing will require many schedule modifications as software systems are debugged. These schedule changes will

inconvenience the operations staff. Project managers should encourage

participation of operations staff members at project meetings to promote

operations staff cooperation and encourage their input on day to day

scheduling adjustments.

108
6.4.4 CONTRACTOR INTERFACE

Planning for conversion with large contractor software

conversion efforts ^ould have provided a COTR on the project managers

staff and a contractor project officer. If this has been accomplished, the

day to day interface necessary to keep contractual efforts on track with

in-house conversion actions will be facilitated.

6.5 TRAINING

Most of the training for conversion was accomplished in the

previous phase, conversion preparation. Nevertheless some training will

be required in the conversion phase.

If newly assigned personnel are applied to the conversion team

to replace unexpected losses, they will have to be trained in their duties.

Additionally, there will be ongoing, ad hoc training requirements to operators, data librarians and data entry personnel as operating

procedures are refined during testing. This training is normally

accomplished by members of the project team. Project managers should ensure that the necessary procedures and documentation (e.g., operations

manuals) are developed and used in conjunction with this trainingInformation systems users normally do not require extensive

training unless new functional changes are included in the converted

software. Some user training may be required when users assist in

systems testing. During parallel testing users will have to be trained to the extent that they can differentiate between and compare the source and target hardware production runs.

6.6 SECURITY CONSIDERATIONS

The project manager, working in conjunction with the agency

information system security official and the information systems users

will ensure that the design reviews are conducted during systems testing

and that sensitive systems are carefully monitored for security during

parallel testing. In accordance with 0MB Circular A-71, the sensitive

information systems will require certification at the completion of

systems testing by the information systems security officer or agency

official designated to certify that the systems meet the documented and

approved system security specifications, meet all applicable Federal

policies, regulations and standards, and that test results demonstrate that

the security provisions are adequate.

6.7 THE SOFTWARE CONVERSION

Software will be converted in-house, by contractor, or a combination of the two, using schedules and work packages developed

during planning and preparation activities.

109
6.7.1 IN-HOUSE CONVERSION

The first source programs to be converted should be the most

complex or those that have been frequently modified. Complex programs

force project team members to become thoroughly familiar with the new

software If there are going to be software problems which could result in

serious slippage, management is provided an early awareness of this

condition and can apply remedial actions. Frequently-modified programs

are the most complex as a result of the modifications. They are also

normally associated with information systems of high user interest.

Giving these priority, converting them first, and placing them in an

operational mode avoids user pressures to incorporate new enhancements

during conversion.

If new enhancements cannot be avoided, one method of

minimizing the effect of modification during the conversion is to

implement change control procedures which carefully record all changes.

Duplicate work packages, go the the project team and the other to the

maintenance programmeKs). The maintenance programmers continue to

make changes as the frozen programs are converted. Changes to the

converted program are added later (23).

6.7.2 APPROACHES

The conversion approaches taken by the project team are team

conversion, individual conversion or a combination. The project team

members will employ the previously-decided techniques of manually

converting code on a line-for-line basis, reprogramming, redesign, the use

of automated tools, or a combination of the four methods. Selection of

the approach will be an ^ency management decision based upon available

personnel resources, skills and experience, time available, and desired

performance of the converted programs.

6.7.2.1 Team Conversion

With team conversion, each member of the team is assigned

either Control Stream Langue^e (CSL), data files, or source programs.

One person or group of people is in chaise of converting all CSL, another

handles all data files, and a third converts all source programs. The

teams differ in size as dictated by the conversion workload. Also, the

skills required of the team members would differ. The CSL and data file

teams need not be trained in application program languages, e.g, COBOL,

Assembly Lar^uage, FORTRAN, etc. The advantage of this approach is the facility in developing conversion staff skiUs. Each team has only to

become experienced in specific rather than broad software skill areas. The expertise in each area will be more quickly acquired and applied.

Each team C6in develop expertise in the other areas later, as time permits.

110
6.7.2.2 Individual Approach

With the individual approach, each person converts all aspects

of the system in his/her realm of responsibility: CSL, data files, and

source programs. For shared data files, conversion responsibility should

be assigned to one person. The advantt^e of this approach is that

individuals become familiar with the total requirements of the individual

systems. The responsible person can often anticipate and resolve some

problems which might arise based on this insight. The disadvantage of

this approach is that it takes longer to develop all the skills associated

with system conversion rather than one particular area of expertise, e.g., CSL.

6.7.2.3 Modified Approach

The modified approach is a combination of the two. An

example would be team conversions of CSL and data files. Application

programs would be converted by a functionally-knowledgeable project

team member. This approach permits tailorir^ existing resources and

skills to agency conversion needs.

6.7.3 CONTRACTOR CONVERSION

With contractor conversion of the source code, the project

manager is less concerned with the approach. The mans^ement concerns,

instead, are contract management and issues associated with timely

delivery, quality and documentation of software.

6.7.4 QUALITY

Converted software should be closely reviewed for quality.

The pressures on personnel during conversion to meet the conversion

schedule, may cause project team members to retain unnecessary or unoptimized code (48). The conversion phase provides the opportunity to

develop well engineered source programs based on modem techniques of

software engineering (39, 42, 43). It is also an opportunity to design out

old routines which require operator intervention but, due to technical

evolution of hardware, are not applicable on the new system. It is particularly important for contractually-converted software to be

examined for quality and performance to ensure converted systems

execute in acceptable run times. The project manager should regularly

schedule and conduct structured walk-throughs of all conversion projects

and similarly examine contractually-converted software.

6.8 UNIT AND SYSTEMS TESTING

Initial testing is normally accomplished in two

steps: individual application program and file (unit) testing, and system

testing (see Figure 6-3). Managers will have to schedule or arrange

supplies and paper stock, machine time, operators, test data, system

111
Application

Program

Conversion

File

Conversion

I

r Converted

Programs

/ Unit \

1 ^^^^ 1

1 ^ ^T"

m ^,—~

System

Testing

Pass to Parallel Testing

TESTING SCHEDULE

Figure 6-3

112
programmers, and possibly, during systems testing, user involvement.

Test criteria should be established beforehand. The test criteria shouldinclude performance factors that relate to the desired level of quality, be

used to evaluate individual or contractor performance, and ensure that

cost-effective results are being obtained.

6.8.1 UNIT TESTING

Individual data files should be tested to ensure that they have

been 100 percent converted. Individual application programs require

testing to ensure that the code is executed. The adequacy of this testing

depends upon the quality of test data. The ultimate objective is 100

percent testing of code execution. While this objective is realistically

unattainable, the project manner is encouraged to continually refine test

data towards achieving that objective.

6.8.2 SYSTEMS TESTING

After unit testing of programs and files are completed they are subjected to systems testing. The purpose of this testir^ is to ensure

that the systems operate adequately on the target hardware. Systems

test data consist of representative production runs with appropriate

performance consideration taken into account. All systems documentation should be written in an acceptable draft state by the end of systems

testing. Systems testing will involve information systems user

participation to verify the acceptability of new input and output

procedures.

6.8.3 TESTING PROBLEMS

6.8.3.1 Assembly Language and Utilities

Project managers should be prepared to handle serious

problems during systems testing if the agency converts from Assembly

Language on a saturated machine or has made extensive use of vendor

unique utilities. Unacceptable run times can occur which require redesign

or extensive reprogramming.

6.8.3.2 Testing Shortcuts

Quality test data is extremely important and difficult to

develop and maintain (48). Managers should resist test data shortcuts as an expedient of avoiding the need to develop different test packages,

however.

Unit test data should not be used for systems testing. Unit

test data is designed to exercise the converted code. The systems test

data is derived from, and represents typical production runs. The test

data construction is different. The project mane^er should also resist

accepting code for systems integration testing that has not completely

113
fulfilled unit code execution tests. The manager should likewise not put

code into a parallel testing mode that has not been fully tested and

debugged during systems testing. Shortcuts in testing due to pressures of

conversion only defer problems to the later stages of software conversion.

Testing problems need to be resolved as early as possible to preclude an unmanageable situation in which cumulative testing problems have to be

addressed and solved late in the conversion phase. Unit and systems

testing reduce to a minimum software problems that will come to the

attention of the functional user during parallel testing. A low incidence

of errors in production runs inspires user confidence and support.

6.8.3.3 Production Interference

Because it is difficult to forecast exactly the machine time

and other resources required for actual testing, management will have to

maintain close coordination with operations personnel and users to gain

their support and cooperation to alleviate unexpected testing problems

that place an unplanned burden on normal operations.

6.9 PARALLEL TESTING AND CROSSOVER

Durir^ parallel testing the project manager is going to be

concerned with running the old and new systems in a parallel production

mode to ensure that conversion has been accomplished.

A management problem exists for those applications that are

infrequently processed (e.g, fiscal year end summaries). It may be

impractical to continue parallel testing long enough to compare all long

term applications. The objective wiU be to achieve user's confidence, crossover to the new system, and remove the old hardware in order to

reduce costs associated with parallel testing or back-up processing. When

all systems have been or are undergoing parallel testing, a firm

completion date must be established to force an end to the conversion

project.

As systems complete parallel testing it is important that users formally acknowledge acceptance. This provides a basis of understanding

between the users and the project manager that conversion of the systems

has been successful.

6.10 DOCUMENTATION

The project manager should demand software documentation

in accordance with ^ency or FIPS standards. Managers should be

especially cautious regarding documentation associated with that

software converted by a contractor (42). The normal form for delivery of

contractually-converted software is in an undocumented state. Managers

should anticipate that even if contracts require documentation, the

contractor may be unfamiliar with documentation standards, may have

underestimated resources and may try to avoid or modify contractual

documentation requirements.

114
6.11 CONVERSION MANAGEMENT DECISIONS

The conversion phase is over when the last system completes

parallel testing and documentation is completed. Upon assurance that users have accepted the converted information systems, agency

executives will approve project management recommendations to

implement post-conversion activities to restructure the software

conversion project team to a normal operational mode, close out software

conversion contracts, vacate or release any conversion facilities and

equipment no longer required, and to conduct a post-conversion analysis

of the conversion project.

It is recommended that these decisions be based on recommendations presented as part of a formal briefing to top agency

managers and information system users. This will lend assurance that

conversion has been successfully executed and keep man^ement informed

of the conversion activities that are required during the post-conversion

phase.

6.12 ECONOMIC CONSIDERATIONS

During the conversion phase the major elements of cost will be

personnel-related. Hardware and telecommunications expenses may

become significant during this phase for file and program conversion and

testing. These expenses may be reflected by direct hardware rental costs

of indirect time-sharing charges. If the software conversion effort uses

existing ADP resources, the costs of these resources should be identified

and allocated to the conversion effort on a fuU cost-basis. The cost of

using contractors should be estimated and recorded according to the

detailed cost structure approach presented in Appendix C. In this manner,

contractor costs should be detailed by cost element; i.e., personnel,

facilities, hardware, overhead, profit, etc. for each conversion activity or function, and not given as a lump sum contract service expense. With this

cost breakdown, the technical evaluation of contractor's performance will

be possible.

Actual cost performance should be collected and recorded in

the cost structure for use in post-conversion audits.

The use of the software conversion cost information is mainly

in the tracking of project costs and the comparison of actual cost to cost

estimates to identify significant cost variations. Communications with

users and top management should include cost information such as expenses to-date, budget projections, and an evaluation of the costeffectiveness of the project. Minor charges in project schedules and the

allocation of in-house or contractor resources to specific tasks should be

performed with consideration of cost impacts. This project refinement

activity should include an assessment of each alternative on the full cost

of conversion in order to address the lowest total overall cost.

115
CONVERSION PHASE MANAGEMENT CHECKLIST

o Conversion team

Located in facilities

Requisite skills and experience available

Team members aware of schedules, duties and

responsibilities

o Interface continuing with

Agency executives

Information systems users Hardware operations staff

Contractor project officer

o Project status being tracked

o Project status current

o Project reports current

At project level

At agency executive level

o Training being accomplished

New hires on project team

Ad hoc to users, operators, etc.

o Security

Features implemented in software; verified

Monitored by information system security officer; users Software certified by information system security

officer, lAW 0MB Circular A-71

Most complex software being converted fi''st Change control procedures established for

conversion of software with new enhancements

Conversion team members following established

security procedures

o Contract being monitored; quality of software and

documentation assured

o Unit and systems test data separate

o Files 100% converted

116
Software converted to level of acceptable code

execution

Users participating in systems and parallel testing

Close interface with hardware operations staff during

testify

Users formally accepting systems at completion of

parallel testing

Firm parallel testing end date established to force

project end

Agency executives and users approve end of the

conversion phase

Agency executives approve post conversion phase

activities

Settling staff into normal software operations

Close-out contract

Post conversion analyses and assessment

117
SECTION 7

THE POST-CONVERSION PHASE

Post-conversion is the phase of a software conversion life

cycle between actual conversions. It extends for an indeterminate but

considerable period of time, generally 2 to 5 years, depending upon the

frequency of hardware replacement. This phase provides the best

opportunities to learn from fresh conversion experiences and to initiate

actions which will improve the utility and effectiveness of an agency's

software and concomitantly facilitate future software conversions.

Additionally the true costs of conversion are most apparent in

this phase if costs have been tracked. Differences between estimated and

actual costs can be identified and evaluated. These evaluations can then

lead to better cost estimating in future conversions.

7.1 OBJECTIVES

There are two objectives in the post-conversion phase:

o Reestablish the agency software organization in a normal operating environment. The associated activities are to complete any functions from the software

conversion phase which remain undone (e.g.,

documentation, completion of parallel testing); settle

the software staff in a normal organizational structure;

and begin normal software maintenance and development

actions.

o Develop a better agency posture for future software

conversions. The agency should conduct a postconversion assessment of the conversion experience;

begin planning for the next conversion; and initiate

actions which will cause the next conversion to be more

effective and efficient.

7.2 POST-CONVERSION ACTIVITIES

Figure 7-1 illustrates the major activities that occur during

the post-conversion phase. Many of these activities are closely related

and have much overlap, particularly those that pertain to the postconversion analysis and assessment, plsinning, and conversion improvement

techniques. These activities provide the framework for subsequent

discussions in this section which provide an understanding of the postconversion management issues. This general understanding will assist

118
CONVERSION TERMINATION/TRANSITION

COST TRACKING

POST CONVERSION ANALYSIS AND ASSESSMENT

PROJECT TERMINATION

FUTURE CONVERSION PLANNING & PREPARATION

T

MANAGEMENT DECISION T

POST CONVERSION ACTIVITIES

Figure 7-1

119
managers in identifying other post-conversion functions that pertain to

their particular agency software conversion environment and form a base on which to build or implement actual post-conversion plans and actions

to improve future conversions.

Post-conversion activities can be generally grouped into three

categories:

o Conversion Termination/Transition Activities

These are transition activities between a conversion

environment and a normal software maintenance and

development environment. Typical activities include

finishing parallel testing, completing documentation,

closing out software conversion contracts, disbanding the

project team, and settling the agency software staff into a normal software organization (e.g., systems

programming, maintenance programming, developmental

programming).

o Post-Conversion Analysis and Assessment Activities

These activities involve conduct of a thorough review

and analysis of the entire conversion experience and

preparation of a formal after-action report. This

document will provide managers a historical perspective

of the conversion, and assist in understanding future

conversions and ways to avoid repetitious mistakes. It also provides a reference on which to base the closelyrelated activities of future conversion planning and

implementing actions to improve future conversions.

o Future Conversion Planning and Conversion Enhancement Techniques

Early initiation of future conversion planning reinforces

the recent conversion lessons learned and significantly

improves management's ability to comprehend all the

issues of future conversion. Management can also

implement and enforce many techniques and procedures

which will improve the quality of the agency software

and, at the same time increase software portability.

These methods include use of modern software

engineering techniques of structured design and

programming, maintaining current documentation,

avoiding the use of non-standard programming languages

and vendor unique utilities, maintaining high quality test

data and files, and maintaining disciplined program files

and data bases.

120
7.3 CONVERSION TERMINATION/TRANSITION ACTIVITIES

In a theoretical conversion, activities associated with the

conversion phase would have been completed before the post-conversion

phase began. In a real situation activities of one phase extend into

another. The most significant on going functions of the conversion phase

that are likely to extend into the post-conversion phase are parallel

testing and documentation. Activities such as closing out contracts and

disbanding the conversion team wiU be more transitionary. Still other

activities such as commencing new user enhancements postponed until

after conversion approach true post conversion activities.

7.3.1 COMPLETION OF PARALLEL TESTING

Software is converted on a prioritized, scheduled basis

according to conversion plans. Thus, in the initial stages of the postconversion phase all of the software will have been converted. However,

for those software applications converted last, some residual testing,

particularly parallel testing, wiU likely stiU be on going.

The management issue here is to strike a balance between

continuir^ parallel testing to ensure that the converted software meets

functional user requirements, while at the same time, avoiding protracted

or unduly long parallel testing and operations. Parallel testing is costly in

terms of dollars and staff resources. As long as parallel testing and

operations persist, transition to a normal software environment cannot be

accomplished. Therefore managers should closely examine parallel

testir^ with a continual involvement to determine if the seemingly

endless details of parallel testing outweigh the benefits of maintaining

two hardware operating environments. Project managers may have lost

the perspective to make this judgement. Upper management must be

prepared to exercise "brute force" decisions to terminate parallel testing.

7.3.2 DOCUMENTATION

Software documentation should be written concurrently while

converting software. However, during the later stages of the software

conversion phase, documentation efforts may fall behind and extend into

the post-conversion phase. Also, some documentation modifications will

be required due to changes or modifications to converted software as a

result of final parallel testing.

Although documentation may extend into the post-conversion

phase, it is critical that management ensure completion before total

transition of software operations to a normal state. Software that is not

documented tends to remain undocumented and this creates a continuing source of problems (23).

121
7.3.3 CLOSING OUT CONTRACTS

If contract services have been used to convert software or to

augment the conversion team staff, the project manager will be involved

in contract close-out activities. If extensive contractual support was

used, contract close-out will be significantly aided if the software

conversion project management team has a full-time COTR to assist in

contract functions (48).

Contract monitoring should have been an ongoing function

throughout the conversion process. During the post-conversion phase, the

Statement Of Work (SOW) should be reviewed and compared with the

deliverables to ensure that contractual obligations have been met. Actual

cost performance should be compared against original estimates to

determine contractual awards or penalties. Software deliverables should

also be examined for quality and fully supported by documentation that is well written, usable and conforms to agency standards or FIPS PUB 38

and 64.

Contractual issues and disputes should be resolved informally

whenever possible, or if necessary, formally through the contracting

office. A full assessment of contractual costs and obligations should be

conducted to assure that the agency received fuU benefit of services and

to surface and resolve outstanding cost issues, thus avoiding any prolonged

contractual disputes which would detract from normal operations. When

all contractual issues have been resolved, the contracting office should be

notified, in accordance with agency procedures, to close-out the contract.

The key management concerns are to ensure that contractual

obligations have been fulfilled, and potential or actual problems or issues

identified and resolved as expeditiously as possible in order to accomplish

a speedy transition to normal software operations.

7.3.4 DISBANDING THE PROJECT TEAM

As parallel testing and documentation is completed, remaining

members of the project team should be released. Those team members

who are normally part of the agency software staff will revert to normal

duties. Since large scale conversions frequently last in excess of one year

the "normal" duties might be quite new. For example, personnel turnover

might have resulted in newly-hired personnel being assigned directly to

the conversion team. For these people, there will have been no previous

experience in agency day-to-day operations. They must be assisted in

adapting to the normal environment.

Requirements for reorganization of the agency software staff

may also impact disbanding the project team. Agency growth or functional changes may have altered the authorized staffing level or skill

mix of the software staff. Differences in the source and target computer

systems may also have generated a need to restructure the software staff.

122
Management problems in settling the agency software staff

into a normal operational mode can be reduced by informing all

conversion team personnel of the normal agency software organization,

and providing current duty descriptions, and internal operating

instructions. Training can also be of assistance particularly if the project

members worked only on specialized conversion tasks (e.g., only converted

job stream language).

7.3.5 NEW USER ENHANCEMENTS

User information system enhancements, deferred until after

conversion, will commence. Because of the length of some software

conversions, some application software may have multiple change

requirements. Information system software changes and enhancements

should be carefully analyzed. It may be cost-effective to redesign

systems, and to incorporate aii cnanges at once, rather than patching

them into the old system structures. Also, if there are many

enhancements required, priorities will have to be established. Priority

assignments will require functional user involvement and top management

decisions and support.

The management issues include identifying and establishing

priorities for developing new user enhancements and determining the most

cost-effective approach for accomplishment. Managers should also ensure

that aU software changes are accompanied by appropriate changes in

system documentation.

7.4 COST-TRACKING

During the post-conversion phase, tracking conversion related

costs as they are incurred on a day-to-day basis is important to reflect

total conversion costs in the post-conversion analysis and assessment.

Operational cost items associated with the post-conversion

phase include, but are not limited to:

o Staffing - Staff resources devoted to conversion-related

actions as opposed to normal operations (e.g., costs

associated with disbanding the project team and

resettling the normal software staff; training).

o Contractual - Costs associated with closing out

contractor support.

0 Computer and Facility - Costs associated with residual

conversion functions such as completion of parallel

testing and residual use of facilities by the project team.

123
o Administrative - Costs associated with clerical and

administrative support to the project management and

project teams; particularly the administrative support

associated with the post-conversion analysis and assess- ment and future plan development. Documentation

production will also incur administrative costs.

7.5 POST-CONVERSION ANALYSIS AND ASSESSMENT

One of the most important post-conversion functions is an

analysis of the entire software conversion experience. The time and

resources required to conduct the analysis and assessment depend upon

the magnitude of the software conversion project. A medium to large

conversion project assessment might involve 2-3 people for 2-3 months.

The analysis should be conducted by the project manager and the project

management team with input solicited from parties that had an important

interest or role in the software conversion (e.g., the contractor, project

team, hardware acquisition staff, involved functional users). The most

important sources should be conversion history logs maintained on an

ongoing basis during the software conversion and the knowledge and

experience of the project management team that remained intact during

the entire conversion experience.

It is important that the post-conversion be conducted in a

positive manner. It should not simply be a list of problems or shortcomings encountered during conversion. The assessment should

describe the entire process and identify those procedures that were

satisfactory and effective as well as those that were less than

satisfactory. It should offer future software conversion managers

suggestions and recommendations to improve their conversion efforts.

The assessment should identify how the agency can plan, now, for future

conversions; ongoing software practices and procedures to improve future

conversions; and other actions (e.g., policy change recommendations ) which may be required.

7.5.1 POST ANALYSIS REPORT

A post-conversion analysis report should be produced as a formal document. It serves four important agency purposes.

o Historical Reference

The report provides a historical reference for agency

personnel to use in future software conversions. The

identification of problem areas and solutions should

provide future software conversion managers insight and

enable them to better manage and execute a software

conversion.

124
o Conversion Costs

The report displays actual conversion costs. If the

software conversion cost structure, detailed in Appendix

C, has been used throughout the project, the report will

reflect all costs including those frequently overlooked or disregarded by managers. For example, the costs of

assigned staff personnel, particularly those involved in

conversion part-time, are frequently overlooked;

conversion costs related to parallel testing, particularly

with government-owned machines are not fully

considered; the full extent of training costs (e.g.,

training time) tends to be underestimated.

o Basis for Software Conversion Planning

Planning for software conversion should be an ongoing

activity and not solely relegated to a planning phase

immediately preceding an actual conversion. Continued

planning for the eventual software conversion can

shorten the planning time span when a conversion

decision is made, provide more detailed and

comprehensive plans, and improve the overall conversion

process. The report provides insight on how to structure

the planning.

o Identify Ongoing Actions or Procedures to Improve

Conversion

There are many actions and procedures managers can implement and enforce which will improve the posture of an agency to conduct a cost-effective conversion. The

report, by identifying these actions and their

importance, assists agency personnel in understanding

the need for these procedures and encourages

implementation.

7.5.2 ANALYSIS CONSIDERATIONS

Elements to be considered in the post-conversion assessment

will depend upon the software environment of the particular agency.

However, the following are generally applicable.

o Planning

Adequacy of feasibility study

Adequacy of software conversion study

Impact of other studies (e.g., A-76, A-109)

Adequacy of planning time

Sufficiency of detail

125
Adequacy of tracking and management followthrough

Adequacy of cost estimates

Planning problems, their resolution and means of

avoidance

Future planning requirements

Staffing and Organization

Adequacy of project management team

Adequacy of project team

Skill mix

Proper location of conversion staff

Adequacy of conversion assignments and control

Staffing and organization problems, their

resolution, and means of avoidance

Future planning requirements

Use of Contractors

Requirements for contractors

Their optimum employment

Adequacy of the Request for Proposal

Adequacy of contract monitoring

Adequacy of deliverables and services

Contractor problems, their resolution and means of

avoidance

Future planning requirements

Software Conversion

Selection, use and adequacy of automated tools and

techniques

Conversion of languages

Conversion of utilities and procedures

Conversion problems, their resolution and means of

avoidance

Future planning needs

Hardware Staff Interface

Adequacy of hardware acquisition staff interface

Adequacy of conversion support

Conversion problems, their resolution and means of

avoidance

Future planning requirements

Facilities

Adequacy of facilities

Success in single site/dual site conversion

Facility requirements and use

126
Documentation

Adequacy of pre- and post-conversion documentation

The use of documentation

Adequacy of agency documentation standards

Documentation problems, their resolution and

means of avoidance

Future planning requirements

Test Data and Files

Employment of test data and files

Adequacy of test data and files

Optimization of test data and files

Development responsibility for test data and files

Test data and file problems, their resolution, and

means of avoidance

Future planning requirements

Training

Adequacy of training

Timeliness of training

How training was conducted

Training problems, their resolution and means of

avoidance

Future planning requirements

Security

Agency specific security and privacy requirements

Adequacy of security and privacy software

conversion activities

Extent of unresolved security or privacy software

issues

Security and privacy problems, their resolution,

and means of avoidance

Future planning requirements

Distributed and Remote Sites

Adequacy of planning

Interface

Adequacy of software conversion

Specific problems, their resolution and means of

avoidance

Future pleuining requirements

127
Telecom munieations

Adequacy of telecommunications planning

Adequacy of telecommunications staff support

Conversion-related problems, resolution, means of

avoidance

Future planning considerations

Top Management and Functional Users

Their support of conversion

Freezing development of new user enhancements

Their roles and involvement in conversion

High level management and user conversionrelated problems, their resolution, and means of

avoidance

Future planning requirements

Directives and Policy

Adequacy of directives and policy

Conflicts in directives and policy

Responsibility for directives and policy conflict

resolution

Future planning considerations

Unforeseen Problems

Unforeseen problems, their resolution, and means

of avoidance

Future planning considerations

Software Conversion Management

If not otherwise addressed, cover shortcomings or support from software conversion management that

affected other related projects or operations.

Telecommunications

Hardware acquisition

Hardware operations

Information system users Agency executives

Budgets and plans

Costs

Actual conversion costs by phase, function and cost

element

Total conversion costs

128
Adequacy and source of funding

Adequacy of budgeting

Comparison of cost estimates to actuals

Adequacy of cost analyses

Cost overrun detail and reasons Conversion cost related problems, their resolution

and means of avoidance

Future planning considerations

7.6 PLANNING AND INITIATING ACTIONS TO IMPROVE

FUTURE CONVERSIONS

Future software conversions can be made more efficient and

effective through employment of a combination of planning and

procedures that encourage easily maintainable software and its

conversion. Some activities can be specifically identified as pure planning — i.e., conversion planning input into agency ADP budget submissions

required by 0MB Circular A-11. This is long-range planning. At the

agency software operations level, some software conversion improvement

actions will be planned and implemented. This is technical planning and it will differ among agencies. Practices conducive to efficient software

conversion such as disciplined documentation may be firmly established

and on-going at one agency and require no planning, only continued

implementation. At another agency, however, a documentation standards

policy may have to be planned and implemented. If managers pursue both

long-range and technical conversion planning, future conversions will be

much simplified.

7.6.1 LONG-RANGE CONVERSION PLANNING

Long-range planning is based on costs. The cost estimatir^,

analysis and tracking experience gained in the recent conversion, if continually refined during the post conversion phase, can assist managers

in estimating correct levels of conversion resources. If the project

manager has been following a total cost estimating methodology as recommended in Appendix C, the structure can be transferred to agency

personnel who are routinely involved in long-range planning.

Planning full costing methcJology permits an agency to

analyze costs from different dimensions. For example, costs can be

developed for personnel, by phase, year, or for a total conversion project.

Alternatively, all costs of conversion (e.g., personnel, equipment, etc.) can be developed by phase or by year. This methodology will produce

consistent cost estimates from whatever perspective they are examined

(e.g., full costs of programmers will result in the same total if they are developed by year or by phase). This consistency results in significant

advantages for an agency by precluding conflicting cost estimates and

providing credibility to agency plans, studies and budgets.

129
7.6.1.1 Agency Long-Range Plans

Office of Management and Budget Circular A-11 requires

agencies to prepare and submit annual agency-wide ADP plans which

support budget estimate submissions covering at least five years. Since

federal hardware is replaced every 7-8 years and conversion time of 1-3

years are incorporated in that span, software conversion planning will be

required in the majority of agency plans.

7.6.1.2 Input To GSA

General Services Administration CFR Part 101-35 also

requires GSA be furnished a copy of the agency long-rar^e plan developed

to support budget submissions with supplementary information addressing:

o Trends in data processing workloads that will or may

saturate existing ADP systems capabilities prior to

expiration of the anticipated systems life,

o Opportunities to take advantage of cost-effective

enhancements brought about as a result of hardware

technology and software improvements,

o System redesign or conversion activities planned or in

process to improve efficiency.

This supplementary annual input to GSA illustrates the need to

maintain continued software conversion planning based on costs. AU plans

and input will have to be addressed in terms of cost impacts.

7.6.1.3 A-76 Studies

ADP is considered a commercial and industrial type activity.

0MB Circular A-76 requires specific evaluation of these activities

annually as well as at the time of major change to determine if government ADP services and functions could be cost-effectively assumed

by a contractor. Major agency conversions or hardware acquisitions are

usually preceded by an A-76 study. Software conversion planning input

based on full costing is required.

7.6.1.4 A-109 Studies

An agency may consider a hardware replacement a major

systems acquisition falling under the provisions of 0MB Circular A-109.

Software conversion planning input will be required to develop the mission

need for the system, analysis of alternatives, and selection of a final

system.

130
7.6.1.5 The Next Conversion

Ongoing, long-term planning for conversion will provide the

details and methodology already in place to support future conversion

feasibility studies, software conversion studies and conversion planning.

An agency will thereby be in a position to complete a future conversion

project in a much shorter time span than required for current projects.

7.6.2 CONVERSION TECHNICAL PLANNING AND ACTIONS TO

IMPROVE FUTURE CONVERSIONS

During the post-conversion phase many actions and procedures can be planned or implemented by management to improve future

conversions. These procedures should be either established agency

practices or implementation of ongoing conversion plans. Most of these

procedures are synonymous with disciplined software management and

should be implemented and enforced regardless of their role in future

conversions.

The f'^Uowing technical planning considerations that can be

applied or enforced during the post-conversion phase were developed from

analysis of software conversion case histories. They all support

portability and efficient conversion.

o Software Libraries and File Maintenance. Conversion

planning and execution is often complicated by

extraneous and outdated programs, files, and data bases

(e.g., outdated systems, old test files). Software

libraries and data bases require disciplined control and

purging to ease actual conversion planning and

execution. Such purging makes maximum effective use

of hardware facilities on a routine basis.

o User's Support. Rapport and understanding must be

maintained between the data processing staff and the

functional users. This reduces user's pressures for

introduction of new enhancements during conversion.

o Top Management Support. Executive-level support is required during conversion to provide authority to

software conversion managers and assist in providing resources to complete conversion and resolve unforeseen

problems. The ADP managers should seek some

continuing means to give software management visibility

during the post conversion phase. Periodic briefings,

perhaps at six months intervals, are recommended.

o Training. Continuous training of the data processing

staff in good software engineering and documentation

techniques promotes routine production of software of

high technical standards as well as portability.

131
Security. Sensitive systems require security features to

be carefully considered and engineered into software.

The time of actual conversion does not provide the

optimum environment to develop security specifications

due to conversion pressures. Security is best addressed

systematicalUy during the post conversion phase. Then,

security features are already engineered into software at

the time of conversion.

Documentation. Adequate, current documentation, in

accordance with agency standards or FIPS PUB 38 or 64

provides, at the time of actual conversion planning,

detailed systems information needed to prioritize and

develop schedules. It improves understanding of system

requirements by outside personnel who assist in planning

(e.g., contractors). Documentation facilitates the

efforts of those actually involved in conversion duties.

Standard Languages. Use of standard languages, by

definition, facilitates portability or conversion of

software. Vendors offer hardware and operating systems

that accommodate standard languages. Conversion tools

and techniques are available to convert standard

languages. Programmers, analysts and consultants are

generally familiar with standard languages.

Vendor Unique Utilities. Reliance on vendor unique

utilities degrades portability and conversion. Software

staffs should be discouraged from large-scale use of such

utilities.

Software Engineering. Modern techniques of structured

software design and development, and modular

programming facilitate conversion and ease of software

maintenance.

File Design. Files should be designed for ease of access by standard languages. DBMS should be employed so

that they can be supported on a variety of common

vendor computer systems.

Test Files and Data. Test files and data require design

and maintenance to ensure that quality software is developed and implemented. This quality assurance is required during software maintenance as well as during

conversion.

Optimization. Software under continuous modification

should be periodically examined for efficiency and

optimized as required.

132
7.7 POST-CONVERSION MANAGEMENT DECISIONS

There are two major management decisions.

First, any parallel testing which continues into the postconversion phase must be terminated. This will halt costly conversion

activities and lead to restructuring the conversion staff into an environment conducive to routine operations.

Second, the post-conversion analysis and assessment report

should be approved. This is the last official act of the project manager

and concludes the conversion project. Activities continue, however, in

planning and preparing for the next conversion.

7.8 ECONOMIC CONSIDERATIONS

It is important to distinguish between the identification of

software conversion costs and the use of this cost information as it applies to this phase. In order to provide a standard, finite definition of

software conversion for cost estimation purposes, the cost structure

defined in Appendix C ends with appproval of the post-conversion analysis

and assessment report. Costs will include significant expenditures

associated with settling the conversion team into routine software

operations (e.g., relocation expenses moving from temporary real estate,

shipping terminals used only for conversion). Other software conversion

costs which are not project-related (e.g., long term planning) incurred

during this phase will not be estimated in the software conversion cost

structure.

During this phase, personnel expenses will constitute the

majority of the total cost as manpower is expanded to perform the postconversion analysis and assessment. Additional cost areas that may be

significant during this phase include relocation expenses for the

conversion staff and freight and transportation expenses for the office

furnishings. If equipment acquired for the conversion effort is released, a reasonable residual value for the equipment should be credited to the

total software conversion cost.

The use of the software conversion cost information during the

post-conversion phase will require a review of both estimated and actual

costs accumulated over the life of the project. Analysis of cost results

should address areas such as the amount and degree of deviation between

estimated and actual costs, specific areas of cost deviation identified

through the use of a detailed cost structure, and the validation of cost

estimation techniques and models. The actual cost information recorded can provide a basis for evaluating the effectiveness of conversion tools

and may be used to prepare recommendations for improved procedures

that can increase the cost-effectiveness of software conversion.

133
POST CONVERSION MANAGEMENT CHECKLIST

o Parallel testing terminated

o Documentation completed

o Conversion staff reverted to normal duties

Informed of organization

Informed of duties

Trained as necessary o Contracts closed out

SOW reviewed

Obligations met

Cost issues (if any) resolved

o Unneeded conversion facilities released

o New user enhancements pending changes analyzed for

redesign

o Ongoing costs being tracked

o Post-conversion analysis completed

Report complete

Support planning and future conversion

Coordinated with staff ^

Approved

o Project manager released

o Ongoing long-term planning based on full cost

methodology; adequate to support

A-76 Studies

A-109 Studies

A-11 Planning

Budget

Future conversion

o Conversion technical planning ongoing

o Conversion technical plans implemented to promote

efficient, portable software

Software library maintenance and purging

File maintenance and purging

Continuous user interface

134
Continuous top executive interface and reporting

Training supporting good software practices

Security requirements regularly addressed

Documentation procedures

Standard language used

Vendor unique utilities discouraged

Software engineering practices

Files designed for standard language access Test files and data maintained and used

Regular optimization of software

135
APPENDIX A

BroLIOGRAPHY

136
BIBLIOGRAPHY

Books and Periodicals

1 Bennett, Wayne Douglas. Computer Performance Management;

Determining Efficiency and Effectiveness Through Cost Benefit Analysis, (draft). National Bureau of Standards. Washington, D.C. May 1980.

2 Computer Systems Conversion. (Second Edition). DR and CG

Seminar (1st), held at the Sheraton Inn, Los Angeles, California. January

25, 1973.

3 DASD Corporation. COBOL to COBOL, Custom Systems and

Programming Proprietary Software Products. February 5, 1980.

4 DATAPRO Research Corporation. "Moving the Data Center".

Delran, New Jersey. October 1976.

5 DATAPRO Research Corporation. "An Inventory of Programming

Aids". Delran, New Jersey. May 1980.

6 DATAPRO Research Corporation. "Computer Systems Conversion-Management Guidelines". Delran, New Jersey. October 1976.

7 Digital Equipment Corporation. COBOL Conversion; We Make It Easier! 1977.

8 Executive Office of the President, Office of Management and

Budget, Circular No. A-11, Preparation and Submission of Bucket Estimates.

9 Executive Office of the President, Office of Management and

Budget, Circular No. A-71, Security of Federal Automated Information

Systems.

10 Executive Office of the President, Office of Management and

Budget, Circular No. A-76, Policies for Acquiring Commercial or Industrial Products and Services for Government Use.

11 Executive Office of the President, Office of Management and

Budget, Circular No. A-109, Major Systems Acquisition.

12 Executive Office of the President, Office of Management and

Budget, Circular No. A 121, Cost Accounting, Cost Recovery and

Interagency Sharing of Data Processing Facilities.

13 Federal Register. General Services Administration, 41-CFRParts 1-4, 101-35, 101-36. VoL 46, No. 2, January 5, 1981. pp. 1196-1219.

137
14 Federal Register. General Services Administration 41-CFRParts 101-35, 101-36, 101-37 (FPMR Temp. Reg. F-496). Vol 45. No.

239. December 10, 1980. pp. 81202-81203.

15 Federal Register. General Services Administration, 41-CFR101-35.2, FPMR Temp Reg F-492. VoL 44. No. 212. October 31, 1979.

pp. 62515-62516.

16 GSG, Inc. DPSC Experience Using the NAVDAC Conversion

Management System. March 10, 1980.

17 Kerrigan, James F. "ADP Conversion in the Federal

Government." Unpublished research paper. The American University.

July 1, 1975.

18 Letter on Software Conversion addressed to George W. Dodson,

General Services Administration. Prepared by Paul Oliver, Federal

COBOL Compiler Testing Service, Department of the Navy (ADPESO),

Washington, D.C. No. 8089-77. November 17, 1977.

19 Lynn, Charles Jr. et. aL "Program Conversion - One Successful

Paradigm." AFIPS Conference Proceedings. National Computer

Conference. VoL 48. 1979.

20 Montague, Noel M. The Data Management Center Conversion

Catalog (Final Report). Department of Health, Education and Welfare.

December 24, 1975.

21 Morgan, L.W., et. aL Conversion of CCF Univac Software. MITRE Technical Report 4710. Contract No. F19628-78-C-0001 T1740B.

The MITRE Corporation. Houston, Texas. January 1978.

22 U.S. National Bureau of Standards. Guidelines for

Documentation of Computer Programs and Automated Data Systems for

the Initiation Phase. FIPS PUB 64. August 1, 1979.

23 U.S. National Bureau of Standards. Conversion of Federal ADP

Systems; A Tutorial Special Publication 500-62. U.S. Department of

Commerce. August 1980.

24 U.S. National Bureau of Standards. Guideline for Automatic

Data Processing Risk Analysis. FIPS PUB 65. August 1, 1979.

25 U.S. National Bureau of Standards. Guidelines for

Documentation of Computer Programs and Automated Data Systems. FIPS PUB 38. February 15, 1976.

26 National Technical Information Service. Computer Software

Transferability and Portability. NTIS/PS-79/0567. May 1979.

138
27 Oliver, Paul. Guidelines to Software Conversion. Software

Engineering Service, Naval Data Automation Command, Department of

the Navy. (Unknown date).

28 Oliver, PauL Handbook for Estimating Conversion Costs of

Large Business Programs. Federal Compiler Testing Service, Department

of the Navy. 1979.

29 "OS-to-DOS Move PuUed Off Without Experienced Staffers."

Computerworld. VoL XIV. No. 52. December 22, 1980.

30 Sanders, John. "Barriers to Estimating DP Projects Effectively."

Infosystems. December 1980.

31 Schneider, Daniel B., Computer Systems Conversion - A Management Perspective, U.S. Department of Justice, NTIS: PB 297-604.

October 1980. 80 pp.

32 Seaman, John. "Smart Benchmarking—The Key to Successful

Procurement?" Computer Decisions. VoL 13. No. 3. March 1981.

33 Tennessee Valley Authority. Conversion Requirements Specifications. Property and Services Computing Operations. December 1979.

34 Tripp, Leonard L. and Dr. Pran N. Wahi. "How Much Planning in

Systems Development." Journal of Systems Management. October 1980.

35 U.S. Army Computer Systems Command. Final Report of the

Modernized Army Research and Development Information System

(MARDIS) Multi-ADPE Conversion. Ft. Belvoir, Virginia.

August 2, 1977.

36 U.S. Army Computer Systems Command. Software Portability. ACSC-ESR. December 1980.

37 U.S. Army Computer Systems Support and Evaluation Agency.

Survey of Software Conversion Aids. (Emulators, Simulators, Translators). Washington, D.C. December 1, 1975.

38 U.S. Air Force. ADP Conversion Cost. A study for the FY 76

Worldwide ADP System Managers Conference. Prepared by the Air Staff

and Major Commands. Randolph AFB, Texas. December 3-5, 1975.

39 U.S. Army Headquarters. Army Automation Planning Guide for

Software Conversion. Technical Bulletin 18-122. October 1977.

40 U.S. Department of Health and Human Services. Software

Conversion and Procurement Alternative Study. Washington, D.C.

June 30, 1980 and Complete Replacement Procurement Workload Analysis

Study (Final Report). Washington, D.C. November 2 6, 1980.

139
41 U.S. Environmental Protection Agency. WCC Transition System;

A-76 Cost Comparative Study. Prepared by the Data Center Branch.

Research Triangle Park, North Carolina. July 15, 1979.

42 U.S. General Accounting Office. Millions in Savings Possible in

Converting Progr'^m<^ from One Comptuer to Another. A Report to

Congress,- F QMSD -7 7 -34. September 15, 1977.

43 U.S. General Accounting Offi-^e. Conversion; A Costly,

Disruptive Process That Must Be Considered When Buying Computers. A

report to the Chairman, Committee on Appropriations, House of Representatives. FGMSD-80-35. June 3, 1980.

44 U.S. General Accounting Office. MEMO; Review of Selected

Computer System Procurement. FGMSD-80-34. February 15, 1980.

45 U.S. General Services Administration. Review and Analysis of

Conversion Cost-Estimating Techniques. Federal Conversion Support

Center. (Pre-Release Copy). Report No. GSA/FCSC-81/001. January

1981,

46 U.S. General Services Administration. Conversion Products/Aids

Survey. Federal Conversion Support Center. Report No. GSA/FCSC80/01. August 1980.

47 U.S. General Services Administration. Conversion Study Outline. Federal Conversion Support Center. August 1980.

48 U.S. Naval Data Automation Command. Data Processing

Service Center Project Final Report. Conversion and Project Management Department. December 1979.

49 U.S. Naval Data Automation Command. Perspay Project

Economic Analysis. Prepared by the Conversion and Project Management

Department. December 1979.

50 U.S. Veterans Administration. Solicitation Document RFPIOI34-79 . August 21, 1979.

51 Wright, Carl A. "Planning Can Ease Software Conversion"

Information Systems News. January 26, 1981.

140
APPENDIX B

CONVERSION DIRECTIVES, STANDARDS AND REFERENCES

141
The following references should be part of any software

conversion manager's library.

FEDERAL DIRECTIVES:

FPR 1-4.11 Procurement and Contracting Government-Wide for

Automatic Data Processing Equipment, Software, Maintenance Services

and Supplies. This regulation defines procurement and contracting

policies relating to the acquisition of hardware, software, maintenance

and supplies for ADP.

FPMR 101-35 ADP and Telecommunications Management Policy. This

regulation establishes the general policies and procedures relative to the

acquisition, management and utilization of ADP equipment, software,

maintenance and supplies.

FPMR 101-36 ADP Management. This regulation defines the

requirements, policies and procedures governing the use, utilization and

management of government ADP facilities.

FPMR 101-37 Telecom munciations Management. This part prescribes

policies and procedures governing the utilization of telecommunication

services by Federal agencies.

FPMR Temp. Reg. F-496 Federal Conversion Support Center. This

temporary regulation advises agencies of the reimbursable services

provided by the Federal Conversion Suport Center (FCSC) for ADPE and

teleprocessing services, software conversion support assistance, guidance,

and support. This regulation replace FPMR Temporary Regulation F-492,

October 18, 1979, in that it removes the F-492 requirement for FCSC

evaluation reports on conversion studies.

Public Law 89-306 Federal Property and Administrative Services Act of

1949 (as amended by the Brooks Act, October 30, 1965). This Act

establishes the authority to provide for improved and efficient

procurement, maintenance, operation and utilization of ADP equipment.

It also establishes an ADP fund for use by Federal agencies.

Public Law 96-511 Paperwork Reduction Act of 1980 . December 11,

1980. The purpose of this Act is to reduce paperwork and enhance the

efficiency of the Government. Specifically it calls for the improvement

and increased efficiency in the use of ADP and telecommunication

services.

STANDARDS AND GUIDELINES:

National Bureau of Standards. FIPS PUB 31. Guidelines for Automatic

Data Processing Physical Security and Risk Management. June 1974. A

handbook for structuring physical security and risk management programs

for ADP facilities.

142
National Bureau of Standards. FIPS PUB 38. Guidelines for

Documentation of Computer Programs and Automated Data Systems. February 15, 1976. This guidelines provides a basic reference and

checklist for determining the content and extent of documentation of

software programs.

National Bureau of Standards. FIPS PUB 41. Computer Security

Guidelines for Implementing the Privacy Act of 1974 . May 30, 1975. This

publication provides guidelines for implementing computer safeguards

(i.e., management of information, system/network controls, and physical

security) as mandated by Public Law 93-579, the Privacy Act of 1974.

National Bureau of Standards. FIPS PUB 48. Evaluation of Techniques

for Automated Personal Identification. April 1977. Discusses techniques

for identifying individuals seeking access to computer systems.

National Bureau of Standards. FIPS PUB 64. Guidelines for

Documentation of Computer Programs and Automated Data Systems for

the Initiation Phase. August 1, 1979. This guideline provides a basic

reference and checklist for determining the content and scope of

documentation for the initiation phase (feasibility, cost/benefit analysis)

of a software life cycle.

National Bureau of Standards. FIPS PUB 65. Guidelines for Automatic

Data Processing Risk Analysis. August 1979. Presents a technique for

conducting a risk analysis of an ADP facility and related assets.

National Bureau of Standards. FIPS PUB 73. Guideline for Security of

Computer Applications. June 1980. These guidelines describe methods

and techniques that can reduce the hazards associated with computer

applications.

Executive Office of the President, Office of Management and Budget,

Circular No. A 76, Policies for Acquiring Commercial or Industrial

Products and Services for Government Use. This policy document

prescribes evaluation of government run operations, at time of major

change (such as software conversion), to determine if operations can costeffectively be transferred to contractor support.

Executive Office of the President, Office of Managfement and Budget,

Circular No. A 109, Major Systems Acquisition. This policy document

requires studies to be performed in a prescribed method when acquiring

major systems, includir^ large computer systems.

143
REFERENCES:

General Accounting Office. Conversion; A Costly, Disruptive Process

That Must Be Considered When Buying Computers. A report to the

Chairman, Committee on Appropriations, House of Representatives.

FGMSD D-80-35. June 3, 1980. This report summarizes GAO's findings on the treatment of software conversion costs in evaluating vendor

proposals.

General Accounting Office. Millions in Savings Possible in Converting

Programs from One Computer to Another. FGMSD-77-34 (1977). This

report is a survey and management review of several agency conversions

and their problem areas.

General Services Administration. Conversion Products/Aids Survey. Federal Conversion Support Center. Report No. GSA/FCSC-80/01.

August 1980. This report describes in detail many of the commercially

available automated conversion packages and aids currently available to

the Government.

General Services Administration. Conversion Study Outline. Federal

Conversion Support Center. August 1980. This document provides a

checklist for identifying and cataloging source programs and data files

subject to conversion.

General Services Administration. Review and Analysis of Conversion

Cost-Estimating Techniques. Federal Conversion Support Center. Report

No. GSA/FCSC-81/001. April 1981. This document identifies and

evaluates seven conversion cost estimating techniques available to

agencies. Each technique is briefly examined in terms of its advantages

and disadvantages.

National Bureau of Standards. Conversion of Federal ADP Systems: A

Tutorial Special Publication 500-62. August 1980. This document

presents in tutorial fashion an analysis of several recent conversion

projects with observations and salient problem areas identified. Several

case studies are included.

U.S. Army. Army Automation Planning Guide for Software Conversion. Technical Bulletin 18-122. October 1977. This report presents a detailed

outline of the conversion preparation process including both pre-award

and post-award activities.

144
APPENDIX C

SOFTWARE CONVERSION COSTING

145
APPENDIX C

SOFTWARE CONVERSION COSTING

The information contained in this appendix has been developed

to provide guidance for the practical application of the conc^t of full

costing to the management of software conversion projects The purpose

of this appendix is to define the approach, or methodology, that should be

followed in developing software conversion costs. The approach presented

is intended to be a generalized methodology and attempts to discuss cost

considerations in general terms This total system approach can then be

modified, as appropriate, to fulfill the specific costing requirements of

each software conversion project.

It is important to understand the steps for developing a total

conversion costing methodology. The methodology consists of two parts.

The first is the definition of fuU conversion costs which requires:

o Identification of project characteristics,

o Development of the full cost structure,

o Estimation of the cost data,

o Analysis of the cost data.

The second part is the application of the cost data to support

management decisions. The remainder of this appendix describes these

steps in more detail It is important, however, to continue to view costing

in terms of a total methodology, to assure that the maximum return is obtained from the costing development effort.

C.l INTRODUCTION

Software conversion project managers are required to prepare

budgets, monitor the progress of programs and projects, estimate the cost

of new capabilities, and make a variety of other system-related decisions on a frequent basis It is the objective of this appendix to provide a

consistent cost methodology that can assist the project manager by

ensuring that the required conversion cost data is both available and

reliable. Also, by providing a consistent costing methodology, historical

costs can be uniformly accumulated and updated to increase the accuracy

of future estimates.

C.1.1 SCOPE OF THIS METHODOLOGY

The identification of software conversion costs addressed in

this appendix includes all major cost factors directly attributable to a

146
software conversion effort. The software conversion project may be

conducted as part of a total hardware installation effort, with planning,

analysis and implementation tasks being conducted concurrently. The

scope of this appendix, however, will be limited to the software

conversion effort which is just one major factor in that hardware

transition effort Other hardware-related costs such as site preparation,

installation, and ongoing operations will not be included. Identification of

software conversion costs will include both direct and indirect costs that can be identified with the conversion effort, and may span organizational

boundaries and include the user community costs.

If the software conversion is accompanying hardware replacement, the costing of the software conversion effort should form an

important input into the life cycle cost (LCC) of the total acquisition

effort. The total LCC should include the total cost of acquiring,

installing and operating the ADP system from the inception of the

acquisition process until the system becomes obsolete. The development

of accurate and detailed software conversion cost estimates will not only

aid the conversion project decisions but will also aid in the selection of

the total system acquisition alternatives. The software conversion

project manager should assure that a single cost estimation effort is conducted where software conversion cost estimates are supplied to the

total acquisition LCC, and where acquisition decisions are communicated

to the conversion project to be reflected in the software conversion cost

estimates. This sharing of cost information can prevent situations where

ambiguous and conflicting costs are reported to upper management

C.1.2 CONVERSION COST DEFINITION

The first step in the understanding of the conversion costing

methodology is the definition of conversion costs. This can be

accomplished by identifying the full cost structure that represents the

software conversion effort, and by defining the length of the software

conversion cycle.

1 C.1.2 .1 FuU Costing

FuU costs of a software conversion include the obvious direct

costs of ADP employees and software conversion tools Indirect overhead

costs such as space rental, ADP management and support costs can also

be identified or reasonably allocated to a particular conversion effort,

especially if the costs are incurred within a particular agency. The

biggest problem of defining the full costs of a system occurs in the user community, or in organizations beyond the control of the ADP facility

management or even the agency management.

C.1.2 .2 Conversion Cycle Length

The length of the software conversion cycle depends upon the

beginning point, when costs begin to accumulate, until the project has

147
been completed. The following factors should be considered in

determining the project cycle length:

o Beginning Point - For the purpose of this appendix, the

beginning event for the estimation of costs is assumed to occur with the appointment of a conversion project

manager. This point does not necessarily coincide with

the beginning of the software conversion effort since

software conversion has a continuous life cycle. Each

life cycle has a distinct project, however, and

development of project costs is the important issue.

With the appointment of a project manager:

Costs can be clearly identified with a particular

project, and.

Accountability for costs has been clearly

established.

If, for some reason, significant project-related costs

have been incurred prior to the appointment of a project

manager, these costs should be retained in the historical

cost records.

o Ending Point - For cost estimation purposes, the

software conversion project ends when conversion has

been completed, conversion resources have been

reassigned and the post-conversion audit and analysis

have been completed.

The subject of costing — its definition, estimation and use by

project management — has no single, cookbook approach that can be

applied for all projects. Instead, what is needed is a methodology that

addresses the costing requirements of management in general, and the

guidance that can mold the methodology to the individual needs of each

project. This is the approach taken by this appendix.

C.2 CONVERSION COSTING METHODOLOGY

The process to be followed in identifying the full cost of the conversion

effort is illustrated in Figure C-1. The major steps in this process

include:

o Characterization of the Conversion Effort - This

includes a general understanding of the project goals and

objectives, source environment, potential target environments, current software inventory and inventory status.

148
Organization Information

Functional Requirements

Historical Information

Proiect Characterization • Scope • Resources • Size • Multiplicity

Estimation Models

Historical Data

Tecfmical

Journals

Industry

Sundards

Equipment

Specificatioru \~'

Cort Structure

Definition

Resource

Estimates

Price Estimates

Historical Cost

Overhead Rates Wave Sales

Vendor

Price Lists

Cost

Aitalysis Techniques

(By Timer

Cost Accumulation tnd Application

(By Phase) (By Product) (By Function)

Pio^ct

Decisions

COST DEVELOPMENT PROCESS

Figure C-1

149
o Definition of a Cost Structure - The cost structure

should reflect the requirement for more detailed cost

information as the project progresses and should include

major categories of cost

o Estimation of Costs - Defined by the cost structure using resource and price estimates developed from historical

data, models, price lists, industry sources, etc.

o Analysis of the Cost Data - Specific analysis objectives are based on the requirements for the use of cost data by

project management

o Application of the Cost Data - To provide specific cost

input for costing decisions and activities.

Each of these steps is described in more detail in the sections that follow.

C.3 CONVERSION PROJECT CHARACTERIZATION

The characterization of the conversion effort is an important

preliminary step in the execution of the conversion costing methodology.

Through a thorough evaluation of the major characteristics of the

conversion project, a cost structure can be developed that reflects the

material costs expected to be incurred and allows for the application of

costs, with sufficient detail, to fulfill expected management

requirements.

A conversion project may be characterized using several

factors including:

o Software environment, e.g., current languages used,

whether they are in standard ANSI language, degree of

documentation,

o Multiplicity, e.g., whether the conversion involves

multiple sites, systems, or user organizations,

o Financial impact, e.g., whether the expected dollar size

of project will require increased reporting efforts,

o Mission supported, e.g., whether workload cycles will

restrict the project schedule.

This characterization step should result in an informal, written

understanding of the relevant project characteristics stated in terms of

the project's goals and objectives. This understanding should be approved

by the project manager during project initiation in the development of a

conversion cost structure. This understanding should also be reviewed

periodically throi^hout the project and revised as needed.

150
C.4 COST STRUCTURE DEFINITION

The primary component of the methodology is the design of a comprehensive cost structure that addresses the full cost of the

conversion, aids in the estimation of conversion resource requirements

and price factors, and allows the application of a single cost information

base to several project costing needs. The cost structure defined in this

appendix meets these requirements through the use of cost dimensions.

A cost dimension is a classification scheme that identifies a

particular characteristic of an entire project. For example, project costs

may be recorded as follows: personnel $75,000, equipment $10,000,

facilities $10,000, miscellaneous $5,000 The cost of the project may also

be defined along functional terms, such as, conversion $80,000, training

$12,000 and administration $8,000 In a similar fashion the total project

cost could be divided into cost per phase, cost per year and so forth. In each case, a summation of costs along any dimension would yield the same

result, or in this example, $100,000.

The purpose of the dimensional cost structure is to minimize

cost ambiguities in addition to providing the following:

o Assistance in defining the fuU cost of a project, o A work breakdown for ease of cost estimation, and o Detailed cost information for use by project

management.

The full cost of a project can be defined using single

dimensions and, similarly, a summation of costs along each dimension

would yield the same full cost figure. The benefit of a dimensional

approach is the ability to identify categories of cost (such as software

conversion personnel costs) that span several dimensions. The following

dimensions diould be included in the software conversion cost structure:

C.4.1 COST ELEMENT DIMENSION

Cost elements correspond to the basic accounting units that

represent personnel, material and facilities The cost element dimension

has been developed for this cost structure using ADP terminology and

providing a level of detail that is consistent with the amount of funds

normally expended for each category. It is the responsibility of each

project manager, working with the cost analyst, to identify the cost

element level of detail that reflects the characteristics of the project and

supports the application of the conversion costir^ methodology to the

project's needs.

The cost element detail that follows is illustrated in Figure C-",

and should be viewed as general guidance. Important cost areas may be

expanded if they are material to the decisions supported by the costing

methodology. Elimination or consolidation of the cost element

151
PERSONNEL

• COMPENSATION

• GENERAL BENEFITS

• TRAINING EXPENSES

• TRAVEL AND TRANSPORTATION

EXPENSES

• HIRING/SEPARATION EXPENSES

• MOVING EXPENSES

ADP HARDWARE

• OPERATING UNIT

• DATA ENTRY DEVICES

• PRINTERS

• TIMESHARING SERVICE

• EQUIPMENT MAINTENANCE

• OTHER ADPE

ADP SOFTWARE

I OCCUPANCY'—

• FACIUTIES i • UTILITY SERVICE

• OFFICE EQUIPMENT

• HOUSEKEEPING EXPENSES

• SECURITY EXPENSES

• ENVIRONMENTAL CONTROLS

• OTHER OCCUPANCY

1 ADPE SUPPLIES 1

MISCELLANEOUS EXPENSES

• OFFICE SUPPLIES

• TELEPHONE SERVICE

• PRINTING/DUPLICATING

EXPENSES

• SMALL CONTRACT SERVICES

• OVERHEAD

• GENERAL AND ADMINISTRATIVE

• OPERATING SYSTEMS

• CONVERSION SUPPORT SOFTWARE

• GENERAL PURPOSE SOFTWARE

• SOFTWARE DOCUMENTATION

• SOFTWARE MAINTENANCE

• OTHER SOFTWARE

TELECOMMUNICATIONS

• LINE CHARGES

• TERMINAL EQUIPMENT

SOFTWARE CONVERSION COST ELEMENT DETAIL

Figure C-2

152
dimensional detail should be done only with careful consideration as to the

impact on the cost estimation techniques and the ultimate application

potential of the resulting structure.

The following is a definition of each significant cost element:

o Personnel - The personnel cost element will normally be

common to each software conversion project and

account for a s^nificant portion of the costs. Personnel

costs are also the most likely to be underestimated

either through an incomplete definition of the work to be

performed, quantity of personnel required, level and cost

of skills required, or amount of ancillary personnel costs.

The personnel cost element consists of the following subelements:

Compensation - includes base wages, cash awards,

overtime pay and premium pay in the form of shift

differentials, incentive pay, merit pay, and other

allowances for all regular, part-time, permanent

and temporary employees.

General Benefits - includes employer-paid medical,

dental, life and disability insurance, and

contribution to non-social security retirement

plans, federal and locally-imposed payroll taxes

such as FICA ^social security), FUTA

(unemployment), and workman's compensation

taxes; and other benefits such as professional dues

and member^ips, subscriptions, awards, uniform

cost and cleaning, and any other personnel

expenses that are not otherwise described.

Training Expenses - includes expenditures for

tuition, fees, educational books, materials and

training aids.

Travel and Transportation Expenses - includes the

transportation of employees for business, training or relocation purposes. It includes actual

transportation expenses for auto, airlines, bus, and

train travel, as well as meals, lodging, tolls, tips

and other travel expenses.

Hiring/Separation Expenses - includes advertising

costs, credit/background investigations fees,

employment agency fees, testing service fees, and

outplacement fees.

153
Moving Expenses - includes the cost of transporting

personal property such as the shipment of

household goods, property storage, closing costs

and mortg^e interest adjustments.

In addition to the personnel cost categories listed above, it may be beneficial to be able to identify personnel salaries based upon

individual skill categories. This process will assist in the estimation of

salary expense by providing common job titles, and will aid in the

application of the costing methodology for alternative evaluation

purposes. A personnel skills category definition would be applied to the

salary cost element and, in the federal government, would contain costs

by jdo title, GS level and GS step.

o ADP Hardware - ADP hardware expenses may be

incurred during the software conversion effort in terms

of CPU hours purchased from a service bureau or provided by the equipment vendor, or target equipment

obtained on a short-term basis to provide the test

environment and on-line conversion capabilities required

during the project. Subelements of this category

include:

Operating Unit - includes the mainframe, operator

consoles, storage and memory devices acquired for

the project.

Data Entry Devices - includes the terminals and

other input equipment.

Timesharing Service - includes the cost of

timesharing services used during the project,

Equipment Maintenance - includes the cost of

normal hardware maintenance service contracts,

Other ADPE - includes ADP equipment not

included above, such as tape cleaners, hardware

monitors, test equipment, and spare parts.

o ADP Software - ADP software includes an everincreasing proportion of ADP costs as data processing

installations use more canned programs, and less inhouse software is developed This cost element includes

only purchased or leased software. ADP software

includes the subelements of:

Operating Systems - includes the mainframe

operating software including spooling software.

154
Conversion Support Software - includes the system

support software such as compilers, utilities,

translators, and tools,

General Purpose Software - includes multi-use

software such as SAS, SPSS, RPG, etc..

Software Documentation - includes the manuals,

guides, and software handbooks obtained for use with the ADP software.

Software Maintenance Service - includes the cost

of normal software maintenance service contracts,

Other software - includes other software-related

costs.

Telecommunications - The telecommunications cost

element includes the hardware and service required to provide data communications between ADPE components

to support software conversion This element includes

the following subelements:

Line Charges - include the cost of leased lines,

trunks or network service,

Equipment - includes the cost of modems,

concentrators, front-end processors, terminals

equipment maintenance service.

Occupancy - The occupancy, or space cost element is used to identify the costs required to house the project

team. It is a cost element that has been occasionally

overlooked, since occupancy costs are frequently borne

by a service agency (e.g. GSA). The occupancy cost

element consists of the following subelements:

Facilities - include the building, land, common

areas, leasehold improvements, and other physical

structures.

Utility Services - include electric power, gas, oil,

coal, water, sewage and garbage service,

- Office Equipment - includes the general office

furniture and fixtures, typewriters, copiers, plants,

pictures, decorating fees, etc..

Housekeeping Expenses - include janitorial supplies

and equipment.

155
Security Expenses - include the access cards,

cameras, locks, monitors and alarms required to control access to the building or the computer

installation,

Environmental Controls - include the normal

heating and air conditioning equipment expenses as well as an uninterrupted power source, humidifiers,

dehumidifiers, water chillers.

Other Occupancy Expenses - include all other

occupancy-related costs not included above.

ADP Supplies - In a typical ADP operation, ADP supplies can account for a small, but significant percentage of

costs. For this reason, a separate cost element is assigned to distinguish the ADP-related supplies from all

other supplies.

Miscellaneous Expenses - Miscellaneous expense is a cost

element that incorporates costs not specifically detailed

by the prior cost elements. It should include general

categories of expenses that are not ADP related. The

characteristics of each project will determine the

materiality of the subelements defined for this cost

element The list of subelements that follows should be

used as a guide that can be expanded as needed to

provide a consistent level of cost detail

Office Supplies - include general administrative

office supplies that are not directly ADP-related.

These would include pens, pencils, copier paper,

pads, folders and the like.

Telephone Services - include the chaises for local

service, long-distance and special voice

communication lines.

Printing/Duplicating Expenses - include the cost of

using off-site printing and duplicating services.

Small Contract Services - include the relatively

small contract services that cannot be defined in

terms of other cost elements, or are too small to

be of material significance. Major software

conversion contracts should be identified by the

specific resources (amount and price) beir^

provided to allow a detailed identification of costs.

156
Overhead - includes indirect costs associated with

the performance of a project that cannot be

defined in terms of other cost elements, or are too

small to be of material significance. The use of

this overhead category should be kept to a minimum since the objective of the cost structure

is the identification of the full cost detail

General and Administrative (G&A) - similar to the

overhead category, G&A is common in the federal

government as a means of allocating indirect costs

to an operating unit. As with overhead, the use of

the G&A element should be summarized and

applied only when a cost detail is not available or the amount of the cost is relatively insignificant.

The cost element dimension detail provided in this section

should be used as a foundation for the construction of a conversion cost

structure that is representative of the software conversion effort and

reflects the full cost of the project. The function dimension discussed in

the following section serves as an additional means of assurir^ that the

full costs of the software conversion are addressed.

C.4.2 FUNCTION DIMENSION

Functions are general categories that may include one or more

activities that are performed during the software conversion project. It is important to distinguish between functions and activities. From a project

management standpoint, activities are important for establishing project

controL Conversion activities may not require a substantial amount of

resources, for example, the appointment of a project manner. From a

cost estimation standpoint, however, conversion functions better

represent the conversion effort. The function dimension is included in the

cost structure since it aids in the identification of the full cost of a software conversion project by identifying all significant functions. Also,

the function dimension helps in the cost estimation process by providing

cost categories that correspond to existing software conversion cost

estimation models, and are sufficiently detailed to provide a work

breakdown structure with which to develop costs. A consistent set of

software conversion functions can also aid in the use of historical costs to estimate future software conversion costs. The following functions

illustrated in Figure C-3, correspond to the conversion tasks identified by

the Federal Conversion Support Center and include:

o Conversion Management and Administration - includes

the resources involved in managing and administering the

conversion effort, such as user and upper management

liaison, contract administration, and personnel activities

involving the project team.

157
CONVERSION MANAGEMENT AND

ADMINISTRATION

SYSTEM AND PARALLEL TESTING

CONVERSION PLANNING ANALYSIS

AND PREPARATION

• PROJECT PLANNING

• STUDY PREPARATION AND

SOFTWARE INVENTORY

IDENTIFICATION

• POLICY REVIEW

• SOFTWARE WORK PACKAGE

PREPARATION

• TEST DATA GENERATION

APPUCATION PROGRAM AND SYSTEM

SOFTWARE CONVERSION

TRAINING

• CONVERSION TOOLS

• TARGET SYSTEM AND TARGET

SOFTWARE

SOFTWARE UPGRADE

• CONFORMITY TO ANSI STANDARDS

• COMPLETE CURRENT SYSTEM

DOCUMENTATION

• PURGE OBSOLETE SOFTWARE

• FUNCTIONAL SOFTWARE REDESIGN

DATA FILE AND DATA BASE CONVERSION GENERAL

• FACIUTIES MAINTENANCE,

SECURITY ETC.

AVERAGE COMPLEXITY

TRANSLATIONS

COMPLEX TRANSLATIONS

VERY COMPLEX TRANSLATIONS

TRANSFERS ONLY

SIMPLE TRANSLATIONS

OPERATION CONTROL LANGUAGE

OPERATING PROCEDURE CONVERSION

REDOCUMENTATION

SOFTWARE CONVERSION FUNCTION DETAIL

Figure C-3

158
Conversion Planning, Analysis, and Preparation -includes

the preliminary conversion activities such as:

Project planning and analysis at the project,

system and task levels, and identification of the

conversion work package,

Study preparation and software inventory

identification including quantity, language, age,

documentation, etc..

Review and implementation of conversion policy,

procedures and documentation standards,

Preparation of the software work package.

Test data generation and validation.

Application Program and System Software Conversion - includes the resources required for reprogramming,

program logic modification, simple translation or other

methods of software conversion, including the use of

conversion translators and aids.

Data File Conversion - includes the following types of

conversions:

Transfer only - where the source and target

systems and environments are fully compatible.

Simple translation - where the conversion is basically character-to-character, from source to

target character set, on a one-to-one basis.

Average complexity translation - which involves

character-to-character, character-to-word, or word-to-word conversions with the conversion

parameters embedded in the files.

Complex translation - where the conversion parameters are external to the files These conversions

usually require development or modification of

several pieces of conversion software and generally

call for multiple steps,

Very complex translation - usually includes DBMS

files and may require major development of special

software,

159
Operation Control Language Operating Procedure

Conversion - includes the resources required to convert

the operating procedures from one environment to

another, including rewriting, reprogramming, and the use

of operation control language translators and generators,

Redocumentation - includes the resources used in

reviewing and analyzing existing documentation,

rewriting, and clerical editing, proofing, and typing of

the new software documentation,

System and Parallel Testing - includes the resources used

in the system test and parallel test of the system to

demonstrate interoperability between system components (programs, files, and job streams) and overall

correct execution. When the system functions as expected, software acceptance testir^ would commence

to achieve acceptable comparison of outputs against the

current or source system results,

Training - includes the resources used in training course

preparation, delivery and participation for the following

activities:

Training which trains the project team in new

conversion techniques or the use of software

conversion tools.

Training which trains functional users, DP staff,

project team and other personnel in the target

system environment, and target system software.

Software Upgrade - used to identify software costs

incurred during a conversion not directly associated with

new hardware. These costs must be budgeted and

tracked, but may or may not be included for hardware

evaluation purposes, depending upon the regulations

currently in force Software upgrade occurs whenever

current applications are changed to conform with

government ANSI standard language, documentation is developed to provide a complete description of the

current systems, obsolete programs are purged, or a

functional redesign of a program is performed.

General - is designed as a default category with which to

identify functions not specifically addressed above.

Examples of functions that could be included in this

category include facilities maintenance, production

control, and security functions.

160
C.4.3 PHASE DIMENSION

The phase dimension corresponds to the software conversion

phases described in the body of these guides. Phase dimensions are useful

in large projects in providing a logical and somewhat sequential grouping

of conversion activities that provides better upper management control

through the use of milestone approval points. Through a standard

assignment of software conversion activities to phases, historical costs

from many projects may be recorded in a consistent manner and used for

future cost estimates, and to develop and validate cost estimation models.

It is important to note that the definition of phases will result in some

overlap That is, as one phase is being completed, activities in the next

phase are already being performed. The software conversion phases

identified in the cost structure include:

o Project Initiation Phase - where the decision is made to

undertake a conversion effort,

o Conversion Requirements Phase - where the detailed investigation and identification activities are performed,

o Conversion Planning Phase - where the conversion plans

and schedules are developed in detail based upon requirements defined in the previous phase,

o Conversion Preparation Phase - where the activities that are required to begin the conversion process are completed,

o Conversion Phase - where the activities identified to

perform the transition of software from the source environment to the target environment is accomplished,

o Post Conversion Phase - where the conversion team is reassigned to normal duties and then post conversion

project analysis is conducted.

While costs may be incurred prior to the appointment of a project

manager in the project initiation phase, or after a post-conversion

analysis, they are not included as estimates in the software conversion

project cost. Activities in these areas fall outside the perspective of

viewing conversion as a "project." The conversion project costs, i.e. those that are incurred from the time a project is started through

completion are the most important. More detail concerning the specific

activities included in each software conversion phase can be found in the

body of these guides. The relationship between the cost element, function

and phase dimensions is depicted in Figure C-4.

161

C.4.4 TIME DIMENSION

The time dimension identifies the calendar period in which

costs are expected to be incurred. The time dimension is included in the

cost structure for budgetary purposes to assist in project planning and

control, and to aid in present value cost analysis for relatively long

software conversion efforts. The detail incorporated in the time

dimension ^ould reflect the use of the cost information by project

management and the ability to accurately estimate costs. Thus, during

project initiation, software conversion costs used for a cost-effectiveness

analysis may be estimated for the next four quarters, and annually

thereafter Prior to the commencement of the conversion phase,

however, costs may be required to be estimated for each month for

project control purposes In general, software conversion costs should be

estimated at least by fiscal year and for periods not shorter than a month.

C.4.5 LOCATION DIMENSION

The location dimension identifies the geographical site where

a function of the software conversion is beir^ performed. It addresses

personnel, equipment and occupancy resources, the price of which may

vary by location Thus, the use of a location dimension aids the

conversion costing methodology by allowing the estimation and analysis of

geographic cost differences relative to the total conversion cost figure.

The location dimension should be included with software conversions that

involve multiple sites.

C.4.6 PRODUCT/SERVICE DIMENSION

The product/service dimension is used to allocate the cost of

the conversion to specific operational objectives performed by the

facility These objectives could be stated as ADP services (e.g.

timesharing, batch processing), programs supported (e.g. anti-aircraft

missile, solar energy) or applications processed (e.g. general ledger,

payroll, disbursements, personnel). Where more than one product

classification is appropriate different product dimensions may be

material This dimension will allow the project manager to estimate the

cost to convert each individual system or conversion unit.

C.4.7 ORGANIZATION DIMENSION

The organization dimension identifies the component, agency,

department or division that performs functions of the project. In this

respect it assists in the identification of the full cost of a project by

providing a structure definition that extends beyond the budget concerns

of the primary organization. The organization dimension also aids in the

identification of inter-and intra-governmental support in performing

conversion functions.

163
The identification of the conversion cost structure is the first step in the

development of the cost of a software conversion project. Through the use of cost structure dimensions, the identification of the full cost of the

project, the estimation of the individual cost detail, and the analysis and

application of the estimated costs can be assisted.

C.5 ESTIMATION OF COSTS

Once the cost structure has been identified for the specific

conversion project, estimates of cost must be developed for the structure

detaiL This section presents this cost estimation process in both a general and specific format.

It is difficult to identify a single, universally acceptable

approach to estimate conversion costs The estimation technique used

will vary with the degree of accuracy required, characteristics of the

software conversion project, and the use of the cost data during the

conversion phases. The basic steps required to estimate costs include the

following:

o Identify the Conversion Cost Structure Detail

Appropriate for the Project - This is accomplished by

using the multidimensional cost structure described in

the previous section. The cost structure can assist in the

cost estimation process by dividing the conversion cost

into manageable pieces.

o Estimate Resources - The next step in the cost

estimation process is to identify the quantity of resources required to perform a given conversion

function. The cost element dimension provides the list of resources, while the function dimension identifies the

workload requirements. Since resources will rarely be

100% utilized, an adjustment should be included in the resource estimate to provide excess capacity whether in

terms of man-hours, processing time, or space requirements.

o Estimate Unit Price - The price of a given resource (or

cost element) unit must be estimated The price may be

dependent upon the conversion function performed (e.g

skill level required), location and time period. Price can

be affected by inflation factors, government discounts, or quantity discounts. Multiplying quantity times price

will give the cost of a single cost structural unit.

The estimation process is not static throughout the conversion

project. The use of cost estimation models and techniques at the

beginning of the conversion project may be sufficient to provide the

accuracy for a limited cost-effectiveness analysis. Later in the project, a

164
given cost estimation model may not provide the accuracy necessary to estimate the structural cost units. The degree of estimation will also

change during the conversion project phases. For a l^rge conversion

project, costs may be adequately expressed to the nearest $1,000 during

the project initiation phase. Later, costs may be required to the nearest

hundred dollars The dimensional levels of detail that are material can

also change during the project. When dealing with broad conversion

strategies it may be possible to estimate at a gross level of detaiL Later,

increasingly finer levels of detail will be defined. Cost estimation

techniques that address a gross detail level may not be appropriate to use

in estimating the lower detail levels of the conversion cost structure. The

estimation process described in this section must be used with common

sense and adjusted to fit the characteristics of the individual project and

its changing requirements for cost information durir^ the project phases.

As a basis for the specific cost estimation process, the

following section presents a general discussion of cost estimation

techniques that may be applied.

C.5.1 ESTIMATION TECHNIQUES (GENERAL)

The cost estimation techniques can be used to supply the cost

figures for the cost data defined by the conversion cost structure. Cost

estimation techniques may be simple, such as using a previous conversion

project's supplies cost and adjusting for inflation; or complex, as in the case of a parametric software conversion cost model The following

general techniques may be used to estimate costs:

o Standards - The use of standards relies on estimates for resource quantities and price that have been systematically developed in the past. These standards then

become stable reference points from which new tasks can be calibrated. Due to rapidly changing ADP

technology, past performance standards, such as a standard for conversion productivity (e.g., number of

lines converted per workday), should be examined before

they are applied to estimate resource requirements for

current systems.

o Modeling - Modeling techniques attempt to predict cost

or resource requirements for the proposed system

without the use of a full-scale development and trial

period. Modelir^ techniques, such as the Federal

Conversion Support Center cost estimation model, are useful durir^ the early phases of the conversion project

planning process to provide an estimation of cost. As

such, they can be useful during preliminary costeffectiveness analyses to determine the cost impact of

proposed alternatives.

165
o Historical Cost Application - The use of historical costs

is generally limited to the refinement of future

conversion phase cost estimates based on cost data

collected for recently-completed conversion phas-^ If historical cost records have been maintained, for

example, the cost of regularly scheduled management

review meetings, these costs could provide the basis for

developing accurate cost estimates for use throughout

the project.

C.5.2 SOFTWARE CONVERSION COST ESTIMATION MODELS

The difficulty in accurately estimating the cost of software

conversion has led to the development of cost estimation models to

provide a simple solution to the estimation problem. While a complete

description of the use of models is beyond the scope of this appendix, the

models summarized below serve as an overview to provide guidance as to

the models currently available at the time of the publication of this

guides that have significant application to federal conversion and the

strength and applicability of each. The use of software conversion

estimation models siiould prove beneficial in the early phases of the

conversion where only gross detail is required and accuracy is not criticaL

These models should be used only with a thorough understandir^ of the

basis upon which the model was developed, the cost elements, functions or phases covered by the model, and the projects in which the model output

has been validated.

o Federal Conversion Support Center Model - The Federal

Conversion Support Center ''FCSC) model was developed

in 1980. The FCSC model is primarily a parametric

software conversion cost estimation model The model

features an excellent breakdown by functions which

facilitates cost estimation. The model includes most

cost elements, and it explicitly states those elements it does not include. The model is sufficiently flexible to handle most complex conversions, and covers essentially

all phases of a conversion effort. While the FCSC model

has not been extensively validated at the time this guide

was prepared, it appears to be the best software cost

estimation model available from public sources.

The FCSC model has several distinct advantages.

Although incomplete, this model does have a comprehensive treatment of costs. The FCSC

model was designed to be applicable to a wide

range of conversions and there are plans for future

enhancements. On the other hand, the coefficients

and values assigned for DBMS and other complex

conversions are untested. Subjective assessments

166
are required in certain cost areas and it does not

recognize effects on conversion costs of over- assignment or under-assignment of personnel. The

applicability of the model appears to be universal.

o Project Management Control System II - Project

Management Control System II (PMCS), which is also

known as the Navy Model, was developed by Naval Data

Automation Command (NAVDAC). It is a parametric

software conversion cost estimation model which is based on batch-to-batch COBOL conversions similar to

those performed in the 1970's at NAVDACs (then Data

Processing Service Centers). PMCS is based on four

similar conversions encompassing over 100 man-years of

work. These conversions were primarily business

oriented, batch, COBOL systems. PMCS is primarily

oriented towards professional staff-days, not towards

dollars. It excludes discussion of costs such as administration, data entry, computer operators, and supervisory

time which can be significant in government ADP operations, but not the associated costs. PMCS includes a management reporting system and automated manpower

estimating aids. Reports produced are, however,

primarily a recompilation of data provided by the user. PMCS is relatively easy to use, validate, and refine, and

is apparently not limited by hardware (assumption of the

model's developers). It contains excellent coverage of

the phases of a conversion effort. PMCS is based on

data of questionable statistical value, because some of

the original data was discarded. Furthermore, the model

is based on major conversion efforts and thus may not be

clearly applicable to small and medium-sized conversion

efforts. PMCS can be used for batch-to-batch, businessoriented, COBOL to COBOL, flat-file to flat-file

conversions.

It is not always possible to draw a distinction among the cost

estimation techniques described above. They do have one common factor

in their use of historical information to predict future events. It should

be evident that if software conversion cost information can be recorded in a detailed and consistent manner, for historical purposes, the accuracy of

the cost estimation process, in general, can improve.

C.6 ANALYSIS OF THE COST DATA

Just as estimation techniques vary according to the requirements of the project for which costs are estimated, the analysis

techniques that are appropriate for each situation depend upon the

characteristics of the project and of the decision being addressed. This

167
section describes several analysis techniques that are applicable to a wide

range of situations. The applicability of each technique is dependent upon

factors such as the phase, function and alternatives analyzed for a

particular project. It is important to understand the value and the

limitations for each technique before attempting to use them for making

decisions.

Certain cost concepts and analysis techniques discussed in this

section must be performed to satisfy the requirements of specific

directives. Where applicable, the discussion of cost analysis includes a

description of how the costs are related to relevant directives.

C.6.1 COST CONCEPTS DEFINITION

The framework and procedures that are presented in this

appendix for developing costs are based upon the concept of full costing.

That is, by defining the full costs of a project in a detailed manner (i.e.,

multidimensional structure) it will be possible to derive cost

classifications from a single cost base. This is important in responding to

directives, since the format and classification of this cost information

may vary. The cost concepts addressed below have been the source of

confusion in the application of cost information. While each concept is briefly discussed, a full definition can best be obtained from financial and

accounting reference material.

o Direct/Indirect Costs - Costs may be classified as either

direct or indirect. The purpose of identifying costs as direct or indirect is to assign all costs as precisely as

possible to the specific product, service, customer or other cost objective they support. Some costs are easily

assigned directly to a product or service. For example,

the cost of programmers that are dedicated to convert a

specific application is a direct cost of that application.

The most common direct costs are for labor and supplies.

Other possible direct costs include travel, purchased

services and service center charges for items such as

printing.

Indirect costs are costs that cannot be directly related

to a product or service, or costs that are insignificant or

difficult to measure. Examples of items that are often

classified as indirect costs are low cost supplies such as paper clips; the labor costs of receiving, storing and

distributing materials and supplies; depreciation of

buildings and general purpose equipment; utilities; and

general and administrative expense for financial

management and other services that benefit the entire

organization. Indirect costs may still be assigned to

specific cost objectives but the assignment is through an

allocation process. The total indirect cost is spread

among all cost objectives according to criteria such as number of people or total budget dollars.

168
Because separating full costs into direct and indirect

costs permits a careful assignment of costs to specific

products or services, it is useful for conversion budgeting

and project monitoring applications. A clear separation

of costs assists managers who are responsible for

controlling resources and costs that are associated with

projects under their supervision. Awareness of the true

cost of providing or receiving services permits managers

to make informed decisions.

o Constant/Current Dollars - The purchasing power of a

dollar during one year is not necessarily the same as the

purchasing power of that dollar during some future year.

Inflation means that more dollars will be needed in the

future to purchase the same goods that are purchased

with less dollars today. The term "constant dollars"

should be equated to "constant purchasing power," that

is, the price of a resource in terms of the purchasing

power of a dollar in some base year. Current dollars

represent the actual cost outlays in the year they are expensed, and show the effect of inflation on the

constant dollar value.

Since both constant and current dollar estimates may be

required during the project (e.g., constant dollars for

economic analyses, current dollars for budgetary

submissions), the software conversion cost estimates

should be developed in such a way as to support both

requirements. This is accomplished by estimating

software conversion costs using constant (base year)

dollars. By applying inflation factors to these estimates,

current dollar figures can they be determined for each

future year.

o Inflation - Inflation is the rise in the general level of

prices over time. Inflation complicates financial

planning and cost analysis because it creates uncertainty

about future prices. Current and past rates of inflation

may be measured by means of price indexes, which are percentage comparisons of the prices of selected

commodities and services between two periods of time.

Future rates of inflation can only be estimated. Once

the future inflation rate is estimated for the years of a conversion project's life, the rate is applied to all future

costs to adjust those costs for projected price increases.

Because inflation affects the prices of goods and

services to be acquired in the future, it is an important

consideration of full costing during any planning or estimating for items that are subject to price changes.

Labor, supplies and utilities are examples of items that

169
may be affected by inflation. The total costs estimated

for each year in the conversion project's life are adjusted

by applying an annual inflation factor to each total.

Software conversion cost estimates should be able to

reflect costs in actual dollar expenditures expected in

each year of the project for budgetary purposes.

Anticipated variations in the inflation rate should be

addressed through sensitivity analysis.

o Wash Costs - The cost of some items may be the same

regardless of which of two or more alternative courses

of action are selected. Although the amount of the cost

may be important, it will not affect the outcome of a

cost comparison among the alternatives. Such costs are referred to as wash costs. For example, if two options are for the government to purchase and operate certain

equipment or to purchase the equipment and hire a contractor to operate it, the purchase cost of the

equipment is a wash cost. It may be a major part of the

total project cost but the cost is the same for the two

alternatives and will, therefore, not contribute more to

the total cost of one alternative than the other.

Under a concept of full costing, all costs should be

included whether a wash cost or not. This is because a

total cost is important for budgeting decisions. Also, it is difficult to correctly identify a wash cost, since cost

components may vary with the alternative selected. For

example, the cost of management is often considered a wash cost; however, a software conversion in a distributed processing environment may require more task

managers and higher travel and administrative costs than

a software conversion in a centralized processing

environment. Another reason for including wash costs in

the conversion costing methodology is that the scope of

the project may change during conversion planning

preparation. Costs which were correctly assumed to be

a wash, now may have a cost impact on the project

decisions. By addressing the full cost of a project, all

cost areas would have been included, whether a wash

cost or not.

C.6.2 ANALYSIS TECHNIQUES

Cost analysis techniques are methods of using previouslydefined and estimated cost data to make management decisions. The

nature of the decision determines the techniques that are most

appropriate for each situation. The following are examples of analysis

techniques that are valuable for management decisions.

170
o Present Value Analysis - Present value analysis is used to

reflect the diminishing value of money with time.

Present value analysis equates future costs to their

present worth. Its primary value is in the assessment of

alternatives that have different cash flows and different

durations.

o Sensitivity Analysis - Throughout the costing process,

various assumptions are made concerning the cost data

used. These assumptions include inflation factors, cost

estimation, workload, etc. As part of the cost analysis

process, these assumptions should be evaluated to

determine if changes in any one assumption will change

the outcome of the analysis.

o Break-Even Analysis - Break-even analysis is used to

study cost relationship between alternatives.

o Ratio Analysis - Ratio analysis is a cost comparative

process which may be used to compare cost data within an alternative, among alternatives or with standard cost

data.

o Risk Analysis - Risk analysis is a technique that uses

probabilities to assess the potential for alternative

outcomes. By assigning probabilities to each alternative

and multiplying by the expected cost or outcome value

of that alternative, a total, expected value can be

determined. In a software conversion project this

technique is important in contingency planning to

develop a plan that assesses potentially harmful events

in a cost-effective manner.

These techniques are intended only as examples of the analysis

methods that are available for use during the project. The use of these

techniques, including their strengths, weaknesses and applicability to

project decisions can be obtained from a review of financial reference

material It is important to remember, however, that the use of various

techniques may yield conflicting results. It is improper to adopt a single

analysis method for use in all applications. The analysis methods must be

applied judiciously, with a knowledge of each method's limitations.

C.7 APPLICATION OF THE COST DATA

The end objective of the conversion costing methodology is support of project management decisions. As illustrated in Figure C-1,

the application of software conversion cost information is directly related

to the manner in which costs have been defined using a dimensional cost

structure. These dimensions allow the application of a single cost basis to a variety of project decisions and activities. In this section the

171
application of costs to specific conversion project decisions and activities

is summarized for each phase of the conversion. While some cost impact

may be shown for every software conversion activity, this section is designed to highlight those tasks which are most dependent upon the

costing information. An overview of economic considerations is given in

Figure C-5 and summarizes the cost detail contained in the body of the

guides.

C.7.1 PROJECT INITIATION PHASE

Project initiation is the phase in which the requirement for a software conversion is determined. The major product of this phase is a

preliminary feasibility study that includes the cost estimates of

conversion alternatives, a comparison and analysis of these alternatives

based on cost and technical factors, and a recommendation of a proposed

alternative. Accompanying this recommendation should be preliminary

project plans that will accomplish the alternative courses of action. Cost

activities during this phase include:

o Analyze the Project Characteristics and Develop the

Unique Project Cost Structure - It is critical to develop

the specific cost structure which is material to the

project under investigation. This will require analysis of

the basic characteristics and goals of the conversion

project, and development of a specific cost structure

which will form the framework for future cost

estimates, cost evaluation criteria, and cost tracking.

This is a major activity which will require careful

planning to assure that the correct structure has been

developed which will allow continuous use throughout the

software conversion effort.

o Establish a Preliminary Conversion Project Budget - The

cost structure should be used for budget preparation by

identifying the estimated project costs for the following

phases in terms of various costs elements and functions.

Also, the scheduling of these expenses should be

established by assessing the priority (cost-effectiveness)

of the project relative to other projects under development.

o Estimate Project Resources - The project budget estimate and schedule can be matched to determine the

availability and utilization of personnel skill categories

to be used. Adjustments in personnel strength can be

made to keep the project within budget and schedule, or

to request additional funds.

Approval of the preliminary feasibility study signifies the completion of

this phase.

172
§1

> <

go

m 1

c z pu

1^

MO O

U w

III

-hil

ml

u a. u. o

E & £ . : i fe ^ S £

t- < I y =

I § 1 5

n 111 I

Se_u(Eoc»_

I!

n

I

° I li

<

e E & £ w uj

•n C

11

<

< ^ e o £ c i88£5S

Is

= 5 £ e

E < " 5 % o £ c.

S

^1

II

< s

s < • isi " c

o

eII

5£

v> o

<il

S E

1 = 1

c f e S £

11 III I.

• • • • •

? 5 X o

i

s:ll

c M i! ^1 = 1 5 I

i e

e

• • • • •

lie I

^

ll

U O < c

?5

C E

* 5 5 - 5 =

S ill

i llliiEl

<iM^ilili c O e S u c B. (ji

4 1

2

(.-> C u. z r

SO to <Ac 5 2 U —

lU

CO

<

CQ

CO

<

lU

9

CO

z

o

o

o

o

o

LU

ir>

I

I.

173
C.7.2 CONVERSION REQUIREMENTS PHASE

During the conversion requirements phase, the conversion

process is analyzed and methods and techniques are selected to

accomplish the effort. The culmination of this phase is a software

conversion study that includes an assessment of the current software

environment, a program inventory, and evaluation of contractor's

assistance and a recommendation as to the use of conversion tools. A

specific costing activity during this phase is:

o Project Planning and Staffing - Conversion cost

information can be used to assist in project personnel

planning by determining the best mix of project

personnel and determining the most cost-effective

project strategy to follow. Cost trade offs between skill

levels, person-hours required, and personnel expenses can

be evaluated for each function during the project. While

this impact on costs is important, it should be evaluated

against management considerations such as expected

turnover, skills back-up, critical staffing positions,

employee development and the like. Furthermore, cost

estimates can be used to assist in evaluating alternative

project execution strategies such as length of phases, use

of contractors, and use of software conversion tools.

For each project management alternative considered, a

cost estimate should be developed to assist in evaluating

the impact of that approach. The final project management approach selected should be based upon the lowest

total overall cost to the organization, given the

constraints of the organization, and the potential for

satisfying the mission needs.

Approval of software conversion study marks the end of this phase and

provides information that feeds the conversion planning phase.

C.7.3 CONVERSION PLANNING PHASE

The conversion planning phase is used to develop the detailed

task schedules and resource requirements needed to accomplish the

conversion. At the completion of these activities a formal conversion

plan is submitted to upper management for approval to continue with the

project. This formal conversion plan should include cost-related

considerations such as a summary of the conversion budget, a description

of the proposed cost-tracking mechanism, and analysis of the costeffectiveness of proposed conversion aids, and a justification for the use

of contract personnel. Specific costing activities during this phase

include:

o Prepare Action Plans - Cost information can be used in

project planning and budgeting to establish a project task

schedule (e.g., PERT-COST and PERT-TIME) that allows

174
for the development of the project in a cost-effective manner. Important considerations at this time should be

the estimated deployment date relative to the expected

operational benefit. The project duration reduction may

increase costs as more overtime or contract employees

are used. This increase in cost, however, may be

justified if the project can become operational sooner,

thereby decreasing operational costs. The cost structure

provides the cost detail for project functions to allow for

this evaluation.

Refine Budget - The budget application of cost

information will aid in identifying the costs for the

current phase, updating project costs for subsequent

phases, and submittir^ the budget for the following

year's effort.

Formalize Conversion Approach - This activity is the

further refinement of the conversion plans developed in

the previous phase. At this point, software conversion

cost estimation models should be compared against a

task-by-task conversion plan to determine the adequacy

of resources (quantity and skills) to complete the

conversion within a suitable time-frame. At this time,

the program manager should examine the alternative

approaches which are available to convert to the new

system. These approaches may include complete

redesign of the system, line-by-line translation, etc. The

program manager will need to evaluate the most costeffective conversion alternative based upon factors such

as the age of the existing software (if appropriate), the

remaining life of the system, and whether it currently

satisfies user's requirements. Furthermore, the cost

impact of the use of outside conversion services,

personnel or tools should be evaluated using the cost

information.

Develop RFP and Evaluation Criteria - If external

support is to be acquired, the conversion costing

methodology can be used to estimate costs, identify

critical cost areas, and provide a cost evaluation

criterion that considers the impact in all relevant cost areas (price and other cost factors). Vendors should be

required to submit cost data in a format that can be

included in the project's cost structure. The conversion

costing structure should then be used to evaluate vendors

based on total project costs that incorporate both direct

vendor charges and other agency project costs associated

with using that vendor. This will require that the cost

evaluation criteria used in the RFP be well documented

175
to allow evaluation of proposals based on lowest project

cost. Technical considerations, such as quality, can be

more easily related to costs through the use of a total

conversion costing methodology. There are certain

service acquisition guidelines (FPMR, FPR, etc.) which

address the cost elements or functions which are allowable in making acquisition decisions. Since these

may be open to interpretation, it is recommended that

oversight organizations be contacted to approve the cost

elements included in acquisition evaluation criteria.

Approval of the conversion plan identifies the completion of the

conversion planning phase.

C.7.4 CONVERSION PREPARATION PHASE

Durir^ this phase, the conversion manager accomplishes the

activities required to assemble the personnel and acquire the facilities

and conversion tools needed durir^ the conversion effort. Costing

activities during this phase include:

o Vendor Evaluation and Selection - Vendor selection

should be based on technical and cost considerations that

account for the impact of a particular vendor's price and

other cost factors on the total cost of the project. A

detailed cost structure would enable the conversion

costing methodology to provide detailed resource cost

information for each vendor to assist in the validation of

cost proposal and to assure an adequate quantity of resources have been proposed. For example, if support

staff is included in the proposal, a detailed cost

structure would identify the level of skills, person hours,

and salary proposed by each vendor. In this way,

significant deviations between vendors may be

addressed. Finally, the conversion costing methodology

can be used, through sensitivity analysis, to identify the

cost areas most critical in the vendor's proposal

evaluation and selection. These areas could then provide

a basis for incentive clauses in the acquisition contracts.

o Establish Deployment and Delivery Schedules - The

timing of the deployment of the converted software and

delivery of the proposed resources affect software

conversion. There will exist various approaches and

possible timetables for accomplishing deployment and

installation. Each schedule may have cost impacts in

terms of the potential net benefits derived from the

project. The cost trade off objective involved in this

scheduling effort should be the lowest total cost of the

project.

176
o Develop Plans and Budgets - Through the use of

historical project costs contained in the conversion

costing methodology, the project budget, task schedule

and resource assignments can be developed for the

conversion phase. Cost considerations such as the use of

overtime or contract personnel, short-term rental of

additional equipment and space, and the impact of

disrupted agency workload ^ould be addressed.

When preparations are complete the conversion phase begins.

C.7.5 CONVERSION PHASE

During this phase, the actual conversion of software from the source to the target environment is accomplished This phase will

contribute to a significant amount of the total conversion cost but will

have relatively few requirements for cost information other than the

following activity:

o Evaluate Conversion Effort Against Conversion Plans - The conversion costing methodology can provide a

detailed cost structure with which to accumulate actual

cost data that can be used to compare actual cost

performance data with historical estimates. In this way

differences can be easily identified for further analysis,

and the full cost impact on the project can be evaluated.

This will require that the acceptance cost data be

recorded consistent with the cost structure.

Acceptance of the final converted system, fully documented and tested,

marks the end of the conversion phase.

C.7.6 POST-CONVERSION PHASE

The post-conversion phase is des^ned to provide an

assessment of the completed project and prepare the organization for

future software conversions. As such it is a continuous process with no

clearly defined end point The use of software conversion costs during

this phase consists of the following activities:

o Post-Conversion Analysis and Assessment - The analysis

of project performance should be performed as part of a post-implementation audit. The conversion costing

methodology can assist in this validation by providing an

historical cost basis and audit trail against which actual

performance data can be measured. If actual system

performance significantly deviates from planned system

performance, the conversion costir^ methodology can

help identify the cost areas and reasons for the

differences. The function and product dimension of the

177
cost structure can assist in projecting user's charges and

evaluating the cost-effectiveness of changing user's

requirements, and their impact on these user charges.

Satisfy A-12 Requirements - 0MB Circular A-12 requires

development of annual agency long-term plans to support

budget submissions. Such plans project agency

requirements for five years or longer. Conversion

costing methodology is directly applicable to conversions

considered in these plans.

Agency Budget Submissions - Similar to A-12

requirements, conversion costing methodology supports

agency budget actions.

Satisfy A-'^S Requirements - 0MB Circular A-76 requires

regular assessments of £^ency commercial-industrial

type activities to weigh the benefits of continual

government operation against contractor operation.

ADP services fall under the provision of A-"6.

Conversion costing methodology can be usefully applied

to any agency A-76 studies conducted during the postconversion phase.

Satisfy A-109 Requirements - 0MB Circular A-109

requires cost analyses to be performed for major system

acquisitions. Large scale agency hardware replacements

are frequently considered to fall under the provisions of

0MB Circular A-109. The conversion costing

methodology will directly support A-109 conversion cost

assessments.

Satisfy A-121-Requirements - 0MB Circular A-121

prescribes the initiation of business-like procedures that

require agencies to account for the full cost of operating

a DP facility, to allocate all costs to users according to services they receive, and to share excess DP capacity.

These costs, when developed, rarely include the costs of

conversion and lead to under resourcing conversion

staffs. By maintaining the conversion costir^

methodology and accounting for cost incurred according

to its structure throughout the life of the project, the

cost information used in satisfying A-121 should be

available. The conversion costing methodology provides

the structure, through the use of organization and

product dimensions, for allocation of conversion costs to users according to service provided.

178
APPENDIX D

CASE STUDIES

179
SUMMARY

This appendix contains eleven ease studies of software

conversion projects at Federal agencies. Some projects had been

completed;- others were in planning and execution stages when these

studies were developed They provide additional insight into software

conversion problems and illustrate that management attention is necessary to improve conversion efficiencies. Readers of this guide may

find situations analogous to their agency conversion environments and

take action to preclude repeating mistakes made by others.

180
AGENCY 1 EXPERIENCE

BACKGROUND

The organization discussed is an element of a federal agency

and is a user of the agency's computer system (approximately 10% of

machine time). The organization had an in-house staff of programmers

and analysts to develop and maintain its automated information systems.

The ADP department of the agency acted as a service bureau to other

departments and organizations in the agency.

Because of saturation, the agency decided to upgrade its IBM

360/65. A competitive procurement resulted in selection and installation

of a UNIVAC 1100/43 system. Because of the results of the competitive

procurement, the organization, as well as other users of the hardware

executed a non-code compatible software conversion.

This conversion experience illustrates problems associated

with such a conversion as weU as problems facing users of a large,

"service-bureau" type of operation.

THE CONVERSION

Application programs on the IBM 360/65 were written in

COBOL, PLl, FORTRAN, Assembly Language and RPG. Approximately

75 percent were written in the latter lar^uage. Little, if any, software

documentation existed for the IBM applications. There were many user enhancements which were pending but not incorporated in the old

software because machine saturation precluded development and test

time.

The decision to upgrade was made in the 1975-1976 time

frame. Conversion planning started in mid-1977 and the target hardware

was installed in mid 1978.

Soon after selection, UNIVAC made computer time available

through Remote Job Entry (RJE) stations. This service was convenient,

and facilitated the conversion. However, this service was not used to

(^timum advantage in accompli^ing early training and software

conversion. The failure to use this resource to fuU advantage ultimately

contributed to conversion slippage.

The organization decided to convert and redes^n applications

concurrently into a DataBase Management Systems (DBMS), System 2000.

It was anticipated that aU applications could be converted before the IBM

system was released. However, this did not occur. Although the IBM

hardware had been removed in late 1980, as of January 1981 the

conversion was still in progress and expected to take an additional year.

The loss of this hardware resulted in a line for line conversion of some old

181
applications without redesign and without parallel testing. Nine major

DBMS applications were active with approximately 400,000, 40-60

character records. Four similar applications remained to be built.

Information system users of the system were not sympathetic

with conversion problems and continued to demand enhancements. No

systems were frozen during conversion. Higher-level management was

extremely interested and involved through hardware acquisition and

installation. Thereafter, there was little interest or backir^ for any

processes which would have eased conversion, i.e., freezing development.

Conversion was accomplished in-house. The conversion staff

lost personnel without replacement due to a hiring freeze. Summer hire

students were used as programmers but their short employment period did

not compensate for personnel shortfalls. In retrospect, it was recc^nized

that some contractual support should have been provided for personnel

loss contingencies, even if not exercised.

Before conversion started, code conversion was expected to be

the most difficult processes In fact, code conversion was

stra^htforward. However, old programs were heavily dependent on IBM

utilities and the conversion staff encountered extreme problems in

applying UNIVAC utilities, which differed considerably from those offered

by IBM.

The IBM systems programmers had detailed knowledge of the source system and were extremely helpful to the organization's

application programmers. Target systems programmers were new and

lacked agency ins^ht and experience. System programming support to

the applications programmers dropped dramatically during conversion.

Associated problems in ddjugging and adapting to the target software

delayed conversion by approximately six months and extended parallel

testing.

Conversion costs were not tracked but were estimated to have

consumed 3 person-years of effort.

MANAGEMENT LESSONS

In summary, lack of planning led to an underestimation of

conversion resources and precluded early training and conversion on the

RJE station. Conversion managers did not anticipate the need to handle

unforeseen problems such as differences in software utilities and

inexperienced systems programmers. These problems were compounded

by not freezing development and incorporating new user enhancements in

conjunction with the conversion.

182
AGENCY 2 EXPERIENCE

The followir^ is a case history of a software conversion

experience that took place from 1974 to 1980 at a federal agency.

BACKGROUND

The agency operates a large centralized service bureau

computer system serving various agency departments and other

government agencies. Saturation caused the agency to convert from an

IBM 36n/65 to two IBM 37^/1 and then to an AMDAHL in 1979.

Approximately 55 percent of the code was FORTRAN, 45 percent PL"*,

and 5 percent COBOL. In every case, migration of application programs

was to code-compatible machines. However, there were conversion

problems in converting to the AMDAHL that are useful as learning

vehicles, particularly from the perspective of a service bureau operation.

THE CONVERSION

The agency allowed one year for planning purposes but

considered that two years would have been better. The biggest problem in

conversion planning was obtaining user's input. Neither users, nor anyone

else, knew the status of all the available programs. Purging outdated

code, old test code and duplicate programs was a difficult exercise.

Although users were charged a pro-rata fee for service and machine time, resources were not applied to storage. Hence there was no incentive to cause users to remove unwanted code or data from the inventory.

One person was assigned to the conversion fuU-time and

served as project manager. While the conversion was viewed as

successful, it was considered that better coordination and interaction with

users and managers could have been effected if more people had been

dedicated to project management activities. Such assignment was

precluded due to the agency chargir^ scheme. User's charges were based

on normal, day-to-day operating costs such as machine use, line costs,

utilities, and program mir^ services. There was no built-in overhead to cover project management personnel required for software conversion.

Continuous negotiations had to be conducted with users to provide the

extraordinary project management resources associated with the

conversion. Essentially project management resources were understaffed.

Adequate documentation on application programs was

unavailable. This condition was due in part to the nationwide spread of users who were responsible for developing their own application programs.

Additionally, users continued to develop and enhance systems throughout

the conversion. These factors, coupled with the outdated code in the

inventory, caused difficulties in developing software conversion

specifications.

183
High level management was primarily interested in hardware

procurement and installation. The next level of management (functional

information system users) were primarily interested in keeping

applications under development

Some planning is now in process for the next conversion. The

use of software standards is being stressed alor^ with documentation.

Given the limited control the processing center has over user's

applications, the achievement of acceptable use of software standards and

documentation was questionable.

MANAGEMENT LESSONS

In summary, there were problems with high level management

involvement, user's support, program specifications, detailed planning and

project management resourcing. Had these problems existed in a non- code-compatible environment, serious problems would probably have

resulted. The selection of a code-compatible machine resulted in the

conversion being accomplished in an acceptable time. However, the

conditions that could have caused problems for a non code-compatible

conversion still existed.

184
AGENCY 3 EXPERIENCE

BACKGROUND

The agency is responsible for management of world-wide cai^o

traffic. A significant functional area involves port cargo operations. For

some time port cargo operations were supported by a management

information system (MIS).

Dual Burroughs 5500 computers were operating at two area headquarters locations, one on the East Coast, and the other on the West

Coast. The B5500 computers were linked to IBM 360/20 terminals located

at offices at various ports (e.g. Seattle, New Orleans) The MIS handled

movement control, manifests, container transhipments, and other traffic

management applications generally oriented to export cargo, as well as retrograde cargo.

Growth in cargo movement administration had saturated the

B5500 computers. Given the age of these computers and the IBM 360/20

remote job entry (RJE) terminals, continued reliance on this equipment

posed a risk to system reliability. Software enhancements were difficult

to introduce, particularly on-line applications. While the MIS was

originally a standard batch-oriented system, the B5500 computers would

support remote terminals. Differences in the degree of saturation at each

area headquarters had resulted in some capability for on-line applications on the West Coast. However, aU applications were batch on the East

Coast, due to the inability of the B5500 to process the higher cargo

volumes in an on-line mode. Because of these conditions, in the mid

197 O's, the organization decided to upgrade the system with the following

objectives:

o Modem equipment,

o On-Line applications,

o Sufficient processing capacity to handle extraordinary

cargo movements loads,

o Improved redundancy and reliability,

o Standard applications on both coasts,

o Stand alone capability at various ports.

THE CONVERSION

Planning started in the summer of 1978. Honeywell Level 6

computers were selected as the target hardware. The initial planning

resulted in a systems conc^t which was approved in October 1978. The

185
concept called for replacement of the B5500 computers as soon as

possible with dual Honeywell Level 6 computers at the two area

headquarters, and replacement of the IBM 360/20 terminals with single

Honeywell Level 6 computers The concept also provided for transfer of

some of the non-time sensitive, historical, high-volume applications to the

agency headquarters for processing on a HIS 6060 mainframe which was

already in place. The combination of modem hardware and revised

application processing covered all system-upgrade objectives.

After the concept had been approved, detailed planning

commenced in early 1979 and continued for six to nine months Thorough

planning, early in the project, was recognized as necessary to successfully

execute the project. This planning was accomplished by a management

team which was organized for the purpose. Planning was a continuing

function, ongoing midway through Uie conversion, and was expected to

continue until the conversion was completed. There were always

unforeseen events which had to be compensated for and which required

revised plans.

Automated (PERT) planning tools, available through

Honeywell, were tried without success. Planners felt that the extra

effort to enter all of the project data did not result in automated planning

aids which were any better than those manually-produced.

PROJECT MANAGEMENT

The management team was essentially a project management

effort. Originally it was envisioned that the team could be dissolved after

it had planned the schedule and identified all activities and actions which

had to be accomplished (e.g., equipment selection and acquisition,

software conversion, communications specifications, and training). The

team was temporarily dissolved, but it soon became apparent that the

project was losing coordination and direction. Formal project

management was reconstituted on a permanent basis before any adverse

developments occurred.

SOFTWARE

There were over 900 source programs to convert. Most were

written in COBOL-64 and 68 except for a few FORTRAN applications.

No new user enhancements were introduced during the conversion. The

conversion was essentially a line for line conversion modified by introduction of some Honeywell input-output and transaction handler routines used

as a matter of expediency. An automated Honeywell tool was used to

convert B5500 applications to be transferred to the HIS 6060 mainframe.

This tool was modified in-house to convert the target software to be

placed on HIS Level 6 computers. New enhancements and redesigns,

primarily on-line applications, were scheduled for development after the

conversion.

186
The old B55<^n system documentation was often incomplete,

causing problems in planning and in developing conversion specifications.

The new system will be completely documented using government

standards. Documentation was ongoing concurrent with software

conversion.

MANAGEMENT AND USER'S INVOLVEMENT

Top agency executives backed the project from its inception.

Management understood the operational advantages of a speedy

conversion and the problems associated with the conversion This

management support was also conducive to good functional user's

cooperation. The project management interacted regularly at all user and management levels to keep these parties appraised of progress arrf involved in meeting requirements.

FUNDING AND RESOURCES

Because the project was well planned in the beginning,

adequate resources were identified, programmed and budgeted to support

the equipment, communication, site preparation, and training. The

software conversion was accomplished with in-house resources. STATUS

Preparation for conversion started in the fall of 1979. Actions

during this phase included assembling and modifying the software

conversion tools, site preparation and installation of target computers.

Conversion actually started in early 1980. All conversion was to be

completed by late 1981. Individual subsystems would undergo parallel

testing until all users and manners were satisfied. Parallel testing

operations would be supported by existing resources. As of January 1981,

the project was on schedule. This condition was primarily due to good

planning, active project management and user and management

involvement and support. The source computers were scheduled for

release in the fall of 1981 at Western Area and the ^ring of 1982 at

Eastern Area.

MANAGEMENT LESSONS

This case history illustrates that the advantages of achieving

high level management and functional user's support, develc^ment

freezing, good planning, and adequate project management can result in an efficient software conversion accomplished on time and within bucket.

187
AGENCY 4 EXPERIENCE

BACKGROUND

The federal agency interviewed was responsible for bi-monthly

mailings of computer output, and had definite schedule restrictions. The

agency was running its systems on old UNIVAC/Spectra hardware. During

the 1975 time-frame, management decided that the system was saturated

and further enhancements of the current system would no longer be

effective. A Honeywell computer was selected as the target hardware.

The Spectra was running over 20 systems consisting of 270,000

lines of assembler code, and 30,000 lines of COBOL. Conversion was to

be to COBOL/68. The agency had adequately documented its system

according to FTPS PUB-38.

THE CONVERSION

A conversion project team with 19 programmers/analysts was

organized. Tasks included conversion, maintenance, and operations with

50 percent effort on conversion and 50 percent on maintenance.

One special consideration and concern in this project was the

conversion of compressed assembler code with over 600 file formats and

100 different record types. Because record control bits were used to

identify field length and absence of data, the conversion from EBCDIC to

Honeywell BCD was of critical concern.

Contractor services for conversion assistance was for a cost

plus fixed fee (CPFF) contract at a cost of $1.7 million. Assembler

Lar^uage to COBOL/68 automated tools were developed by the

contractor. These tools were fairly successful but manual coding for

special extensions was still required. Another tool was used to compress

data files.

Of the twenty systems to be converted the ten smallest were

converted first. During their conversion, significant problems became

apparent Some converted programs were far less efficient on the target

hardware than the source hardware. Midway through the conversion

effort, target hardware was changed to an IBM 3231, and the remaining 10

systems were converted to this hardware The IBM software was

compatible with that of the source software and conversion was much

simpler.

Prior to the conversion, the agency had provided back-up

services with a time-sharir^ firm in case conversion hardware facilities

went down. The agency was also prepared to keep and maintain the old

Spectra hardware until all systems were converted.

188
MANAGEMENT LESSONS

While adequate planning was spent in converting master files

and development of test data, little effort was expended in developing and

analyzing benchmark criteria. This was exemplified by one system's 14

hour run time on Honeywell target hardware compared to 55 minutes on

the IBM target hardware.

Software conversion managers did not participate in hardware

procurement decisions In both instances (conversion to Honeywell and to

the IBM), the software manager was notified after the hardware was

procured. This left inadequate time for planning. The software project

manager was also unable to prevent users from ordering enhancements.

The conversion team was able to deal with this, but the project would

have been easier, had software been frozen. Upper management did

intercede, at times, when user's requests were unduly affecting the

conversion effort.

Financial planning was also inadequate. Thoi^h the contractor

came within budget, there would have been a cost-overrun had the target

hardware not been changed to a code-compatible configuration.

189
AGENCY 5 EXPERffiNCE

BACKGROUND

The organization interviewed was responsible for maintaining

up-to-date information on world-wide activities, and distributing this

information to field offices around the world. This organization was one element of many within the agency.

The information files, which constituted the bulk of the

automated effort, were extensions of applications that had been

maintained for many years on punch card accounting machines. These

files were migrated to an IBM "60/40, which was acquired in 1969, and

placed on a DBMS.

In 1973, the vendor supporting the DBMS cancelled support.

This resulted in a decision to convert to another DBMS. Conversion was

to be completed within 6 months.

Situation at Project Initiation

o Batch applications, approximately 75 percent of a

sequential workload, were running on an IBM 360/40 3

shifts a day, 7 days a week.

o No programmers, users or analysts were trained in the

new DBMS.

o There was a programmer and analyst staff of 18.

o The staff, which had recent conversion experience

before was still in place.

o High-level management agreed to halt all enhancements

to existing applications This caused user's support of

the project, at least to the extent that they couldn't

pressure the ADP staff to continue enhacements and new

developments.

THE CONVERSION

A straight redes^n conversion was planned without

incorporation of new user's enhancements.

A project management team was established. The supervisor

of the analysis and programming section was the team^iead, assisted fulltime by the lead systems analyst. The most competent developmental and

maintenance programmers (approximately four) were added to the team

full-time. One input-output control technician was also added full-time.

190
The complete lack of any staff trained in the new DBMS was a

serious problem. This problem was compounded by the lack of experience

in newly-trained programmers, and the short project deadline.

Coordination with a mobile training team revealed locations where new

DBMS training was scheduled. Coordination with organizations scheduled

to receive new DBMS training produced a few slots to train project team

members as early as possible. The training team also cooperated by

adjusting their schedule to provide on-site analyst, programmer and user

training to most of the remaining conversion team approximately one month after project's initiation. This was aifficient to accomplish the

conversion.

No contractor's assistance was used. The most complex

system was chosen for the initial conversion It was assumed that if the

project management team could convert that application, the remaining

applications would be problem free This approach produced successful

results.

Freezing new user's enhancements and system development

provided enough computer time for training and conversion except for two

two-week periods late in the conversion process. Arrar^ements were

made with back-up computer facilities to provide processing time during

those two week periods. Small teams of computer operators,

maintenance programmers and a system programmer were dispatched to run production reports and applications.

At the conclusion of the six-month period, the conversion was

complete. However, all converted applications had not processed in

parallel for a two-month period to allow debugging and assure quality

controL Parallel testing operations continued for two additional months.

Moreover, while documentation was an ongoing effort during conversion,

full sets of systems documentation were not completed until

approximately four months after the conversion effort.

Unbudgeted conversion costs were mostly absorbed by

cancelling or limiting projected travel and carefully monitoring operating

costs for the remainder of the fiscal year. A mid-year request for

shortfall-funding provided the additional funds necessary to cover all

costs.

MANAGEMENT LESSONS

This conversion, which was essentially accomplished on time,

received high-level management support, and benefited from the freezing

of new enhancements and development Full-time project management

and an experienced staff had the insight and authority to overcome

problems associated with a short conversion deadline and inadequate

training.

191
AGENCY 6 EXPERIENCE

BACKGROUND

In 1973, the agency developed 15 administrative data base

management system applications supporting ^ency training. These

applications were run at night as batch on a Honeywell (HIS) 635

computer, the daytime hours being primarily reserved for on-line student use of the hardware system. There was no requirement for student access

to the administrative applications. However, the staff and faculty did

require access at times during the day.

Besides the training-related administrative systems, there

were approximately 300 various agency installation-unique COBOL

programs which were processed, as required, at night on the HIS 635.

By 1974, the on-line demands of all users exceeded the

capacity of the HIS 635 system. Efforts to upgrade, sole source, were

denied and competitive hardware procurement and software conversion

contracts were pursued. To resolve saturation problems the agency was

permitted to upgrade the hardware to an HIS 6080 System as an interim

measure pending completion of the competitive procurement.

THE CONVERSION

UNIVAC won both the hardware and training-related

administrative application conversion contracts. A UNIVAC 1100/11 was

selected to process the COBOL and administrative applications. A

UNIVAC 1100/12 was selected to provide time sharing service to the

student body. Separate from UNIVAC, another contractor was awarded

the contract to convert the agency unique COBOL programs.

It was decided to redesign the administrative DBMS

applications to another DBMS offered by UNIVAC and to convert the

COBOL programs line by line.

There were problems with development of the UNIVAC DBMS

software conversion specifications. Users were not interested in

collaborating in the specification definition effort. They were relatively

satisfied with the existing DBMS applications. Since the input and output

would remain essentially unchanged, the users were not inclined to

emphasize to the conversion planners the subtle but important insights or considerations relating to timing of reports or relationships of certain

reports to others. While these relationships were probably understood by

the in-house team that developed the specifications, they were not

adequately stressed, and ultimately not comprehended by the contractor.

Futhermore, the original software documentation was outdated or nonexistent. This condition contributed to conversion specification

inadequacies.

192
Conversion from one major DBMS to another resulted in an extremely complex software design effort The complexities of the

project, when coupled with specification shortfalls, resulted in disputes

with the contractor, project slippage and generated considerable

unanticipated involvement in the conversion process by the in-house staff

of programmers and analysts.

The agency insisted that the UNIVAC contractor develop

complete software documentation based on FIPS Publication 38. The

contractor sought release from this requirement Disagreement over

contractual conditions relating to documentation requirements and

specification shortfalls resulted in slippage of the conversion effort

approximately 9 months past release of the HIS 6080. This condition

precluded parallel testing of some applications.

Disagreement over contractual levels of effort with the

second conversion contractor over a lack of COBOL programs

documentation led to disputes which resulted in contractor conversion of

approximately 90 percent, rather than all of the software. Twenty-four,

or 10 percent of the applications, were converted in-house. The

contractor did not provide any documentation. The agency intended to write the documentation in-house but recognized that in reality some or

all of the program documentation would never be developed.

It was estimated that all software conversions could have been

accomplished in-house for the same effort spent in resolving all

contractual software conversion issues.

Analyst and programmer training on the new system was

considered sufficient but was conducted too early. Maintenance

programmers lost their technical edge due to too much elapsed time

between training and delivery of the contractually-developed DBMS

software for their maintenance.

Formal processes were established and adhered to regarding

review of contractor performance and recording user acceptance of

converted applications. These processes assisted in conversion by

improving understanding, reducing slippage and monitorir^ costs.

FuU-time project management had not been exercised in the

pre-conversion phases and resulted in planning shortfalls (e.g., inadequate

software specifications and training). To remedy this the software

conversion process operated under the project manager concept. This was

considered invaluable in resolving unanticipated issues. It was also

considered essential that a contractor have a full-time project manager

throughout the project. This had been the case until the contract was

extended to compensate for slippage. At that time, the contractor

project manager's position was abolished in an attempt to reduce costs. Thereafter, internal contractor coordination and management problems

developed and adversely impacted productivity.

193
MANAGEMENT LESSONS

This case history Illustrates the need to have software well

documented. Documentation facilitates conversion planning, development

of software specifications and contractual statements of work. The need

to maintain full-time project management throughout a conversion was

also shown. Management recognized the need for software documentation

but experienced problems with the contractors who resisted delivery of

documentation.

194
AGENCY 7 EXPERIENCE

BACKGROUND

The agency is responsible for the regulation of a major

industry. To administer the programs necessary for compliance with its

regulatory responsibility, the agency utilizes the services of its data

processing division to track various equipment, licenses, and applications,

monitor violations, and other administrative functions such as payroll and

personneL

Aging hardware and systems growth resulted in a conversion

from a UNIVAC 3 to a Honeywell 6023 computer system. Conversion

consisted of some 30 systems encompassing 260 programs written in SALT

(assembler) and translated into COBOL.

Planning for the conversion began in late 1973. By that time

replacement parts for the UNIVAC 3 had become difficult to obtain and

often required cannabilizing other UNIVAC 3 systems. The workload had

reached a point that the agency rented time on a UNIVAC 1108 to handle

its UNIVAC 3 overflow. The agency developed specifications for its

conversion after holding discussions with conversion specialists. Separate

hardware and software conversion RFPs were prepared and released in

1975. Honeywell won the hardware selection while another contractor

was awarded the software conversion project.

THE CONVERSION

Under the terms of the software RFP the agency was to

provide system documentation, programs, test data and machine time to contractors. The specifications, however, allowed the contractor to

request virtually unlimited levels of detailed documentation, and that test data be in contractor specified format. These conditions placed

unanticipated workloads on the conversion project team Program

acceptance was based upon successful execution of 90 percent of code.

However, no performance specifications were required. As a result,

processing that had previously required two shifts on the UNIVAC

required three shifts on the Honeywell This condition indicated that the

software was inefficient in design.

Some 2,000 data files ranging from 2,000 records to 7-"

million records per file were required to be converted. To convert these

files, the agency had to temporarily acquire a minicomputer at an

additional cost of $25,000. A "bit to byte" format change had to be

accomplished because of software differences between source and target

systems and caused considerable problems for the agency.

The conversion staff consisted of seven full-time and two

part-time personnel who handled the data conversion effort along with

195
two full-time (on-site) contractor personnel for 12 months. The number

of contractor personnel working off-site was unknown. What was initially

estimated as a 9-12 month conversion effort actually required two years

(in addition to one year spent in planning and procurement) for a total of

21 man-years of effort. Both the schedule and budget ($1 miUion) were

overrun.

Because of continuing growth, the agency again upgraded to a Honeywell 6640 in 1978, and in late 1979 upgraded tg a Honeywell 6660.

These migrations, being code-compatible, were accomplished with

negligible problems.

While existing systems and operations documentation was

adequate, the contractor was required only to document the operational

procedures (run manuals) for the H6023. System/program documentation

was left up to the agency.

There were no ongoing plans for future conversions although

the £^ency had upgraded hardware twice since the conversion to the

Honeywell 6023.

MANAGEMENT LESSONS

The conversion and budget overrun were indicative of poor

initial planning. Also, the software conversion contract was constructed

to the contractor's advantage which adversely impacted the conversion

staff efforts. This resulted in loss of project management control over

the contractor, produced programs with exceptional run times (indicative

of poor software design), and caused delivery of inadequate software

documentation.

196
AGENCY 8 EXPERIENCE

The followir^ is a case history of a software conversion

experience at a federal agency that started in late 1976 and was still

ongoing in Fdjruary, 1981.

BACKGROUND

The agency was heavily involved in simulation and modelling.

There were approximately twenty major models running on a UNIVAC

1108 using EXEC 8, Level 33. The models were large-scale, mostly

written in FORTRAN, with some COBOL used The twenty major models

consisted of approximately 200,000 lines of code in FORTRAN and 50,000

lines in COBOL. Other models and systems doubled the lines of code to

approximately one-half million.

In late 1976, ADP personnel determined that the system was

saturated; models were taking too long to run. A hardware RFP was

released in February 1979. UNIVAC won and a UNIVAC 1182 was

installed. The source and target system machines were expected to run in

parallel for approximately six months. The RFP required a preinstaUation test facility nine (9) months before the new mainframe was

installed.

THE CONVERSION

Prior to releasing the RFP, aU models were scanned and code

was analyzed for vendor specific extensions. Problems were noted in two

areas:

o Word size,

o Representation of character type data.

It was decided that software conversion would be done by inhouse personnel Contractors would require too long to familiarize

themselves with the models Agency functional users were also the

programmers, were the most familiar with their own models, and

considered best able to perform the conversion. Additionally,

documentation was inadequate and outdated, adding to the difficulties of

indoctrinating contractors on mechanisms of the models. Automated

tools were also examined but determined to be ineffective.

A detailed software conversion requirements study was not

performed. In-house personnel were expected to handle the conversion in

addition to their regular duties; no specific planning or thought was

accomplished to address the difficulties associated with this option.

Software conversion was thought simple and no major problems were

expected. A project team was not organized, and no cost estimation was

performed

197
The conversion itself proved to be straight forward because a code-compatible machine was selected. UNIVAC was the only

respondent Operating systems were very similar and few problems were

encountered during the conversion. However, management personnel did

not plan adequately for site preparation. Because of delays in getting

GSA approval for site preparation, the 1182 had to be installed in a UNIVAC facility. GSA, as of February 1981, had yet to approve the site

preparation.

MANAGEMENT LESSONS

The agency was extremely fortunate in obtaining a codecompatible machine In spite of a previous conversion experience that

had proven very difficult, conversion requirements were relegated to a minor role. No planning or cost estimation was performed.

Also, the lack of adequate model documentation would have

impacted on conversion if a non code-compatible machine had been

selected. The models, maintained by users who understood the code ami

model scheme, contain modifications that were rarely documented.

Despite the potential conversion problems posed by this lack of

documentation, program documentation was not being pursued.

198
AGENCY 9 EXPERIENCE

BACKGROUND

This agency was in the planning and procurement stage of a software conversion to meet increased mission needs and requirements.

Their applications were being processed on a variety of hardware

configurations within the agency, consisting of a Honeywell 635, two IBM

3032s, a HoneyweU 6000 and a Honeywell 6060. In addition, a DEC2020

and five PDP ll/70s were included in their hardware inventory.

PLANNING

Although the planning and procurement process had been ongoing for two and a half years, the RFP has not yet been awarded; thus

target hardware was still unknown as of February 1981.

It was estimated that the conversion effort itself would take

two years and that the total conversion process including planning and

procurement, would last four and a half to five years.

Various off-the-shelf automated tools were currently being

evaluated to handle the common compiler driver language types. For

example, plans called for automatically converting COBOL/68 to the

more efficient COBOL/74. In addition to COBOL their basic software

packages in use included FORTRAN, PL/1, SIMSCRIPT, GYPSIE

(graphics), SPSS, as well as a variety of ad hoc query/update routines.

STAFFING

Although the bulk of the conversion was to be accomplished by

in-house personnel, provisions called for a one-year task order type

contract to be awarded for assistance as needed, during the conversion. It was projected that one third of the conversion would be accomplished by

the use of automated tools, one third through recoding, and the remaining one third would require some degree of redesign.

There were 675 people assigned to the agency data center, 600

of whom were programmers. Approximately 100 project officers, and

their staffs would be responsible for actually accomplishing the

conversion. Each project officer would be assigned responsibility for one

or more systems. Reporting to each project officer would be a variety of

programmers and analysts. It was projected that 200 people would be

involved at any one time in conversion duties. Two miUion dollars was

budgeted for an estimated 400 man-year effort

199
MANAGEMENT LESSONS OR OBSERVATIONS

For a conversion of this magnitude, it was planned

significantly far enough in advance to allow adequate time for staffing,

identifying, and evaluating activities. However, two major shortfalls

were observed:

(1) The budget of $2 million appeared extremely low. A

more realistic budget was estimated at $6 - 9 million.

(2) User and system documentation was not satisfactory.

Although standards were being examined, this critical area had not been

stressed. Lack of acceptable documentation would most probably

complicate future conversion efforts.

200
AGENCY 10 EXPERIENCE

BACKGROUND

The agency interviewed was responsible for maintaining an

inventory of equipment and supplies at locations throughout the world.

The agency maintained statistics on equipment failure, and adjusted the

maintenance schedule as indicated by these statistics. Programs were

written in COBOL and Assembler, and the data base management system

was TOTAL 7. The primary environment was in on-line/real time mode.

Management decided to upgrade the system in late 1977, and

plans were made to release an RFP to procure new equipment. The

source machines were IBM 360/40's. IBM 4331 machines were selected as replacements.

THE CONVERSION

Approximately two years of planning was performed prior to

release of the Requests for Proposals. Durir^ this planning phase, though

target hardware was unknown, the following activities were performed:

o A project management team was assembled,

o Programs were inventoried,

o Schedules and milestones were determined,

o Management hierarchy was developed,

o It was determined that conversion would be performed

in-house by users (programmers and functional users were the same),

o Formal test procedures were developed.

The conversion went fairly smoothly. Software was not

completely frozen, however, and some incorporation of new user enhancements was accomplished. Some problems were encountered with

vendor extensions operating on the 360/40's. Weekly meetings, held with

the project management team and programmers, kept all participants

aware of problems that other personnel encountered.

At the conclusion of the conversion, the ^ency initiated a system to examine both the positive and negative aspects of the

conversion in the interests of facilitating future conversion efforts.

201
MANAGEMENT LESSONS

The major shortfall noted in this conversion effort was a lack

of cost analysis and accounting. Though progress was tracked, costs were

not Thus, the agency had no detailed knowledge of the actual conversion

costs to use in planning and estimating future conversions.

Planning activities appeared to be adequate and these plans

were implemented during the conversion. The following activities were

cited as being beneficial to the effort:

o Developing bar charts depicting milestones; these were

easy to follow.

o Developing and implementing a conversion-reporting and

management hierarchy; personnel knew who to report to.

o Holding regular meetings; information was disseminated

to the staff.

o Availability of adequate documentation.

202
AGENCY 11 EXPERffiNCE

BACKGROUND

In June 1981, a federal agency was in the planning and

preparation stage of a software conversion. Due to problems with the

aging CDC 3300 computer, the agency was preparing to convert

applications to a AMDAHL 470V/7A computer.

PLANNING AND PREPARATION

The agency planned to convert 600 programs estimated at

700,000 lines of code encompassing approximately 24 major applications.

All applications were business-oriented in nature. Processing was batch

but was expected to shift toward some on-line DBMS with the recent

acquisition of IDMS on the AMDAHL.

Due to hiring freezes and budget constraints, the ADP staff was short of six full-time program mer/analysts. Because of this

manpower shortage the agency was conducting preliminary negotiations

for contractor's conversion assistance. The contractor would have

responsibility for selection and/or development of any automated tools to

be used.

The user's community, consisting of 14 major functional users had been notified of the upcomir^ conversion. Functional users were

cooperative and constructive but plans did not anticipate a heavy user involvement in the conversion. Current plans called for off-site unit

testing at another computer facility, with system and parallel testing

being conducted on the AMDAHL.

The conversion manager was not assigned full-time and had to direct not only the conversion project but also conduct normally assigned

duties as welL

The team had no prior conversion experience, and as a result, no comprehensive conversion plan was developed. Although the planning

process was still being formulated, the entire scope of the planning effort

had not been determined. It was estimated the conversion effort,

excluding planning, would take 18 months, and that the total conversion

process, including planning and preparation, would take 2 and a half years.

MANAGEMENT OBSERVATIONS

Considering the scope of this conversion, this agency did

reasonably well in their planning, preparation and identification of many

potential conversion problem areas. They assigned conversion priorities.

They recognized the importance of freezing software development and

maintenance but were also aware that the demands and mandates of users would likely preclude any total freeze. They, therefore, instituted change

203
control procedures to facilitate conversion with new user enhancements

where freezir^ could not be accommodated. Moreover, their lack of

conversion experience forced them to recognize the need for contractor's

assistance. However, lack of conversion experience coupled with a non

full-time conversion manager resulted in some problem areas being

overlooked. Amor^ these were:

o Selection of conversion technique(s) still remained to be

resolved (i.e., determining the programs that lend

themselves to translation by automated tools, recoding,

or that will require a complete redesign; particularly in

view of the recent acquisition of IDMS).

o Data communications and its attendant requirements

with agency RJE stations were completely overlooked.

o Adequate training, critical to a smooth and successful

conversion, especially when converting to non codecompatible hardware, had not been planned.

o No overall top management conversion plan had been

developed. Rather, planning had been fragmented.

o No contingency planning had been developed (e.g.,

determinir^ how ttie agency would cope with losses or transfers in team and staff personnel).

204
APPENDIX E

GLOSSARY

205
Activity Distinct software conversion work that is accomplished within a phase; examples of

activities would be organizing a software

conversion team, budgeting for software

conversion.

Application Programs Programs developed for functional users; to be

differentiated from system (operating) programs.

Application System One or more applications programs which together

form an information system for an agency.

Examples are payroll, personnel, supply inventory,

equipment maintenance.

Automated Tool Software to aid in software conversion by

convertir^ some or all of the old source software

to the target software. An automated tool could

also be used in an intermediate step, e.g., converting assembly lar^uage to COBOL on a

source machine for subsequent conversion to

COBOL on a target machine.

Data File Agency information stored in a format used by

automated information systems.

Emulate Use of firmware to allow original code to run on

target hardware No functional change.

Functional User User of an automated information systems that

supports an agency operational function (e.g.,

personnel, finance).

Operation Control

Stream Lar^uage A generic term for Control Language,

e.g. IBM's Job Control Language (JCL)

Parallel Testing Parallel testing consists of operating the converted

target software in a parallel, operational mode

with source software to ensure that the old and

new systems conform functionally and that the new

source systems run in an acceptable operational

mode with other systems.

206
Phase A distinct period of time in a software conversion

project where certain activities are performed.

The completion of all activities in the phase leads

to the next phase, ag. conversion planning should

precede conversion preparation which should

precede actual conversion.

Program

Project Manager

Smallest amount of stand alone, executable code.

The full-time manager of a software conversion

project

Project Team Personnel appointed or assigned to participate in a software conversion project The project team

size and skills can change by phase, depending on

the project requirements Team members can be

assigned from agency resources or from outside resources (i.e. consultants, contractors).

Recede A translation of source code to an equivalent line

of code on the target hardware such that the

functional specifications remain the same. May be

accomplished manually or with automated tool(s).

Redesign A change in system specifications, including

different algorithms to accomplish the same

function as source code. No change to functional

specifications.

Reprogram A functional translation where some or all new

code is produced utilizing new logic where

necessary. No change to functional specifications.

Resource Utilization A measure of work units needed to process the

current workload or the source system.

Simulate Use of specialized code to allow original source code to run on target hardware. No change to functional specifications.

207
Software Conversion The transformation, without functional change, of

computer programs or data elements to permit

their use on a replacement or changed ADP

equipment, environment, teleprocessing service or system.

Software Conversion

Manager The agency staff member who, next to the

conversion project manager, has the greatest

technical interest in the status of the software

conversion project. This guide assumes that the

software conversion manager will have normal

responsibilities for day-to-day software operations

and lack sufficient additional time to manage the

software conversion project. A full-time project

manager will thus be assigned and work with the

software conversion manager during conversion.

System Software A set of programs that encompass or support the

operating system.

Task Sub-elements of work related to conversion

activities. For example, tasks related to

converting an application system could include

converting the source code, data files or job

stream lar^uage.

Test Data Data that is used to test software. Unit test data

usually is constructed to test technical aspects of

software and does not necessarily correspond to

actual data. Systems test data normally represents

operational data. Parallel test data usually is operational dataTop Management

(Top agency executives) Organizational levels of management above the

ADP level with broad authority and oversight over many or all agency operations; top management

has authority for approving buckets and allocating

resources.

Translate A change in language or version only (e.g.,

COBOL/68 to COBOL/74) No change in functional

or detail specifications. (FCSC definition).

208
No charge in function or detail specifications and no change in lar^age. (FCSC definition). Occurs

on a code-compatible conversion.

The compilation, execution and testing of each

target program with its test data. Unit test data

technically tests the software and does not

necessarily correspond to operational data.

209
NBS-n4A (REV. 2-8C) U.S. DEPT. OF COMM. BIBLIOGRAPHIC DATA

SHEET (See instructions)

1. PUBLICATION OR

REPORT NO.

NBS SP 500-105

2. Performing Organ. Report No, 3. Publication Date October 1983

4. TITLE AND SUBTITLE

Computer Science and Technology:

Guide to Software Conversion Management

5. AUTHOR(S)

CRC Systems, Inc. and Mark Skall, NBS, Editor

6. PERFORMING ORGANIZATION (If joint or other thon NBS. see /n struct/on s) 7. Contract/Grant No. CRC Systems, Inc.

riB8056BCA0495

4020 Williamsburq Court 8. Type of Report & Period Covered

Fairfax, Virginia 22032 Final

9. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street. City. State, ZIP)

National Bureau of Standards

Department of Commerce

Washington, D. C. 20234

10. SUPPLEMENTARY NOTES

Library of Congress Catalog Card Number: 83-600589

[2J Document describes a computer program; SF-185, FIPS Software Summary, is attached.

11. ABSTRACT (A 200-word or less factual summary of most significant information. If document includes a si gnificant

bi bliography or literature survey, mention it here)

This guideline was developed to provide federal ADP managers a better understanding

of the entire process of software conversion. Software conversions have life cycles

with distinct phases and activities that occur in each phase. Understanding the

order or sequence of a conversion and of the associated costs should help managers

to plan and execute software conversions efficiently, effectively, and with minimum

operations disruption to federal agencies. Although extensive references were consulted in preparing this guideline, the most important sources were interviews

conducted at 14 federal agencies that had completed or were involved in software

conversion projects. These interviews influenced the structure and organization

of this guideline in an attempt to present, in logical order, activities that must

be performed to achieve a successful conversion.

12. KEY WORDS (Six to twelve entries; alphabetical order; capitalize only proper names; and separate key words by semicolons)

conversion costs; conversion execution; conversion planning; conversion

preparation; conversion requirements; documentation; project management

13. AVAILABILITY

Unlimited

I I For Official Distribution. Do Not Release to NTIS

Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C.

20402.

Order From National Technical Information Service (NTIS), Springfield, VA. 22161

14. NO. OF

PRINTED PAGES

220

15. Price

$6.50

V USCOMM-DC 6043-P80


ANNOUNCEMENT OF NEW PUBLICATIONS ON

COMPUTER SCIENCE & TECHNOLOGY

Superintendent of Documents,

Government Printing Office,

Washington, DC 20402

Dear Sir:

Please add my name to the announcement list of new publications to be issued in the

series: National Bureau of Standards Special Publication 500-.

Name

Company

Address

City State Zip Code

(Nodilcalion key N-503)
I
NBS TECHNICAL PUBLICATIONS

PERIODICALS

JOURNAL OF RESEARCH—The Journal of Research of the National Bureau of Standards reports NBS research and develop- ment in those disciplines of the physical and engineering sciences in which the Bureau is active. These include physics, chemistry,

engineering, mathematics, and computer sciences. Papers cover a broad range of subjects, with major emphasis on measurement

methodology and the basic technology underlying standardization. Also included from time to time are survey articles on topics

closely related to the Bureau's technical and scientific programs. As a special service to subscribers each issue contains complete

citations to all recent Bureau publications in both NBS and non- NBS media. Issued six times a year. Annual subscription: domestic

$18: foreign $22.50. Single copy, $5.50 domestic; $6.90 foreign.

NONPERIODICALS

Monographs—Major contributions to the technical literature on

various subjects related to the Bureau's scientific and technical activities. Handbooks—Recommended codes of engineering and industrial practice (including safely codes) developed in cooperation with in- terested industries, professional organizations, and regulatory

bodies. Special Publications—Include proceedings of conferences sponsored by NBS. NBS annua! reports, and other special publications

appropriate to this grouping such as wall charts, pocket cards, and

bibliographies. Applied MathemaCics Series—Mathematical tables, manuals, and

studies of special interest to physicists, engineers, chemists,

biologists, mathematicians, computer programmers, and others engaged in scientific and technical work.

National Standard Reference Data Series—Provides quantitative data on the physical and chemical properties of materials, compiled from the world's literature and critically evaluated. Developed under a worldwide program coordinated by NBS under

the authority of the National Standard Data Act (Public Law

90-396).

NOTE: The principal publication outlet for the foregoing data is the Journal of Physical and Chemical Reference Data (JPCRD)

published quarterly for NBS by the American Chemical Society

(ACS) and the American institute of Physics (AIP). Subscriptions,

reprints, and supplements available from ACS, 1 155 Sixteenth St., NW, Washington, DC 20056.

Building Science Series—Disseminates technical i'' formation developed at the Bureau on building materials, components,

systems, and whole structures. The series presents research results,

test methods, and performance criteria related to the structural and

environmental functions and the durability and safety characteristics of building elements and systems.

Technical Notes—Studies or reports which are complete in themselves but restrictive in their treatmerit of a subject. Analogous to monographs but not so comprehensive in scope or definitive in treatment of the subject area. Often serve as a vehicle for final reports of work performed at NBS under the sponsorship of other government agencies.

Voluntary Product Standards—Developed under procedures

published by the Department of Commerce in Part 10, Title 15, of

the Code of Federal Regulations. The standards establish nationally recognized requirements for products, and provide all concerned interests with a basis for common understanding of the

characteristics of the products. NBS administers this program as a supplement to the activities of the private sector standardizing

organizations. Consumer Information Series—Practical information, based on NBS research and experience, covering areas of interest to the con- sumer. Easily understandable language and illustrations provide

useful background knowledge for shopping in today's technological marketplace. Order the above NBS publications from: Superintendent of Documents. Government Printing Office, Washington, DC 20402. Order the following NBS publication.i—FlPS and NBSIR s—from

the National Technical Information Service. Springfield, VA 22161.

Federal Information Processing Standards Publications (FIPS

PUB)—Publications in this series collectively constitute the Federal Information Processing Standards Register. The Register

serves as the official source of information in the Federal Govern- ment regarding standards issued by NBS pursuant to the Federal Property and Administrative Services Act of 1949 as amended.

Public Law 89-306 (79 Stat. 1127), and as implemented by Executive Order 11717(38 FR 12315, dated May II, I973)and Part6

of Title 15 CFR (Code of Federal Regulations).

NBS Interagency Reports (NBSIR)—A special series of interim or

final reports on work performed by NBS for outside sponsors

(both government and non-government). In general, initial dis- tribution is handled by the sponsor: public distribution is by the National Technical Information Service , Springfield, VA 22161,

in paper copy or microfiche form.
U.S. Department of Commerce

National Bureau of Standards

Washington, D.C. 20234

Official Business

Penalty for Private Use $300

POSTAGE AND FEES PAID

U S, DEPARTMENT OF COMMERCE

COM-215

SPECIAL FOURTH-CLASS RATE BOOK