Millions in Savings Possible in Converting Programs From One Computer to Another

Published by the Government Accountability Office on 1977-09-15.

Below is a raw (and likely hideous) rendition of the original report. (PDF)

                         DOCUMENT RESUME
03389 - [A2593734]

Millions in Savings Possible in Converting Programs from One
Computer to Another. FGMSD-77-34; B-115369. September 15, 1977.
14 PF. + 3 appendices (45 pp.).

Report to the Congress; by Elmer   . Staats, Comptroller General.
Issue Area: Automatic Data rocessing. Changeover to Other ADP
    Systems 107)
Contact: Financial and c-neral Mnagemtnt Studies Div.
Budget Function:   iscellaneoi,L. Automati Data Processing
Organization Concerned: Department of COLmerce; Department of
    Defense; General Services Admiristration; Office of
    Management and Budget.
Congressional Relevance: Coagress.
Authority: Brooks Act (P.L. 39-306).

          Frequently, computer poqrams must be converted to make
them run on a computer different fr-z  the one for which they
were originally devised. The annual Fedeial cost of such
conversions is estimated at more than $450 million; over $100
million of this coulu be saved. Findings/Conclusions: The
following factors tend to increase conversion costs: lack of
readily available software conversion expertise in the
Government; poor quality of software to be converted; inadequate
flowcharts and other explanatory data; selection of
nonstandardized equipment; and lack of programmer productivity
aids. The Navy and the General Services Administration (GSA) are
planning a Federal center for software conversion. This center
could provide the know-how that is needed in software conversion
and make it readily available to all agencies. Recommendations:
The Office of Management and Budget should assist in
establishing a Federal center for software conversion. When such
a center is established, GSA should be able to require
independent conversion estimates by the center for expensive
agency procurements which have significant conversion costs. The
center could also assist agencies in converting programs
collected by GSA's recently established Federal Software
Exchange Center. Beads of Federal agencies should emphasize
quality and standards in new software development, including
both the programs themselves and their documentation. The
National Bureau of Standards should select and publish a set of
programmer productivity aids for Government-wide use to improve
the productivity of computer programmers on both original
development of software and software conversion. (Author/SC)
3 '                        REPORT TO THE CONGRESS

                  ,-       BY THE COMPTROLLER GENERAL
 -    ."
      't( ( (It   "
                       -   OF THE UNITED STATES                             -

                           Millions In Savings Possible In
                           Converting Programs From
                           One Computer To Another

                           Office of Management and Budget
                           Nationai Bureau of Standards

                            Frequently, computer programs must be con-
                           verted to make them run on a computer dif-
                           ferent from the one for which they were origi-
                           nally devised. The annual Federal cost of such
                           conversions is estimated at more than $450
                           million. GAO estimates that over $100 mil-
                           lion of this could be saved. Further savings
                           will depend on future developments, some
                           technological in nature.

                           FGMSD-77-34                                SEPTEMBER 15, 1977
                          WASHINGTON. D.C.   20548


To the President of the Senate and the
Speaker of the House of Representatives

     This report describes (1) the problems Federal agencies
have in converting computer programs from one computer to
another, (2) the annual cost and savings possible in this
activity, and (3) how the savings can be realized.

     We made our review pursuant to the Budget and Accounting
Act, 1921 (31 U.S.C. 53), and the Accounting and Auditing Act
of 1950 (31 U.S.C. 67).

     We are sending copies of the report to the Director,
Offic? of Management and Budget; the Secretaries of Commerce
and Dfense; and the Administrator of General Services, who
are addressed specifically by our recommendations, and to
other interested parties.

                                     mptroller Gen  al
                                   of the United States
                                     COMPUTER TO ANOTHER
                                     Office of Management and Budget
                                     National Bureau of Standards

           D I G E S T

           In the early days of computers, the price of
           the equipment was the largest part of the costs.
           The programs which made the equipment operate
           cost relatively little.  Today the program.--
           software as they are called in the data pro-
           cessing community--cost considerably more than
           the equipment in most systems.

           One part of software cost that is large and not
           directly productive is called conversion cost.
           This is incurred to make programs devised for
           one computer work on another computer of a
           different make or model. Conversion costs
           should be reduced.

           If you buy a new stereo phonograph, you expect
           your present library of stereo records to play
           on it.   This is because turntable speeds and
           record grooves are the same on all makes of
           phonographs. You cannot expect such a carryover
           where computers and computer programs are con-
           cerned. There is ittle standardization in com-
           puters; even different models of the same make
           may not un each other's programs without some
           Considerable work is often necessary to make
           old programs "play" on a new computer. Admit-
           tedly, this analogy is simplistic--computers
           and phonographs differ greatly in complexity--
           but it gives an idea of the situation. The
           effort needed to make computer programs work
           on a new computer varies greatly from case to
           case but, in the aggregate, is quite large.

           No good figures are available on Federal
           conversion costs as such, but GAO estimates
           them at about $45G million a year.  GAO esti-
           mates that about 24 percent--over $100 million--
           could be avoided in today's environment.  (See
           pp. 3 and 4.)
IRL.Sht. Upon removal, the report    i
cover date should be noted hereon.
The following factors tend to increase conver-
sion costs.  (See pp. 5 to 7.)

-- Lack of readily available software conversion
   expertise in the Government.

-- Poor quality of the software to be converted,
   including unnecessary use of features peculiar
   to an old computer which do not work on the
   new one.

-- Inadequate flowcharts and other data (called
   documentation) which explain the working of
   the software to be converted.

-- Selection of new computer equipment that re-
   quires more work on conversion because equip-
   ment has not been standardized among manufac-

-- Lack of "programer productivity aids," or a
   set of tools and techniques to be used by
   programers, which could reduce the amount
   of human effort needed in conversion.

Not all of these factors are readily controll-
able, but GAO estimates that costs in the current
environment can reasonably be reduced about 24
percent with good conversion planning and prac-
tices.  Since such a reduction offers savings
estimated at over $100 million a year and be-
cause better conversions would result in prompt-
er, more effective Government services, the
work needed to bring about better conversions,
although considerable, will be worthwhile.

The Navy and the General Services Administration
are planning a Federal center for software conver-
sion.  (See app. I).  The center could provide the
know-how that is needed in software conversion and
make it readily available to all agencies.

To reduce conversion costs, GAO recommends that
(see pp. 11 and 12):

        -- The Office of Management and udget assist in
           establishing a Federal center for software
           conversion. When such a center is established,the
           General Services Administration should be able
           to require independent conversion estimates by
           the center for expensive agency procurements
           which have significant conversion costs.   The
           center could also assist agencies in converting
           programs collected by General Services Adminis-
           tration's recently established Federal Software
           Exchange Center.

        -- Heads of Federal agencies emphasize auality
           and standards in new software development,
           including both the programs themselves and
           their documentation.

        -- The National Bureau of Standards select and
           publish a set of programer productivity aids
           for Government-wide use to improve the pro-
           ductivity of computer programers on both
           original development of software and software

        Several agencies provided written comments on
        the matters discussed in this report. They
        generally agreed with GAO's conclusions and
        recommendations.  (See pp. 12 to 14.)

Yr S_
 Lhet                        iii

DIGEST                                                     i

      1    INTRODUCTION                                    1
               Roles of various agencies                   I
               Scope of review                             2

             AND COSTLY UNDERTAKING                        3
               Why a better approach to software
                 conversion is needed                     3
               Problems ir.software conversion            4
               Ways in which software conversion
                 costs can be reduced                     7

             COMMENTS                                     10
               Conclusions                                10
               Recommendations                            11
               Agency comments                            12


      I    Where computer software is now, and
             how it got there                             15

  II       Details of the separate sources of in-
             formation                                    27

 III       Agency comments                                43

ADP        automatic data processing

COBOL,     Common Business Oriented Language
DOD        Department of Defense

GAO        General Accounting Office
GSA        General Services Administration

HEW        Department of Health, Education, and Welfare
NBS        National Bureau of Standards

OMB        Office of Management and Budget
                            CHAPTER 1


     This report discusses the conversion of applications
software, including its costs, causes of problems, and
possible improvements. Applications software automates
the tasks of users--such as payroll, accounting, and statis-
tical calculations. Software conversion is the act of mak-
ing computer programs run on some computer other than the
one for which they were originally devised. The reason for
converting existing application pro,       nts, instead of witing
new ones for the  new computer,   is  that   it is usually quicker
and cheaper.   Application  programs   are   converted  when (1) a
replacement computer has   been acquired     and (2) where  it is
desired  to shire a program  that  was  written   at another  place.
Recent congressional  hearings  1/   were  concerned   with the
treatment of conversion costs n automatic data processsing
(ADP) procurement, but this report deals with conversion
matters in general, not procurement policy alternatives.

     The basic law governing Federal ADP management is the
Brooks Act, Public Law 89-306. Undrr this act, the General
Services Administration (GSA) is responsible for procuring
and maintaining Federal ADP resources. GSA receives techni-
cal advice from the Secretary of Commerce primarily through
the National Bureau of Standards (NBS) and both these agen-
cies receive fiscal and policy guidance from the Office of
Management and Budget (OMB).
     In or role of aiding the Congress, we are concerned
with the management of Federal ADP and with computer soft-
ware conversion as a frequent and expensive activity. 2/
Our past reports to the Congress have recommended im-
provements in ADP management on a Government-wide basis
and at specific agencies.

1/House Committee on Government Operations "Administration
  of Public Law 89-306, Procurement of ADP Resources by
  the Federal Government," October 1, 176.

2/For a discussion of the present state of computer
  applications programs, see app. 1.


     Our review included questionnaires to Federal
programers and supervisors 1,', interviews with experts,
and a study uf the literature.

     The questionnaires were administered to 2,005
programers and 465 supervisors of ADP functions at
43 Federal computer installations, including business
and scientific ones.  Twenty-six were Department of
Defense (OD)  installations and 17 were not.  The
purpose    the questionnaires was to obtain information
on Federal conversion problems and remedies and cost
estimating data from working level employees directly
involved in the process.

     We discussed conversion problems with recognized
software experts from both the Government and the private
sector.  We also made an extensive study of literature on
software in general and software conversion in particular.

     Our review yielded an extensive bibliography, a soft-
ware glossary, and a provisional planning checklist for
software conversion projects.  All are available on request.
For copies, write to:
     U.S. General Accounting Office
     Attn:  FGMSD-ADP
     441 G Street NW.
     Washington, D.C.   20548

1/See app. II for some detail of our sources.

                       Chapter 2

                  AND COSTLY UNDERTAKING

     Software conversion is a frequent and expensive
part of Federal ADP operations. Replacement computers
are bought and installations must convert to them. Also,
programs that are shared must be modified before
they will work on the receiving installations' systems.
Each situation requires a conversion effort which can
range from trivial to enormous.

     To assess the importance of software conversion, we
asked about its frequency both in our questionnaires and
our discussions with experts. We found that conversion to
replacement systems is very common in Federal agencies,
although at any one installation 7 years is the average
time between computer system replacements. Federal organi-
zations contacted during this review cited conversion
problems as a major concern. On our questionnaires, over
three-fourths of the supervisors and over two-thirds of
the programers indicated that they had worked on at least
one conversion to a replacement system, while one-half
of the supervisors and one-third of the programers
indicated that they had been involved in at least one
conversion of a program brought in from another instal-

     The Federal cost of software conveLsion for all
ADP categories is estimated to be over $450 million
annually. Its potential for reduction in today's
environment is estimated to be over $100 million annually.
This saving is available sol2ly from doing the samne
jobs better in the current environment. Other alternatives,
such as buying or sharing software, also have a great
potential for more software cost avoidance, but such
savings cannot now be quantified.

     We know of no good figures available on what the
conversion of computer programs costs the Government
each year or how much of it could be saved by better
conversion techniques.  Consequently, we could not make
a precise determination of what either the costs or
the potential savings might be. Recognizing, however,

that estimates are often useful in judging whether propo-
sals are worthwhile, we made the best estimates we could
of costs and potential annual savings.  Admittedly, they
are based on many approximations, but we believe they are
reasonable, and they are supported by several consultants'
estimates of conversion costs which were about the same
as ours.

     In making our estimate, we determined that the Federal
Government spends about $6 billion a year on software for
all types of ADP and that about half of this, or $3   bil-
lion, is spent for maintaining and converting computer
programs after the software is acquired.  We estimated
that conversion costs to replacement systems are one-
seventh of the $3 billion, or over $425 million, using
7 years as the typical life of a hardware system and
1 ear as the typical time it takes to completely convert
an installation.  Aother $25 million was estimated for
converting programs acquired elsewhere (foreign pro-
grams) for use on installation computers.  The $25 mil-
lion estimate is based upon programers' estimates of the
percentage of their  ime they spend on converting foreign
programs, the number of programer and systems analyst
staff-years reported to GSA, and the estimated average
cost of a software staff-year.  Thus, a total of over
$450 million is arrived at for converting computer pro-

     To get an idea of how much of this amount could be
sa-ed by better techniques, we obtained estimates from
programers and their supervisors through our auestionnaire
and, separately, from experts wa contacted in the fields
of computer program development and  oftware conversion.
The programers and their supervisors estimated that over
40 percent could be saved, while the experts' estimates
averaged about 24 percent. We believe the experts, with
their broader experience in the complexities of overall
design and conversion work, have a better total perspective
of the problem, and their more conservative estimate is
probably more realistic. Using the experts' percentage,
we estimated the potential savings in conversion costs in
the current environment as over $100 n.illion. Our suqges-
tions for achieving these savings are discussed later in
this chapter.


General costs

     Software conversion costs are incurred in several ways,
including delays in user tasks, labor, retraining, inter-

ference, morale, and documentation. Each is discussed
briefly below.

     -- Delay in automating user tasks. This cost of
        th conversion process isfT   icult to estimate but
        may be the most important in some cases. If a
        conversion project is late, the user does not
        get the task(s) automated at the expected time.  Hence,
        the adverse impact on the user's work or his clients
        may be great.

     -- Prpramer and analyst labor. This is the maior direct
        cost of conversion.  We estimated that a typical staff-
        year of this type, with overhead and computer support,
        cost $33,000 in fiscal year 1976.
     --Retraining. This cost, which will be reater
       wFen the conversion is to a replacement system of a
       different vendor, includes retraining of system
       programers, computer operations staff, applications
       programers, users, and management. The retraining
       needed i, the case of converting a program from
       another installation depends entirely upon
       specifics of te situation, including the uality
       and size of th- program being converted, the degree
       of communication between originator and recipient,
       and the knowledge and motivation of the responsible
       programers at the receiving installation.

     -- Interference with other uses of the computer. A lengthy
        conver sion-efort may serousl-'yinterfere with other
        work that is scheduled :tobe done on the computer
        at the same time. On the other hand, the conversior
        could suffer if other work has priority.
     -- Employee morale. Employee morale may suffer durinq
        a conversion, especially if (a) there are indications
        of poor planning or (b) prolonged overtime is involved.

    -- Chaging documentation.   This cost is very
       situation dependent. If original documentation is
       good and kept in a machine-readable form, it will be
       easier to change, but if documentation is poor, signi-
       ficant time and effort could be required to change it.
Software conversion problems
 identified in our review

    -- Lack of readily available software conversion
      expert'se.   Both t       -
                                      …     respondents

  and the experts identified the lack of Federal
  software conversion experts and knowledge as
  the most important causes of problems in con-
  verting programs from other installations and
  significant causes of problems with conversions
  to replacement systems. Experts cited the fact
  that the typical installation which performs a
  conversion with its own staff is using people
  who very rarely do conversions since computers
  are generally replaced only every 5 to 10 years.
  The experts said that conversion would be better
  done by specialists.  A Federal conversion center
  was often suggested as a solution.
-- Poor ouality of the software to be converted
   to replacement systems and of its documenta-
   tilon. Since programs are usua-ly converted by
   persons other than their authors, either aspect
   of quality can vastly complicate the conversion.
   Poor quality of existing software has resulted
   from management failures to require excellence in
   software development and documentation, and to
   consider eventual conversion in the development
   of new software. Poor quality of the software
   includes code that is needlessly complex and
   difficult to understand and that uses unneces-
   sary computer resources. Failure to consider
   eventual conversion results in programers being
   allowed to unnecessarily use features of the cur-
   rent computer's programing languages that will
   not work on another make.
-- Lack of standardization among manufacturers.
   Manufacturers typicalTy offer ADP systems and
   programing lnguages with features which are
   unique to their equipment. In the past, pro-
   gramers have been frequently allowed to, and
   have sometimes needed to, use such features.
   Thus, an installation's software inventory
   typically includes programs using such unique
   features, which do not conform to standards.
   If the replacement system is made by a different
   vendor, the unique features of the original vendor
   usually will not work on the replacement system,
   and partial reprograming is necessary to make
   them work. Better adherence to standards in
   software development to reduce the use of vendor-
   unique features would reduce this problem.

     -- Lack of staff conversion experience, knowledge,
        or interest. Ths pro-em results because a
        given installation very seldom experiences
        conversion to a new system.  (A 7-year system
        life is often cited.) Thus, due to normal turn-
        over, many of the employees who worked on a
        prior conversion may not be there for the next
        one. Also, people who are very skilled on one
        manufacturer's systems may know nothing of an-
        other's. Another staffing problem is that many
        programers and analysts are not interested in
        conversion. They perceive developing new soft-
        ware as more challenging and creative than con-

     -- Lack of programer productivity aids.  Programer
        productivity aids can automate much of the
        drudgery of both writing original programs
        and conversion, Some can even provide partial
        translation from one manufacturer's programing
        language to that of another. If these aids
        are not present and used, programers must
        do much more by hard.
     The roblems identified for conversion of programs
from other installations were basically similar to those
identified for conversion to replacement systems. They
included poor quality of the material to be converted and
the conversion staff's lack of knowledge. However, there
was the added problem of programs from other installations
not being adequately studied before the decision was made
to bring them in to see if they matched the needs of the
recipient. In these cases, there was not only a conver-
sion effort but also a modification effort much larger
than if more suitable programs had been chosen. This prob-
lem indicates that careful study is needed before the deci-
sion is made to share programs from other installations.


     There are several ways to improve software conversion
which apply generally to both types of conversion.

     It would be helpful, for agencies anticipating a
conversion project, to be able to turn to recognized
impartial experts who could aid them in avoiding the com-
mon pitfalls. We believe that significant savings would
result if a center of expertise were available to such
agencies to assist with conversions. The expert assistance

would include impartial evaluation of conversion aspects of
procurements, selection of contractors to perform conver-
sions, project management of the teams actually doing the
conversions (either agency or contractor), and transfer
of lessons learned from one conversion to another and from
one agency to another. Such a center could also actually
do conversions--requiring a larger staff than if conversions
were not done by the center--and assist agencies that want
to share software from the Federal Software Exchange Center.
     The Navy and GSA are now developing a cooperative
agreement to establish such a center. We believe that such
action would be a step in the right direction.
      More emphasis on quality in the original development
of software and documentation would ease eventual conversion
problems. Means of attaining better uality include better
enforcement of documentatior. and other standards, adoption
of the new software technologies 1/, better training for
programers and systems analysts, and adoption of productivity

     The possible greater cost of higher quality software
development would be more than offset by (1) easier and
cheaper future conversion and modification of the software,
(2) fewer errors in the supported user tasks, and (3) more
feasibility of sharing the software by multiple users.
Also, the productivity improvements available from the new
programing technologies and cooperative efforts to develop
software for groups of users indicate that higher quality
software need not necessarily cost more, and may in fact
be cheaper, than the old method.
     More widespread use of automated programer product-
ivity aids would also ease software conversion and origi-
nal software development problems. These aids, which are
already sold in the marketplace, include translation pro-
grams which automate part of the translation process,
text editors, which ease the "manual revision" part of
conversion, and programs which can scan another program
and print a flowchart for it.

1/See app. I, pp. 21 and 22.

     Conversion costs can also be reduced by management
recognition that most production programs will eventually
be converted to newer equipment. Therefore, it is prudent to
make every effort to avoid the use of vendor-unique features
present in programing languages. Such avoidance will aid
in reducing the conversion costs involved in new equipment
procurement, and facilitate maximum competition.

                          CHAPTER 3

     Software is the most costly element of modern ADP
systems. It is both the ighest single cost of devel-
oping an automates system and the system component with
the most potential for adverse impact on the user tasks
it supports. Malfunctions in these tasks have a potential
for cost impact greater than the cost of developing the

     The conversion of software to replacement hardware
systems is a recurring, frequent, and costly activity
in the Federal Government. Program conversions among
installations are now much less frequent, but greater
sharing of software would increase them. Reduction of
the time and effort needed for this type of conversion
would encourage software sharing.

     More effort devoted today to developing better
quality software and documentation would ease eventual
conversion problems. Means of attaining better quality
include better enforcement of standards (for programing
languages, programing practices, and documentation),
adoption of the new programing technologies, better train-
ing for programers and systems analysts, and adoption of
productivity aids.

     The greater cost of developing higher quality soft-
ware would be offset by (1) easier and cheaper future
conversion of the software, (2) fewer errors in the sup-
ported user tasks, and (3) the increased feasibility
of sharing the software by multiple users. Also, the
savings from cooperative efforts to develop software
for groups of users, and the productivity improvements
possible with new programing technologies, mean that
developing better software need not necessarily cost
more chan the old methods.

     More widespread use of programer productivity
aids would also ease both software conversion and ori-
ginal software development problems. These aids in-
clude automatic translation programs and programs
which automatically scan another program and print
a flowchart for it.

     Management, anticipating eventual conversion, can
direct that vendor-unique features be avoided where poss-
ible 1/ in developing new applications for existing equip-
ment. By avoiding such use, eventual conversion to replace-
ment equipment of other manufacturers will be eased.

     We estimate that in today's environment $100 million
can be saved annually thrcugh the use of techniques and
activities cited above. We believe that achievement of
these savings could be facilitated through establishing a
Federal center for software conversion which would provide
a pool of expertise for agency assistance.

     In the long run, even more savings in the software area
may be attained as a result of other actions, especially
standardization of more high-level languages and further im-
provements in programing and documentation techniques. We
plan to monitor these developments and report on them as

     We recommend that OMB assist in establishing a center
of Federal expertise for software conversion. The services
provided by this center should include impartial estimates
of the conversion implications of system procurement alter-
natives, contracting for software conversion, some capability
to actually perform conversions, and a mechanism for transfer
of lessons learned to future software conversions, develop-
ments, and procurements. GSA should be able to require in-
dependent conversion estimates by the center for expensive
agency procurements which have significant conversion costs.

1/In cases where vendor-unique features must be used, we
  believe that management should require (1) that such use
  be justified by savings in operating costs, (2) that the
  justification be documented, and (3) that the use of
  the unique features be isolated into separable parts
  of the program (called modules).

     We also recommend that the heads of Federal agencies
emphasize quality in software development, promote stand-
ards more vigorously, and require both their in-house staff
and their contractors to observe standards.  Standards to
be promoted include programing languages, documentation,
and programing practices.  The guidelines recently published
by NBS (FIPS PUB 38) 1/ offer a reference for documentation.
Programing practices standards should include restriction of
the use of vendor-unique features in software development. 2/

     We recommend that NBS select and publish a standard
set of programing productivity aids for Government-wide
use.  These aids would ease both the original development
of software and its later maintenance and conversion.
Here, "standard set" means standard in the sense that
each aid's features and uses would appear the same to
programers no matter which make of computer it was in-
stalled on.


     We asked HEW, DOD, CommeLce (NBS), OMB, and USA
to comment on our preliminary report.    Their replies,
which indicated  general  agreement, are shown in ap-
pendix III and  discussed  below.

     The Inspector General, HEW, said that he had no
substantive comments.

     The Deputy Assistant Secretary of Defense (Comp-
troller) said that he ajreed that sufficient benefit would
accrue to make implementing our recommendations worth-
while, even though he was "less optimistic about the po-
tential for hard dollar savings" than we are.

1/Federal information processing standards publication 38.

2/Another possible means of restricting the use of
  vendor-unique features is that of requiring vendors
  to sell the Government programing language compilers
  which include only the standard lanquaqe (no special
  features unique to the vendor).  This would force
  programers to avoid special features by removing them

     The Assistant Secretary for Administration, Commerce,
concurred with our three recommendations. She stated that
NBS recognizes the need for greater use of productivity aids
and will work in this area as priorities dictate and re-
sources allow.

     The Associate Director for Administrative Management,
OMB, commended the report and agreed to support the establish-
ment of a conversion center. He raised the question of whether
or not the center should be the only source of conversion ser-
vices Fderal agencies would be allowed to use. He suggested
that agencies be allowed to use other sources as a way of sub-
jecting the proposed center to competitive pressure.  He also
indicated that he feels the Federal Computer Performance Eval-
uation and Simulation Center is an example of how to arrange
the conversion center.

     In general, we agree that an arrangement like the above
center has (i.e., agencies voluntarily requesting assistance)
is appropriate for the conversion center. However, we be-
lieve GSA should be able to require an independent estimate
by the conversion center for expensive agency procurements in
which conversion is a significant component of the total cost.
We modified the report to clarify this matter.

     The Administrator of GSA supported our conclusions and
recommendations, but said that we should have discussed con-
version in terms of the broader problem of management plan-
ning for future needs. We also realize that conversion oc-
curs in a broader context of related matters, but feel that
our report covers a subject which warrants attention and ac-
tion. He said that while adoption of our recommendations would
be beneficial, it would not substitute for good ADP installa-
tion management. We agree.

     The Administrator discussed some software conversion
problems, including mixes of agency-developed and contractor-
developed software, and "efficient nonstandard programs."
We realize that many Federal ADP installations have software
developed by outside sources as well as by their own pro-
gramers. We realize also that data base management systems
are written in assembly languages (nonstandard) in the cur-
rent state of the art and would not normally be converted.

     Concerning the use of uniaue features of programing lan-
guages--which we advise against--the Administrator said that
these features often provide advantages over the near term.
We do mention that they must sometimes be used. However. the
experts we consulted during our review felt that the near-
term advantages of unique programing features are often

overrated and contribute unnecessarily to increased long-term
costs without really reducing short-term costs.

     The Administrator disagreed with our suggestions to use
industry-provided application software, saying that its lower-
ing costs and speeding implementation are the exception, not
the rule. During our review, we found that many users of pur-
chased software are satisfied and intend to buy more. Also,
user groups--including those of the International Business
Machines Corporation and the Control Data Corporation--repeat-
edly discuss purchased software as a viable and commonly used
alternative to software written by the organization's own pro-
gramers.  It is true that such software . 'st often be modified,
but modification can be much cheaper thai. writing complete new

     The Administrator said that it would have been helpful
if we had more fully discussed the involvement of programing
language standards with conversion.  We are aware of the im-
portant effect of standards (or lack of them) on conversion.
We agree that better standards, together with compliance
mechanisms, would greatly reduce the problem. We are now
studying the Federal Information Processing Standards Program
and will report our results to the Congress.

APPENDIX I                                        APPENDIX I


     In 1951, the Census Bureau installed the first
business type computer in the ederal Government. The
computer itself was expensive, large, and delicate.
Its programing was done in machine language by a problem
solver untrained in programing. The cost of this soft-
ware was small compared to the cost of the hardware it

     From that beginning, software hs evolved until it is
now generally the most costly single part of an ADP system;
programing is recognized as a separate occupation which can
be taught and managed; and there exists a very large invest-
ment in programs running on current computers, many of which
will eventually be converted to run on other computers.

     Several characteristics and issues in the software
area were identified repeatedly in the literature and by


     An industry grout concerned with the future of ADP
recently predicted that bv 1985 software will be about
90 percent of the total cost of a computer system. Also
a recent GAO report, "Improvements Needed in Managing
Automated Decisionmaking by Computers Throughout the
Federal Government" (FGMSD-76-5, April 23, 1976), found
that "software problems" are a major cause of expensive
malfunctions of automated systems.

     Many administrative applications are automated in
virtually every agency of the Government, and it is
applications softwa:e that drives this automation.
The Federal Government alone spends about $6 billion a
year on computer software and now has large inventories
of computer programs, many of which will eventually be
converted to run on another computer system. This annual
cost includes software conversion projects which are
frequently expensive. For example, a single Navy con-
version project reported approximately

    -- 100 staff-years of effort,

    -- a total direct labor cost of about
       $1.2 million, and

    -- conversion of 400 applications programs over
       a 12-month period.

APPENDIX I                                                 APPENDIX I

     Software conversion costs and difficulties are fac-
tors in many procurements of new computer systems.  The
difficulty of conversion is often cited as a reason to
buy a replacement computer from the same vendor.


     Two causes have made software a relatively larger
part of ADP systems costs:  one is increasing complexity
and quantity of software functions demanded by users
and the other is decreasing hardware cost.

          The first is due to the increased use of computers
by laymen who want convenient automation which is tailor-
ed to (1) their problem at hand and (2) their conven-
ience--not the convenience of the machine or its           pro-
gramers.       The  ew user-oriented     applications  are very
different      from older clerical    applications,   such as
payroll,      which were the original      uses of business auto-
mation.       Programs which provide user convenience are
more complex, and since users demand convenience, the
programers' work is becoming more complex.

     Besides more complex software, there is simply a de-
mand for more software; there are more computers, and
they all need software to make them run.  With less ex-
pensive computers, more organizations find more automation
attractive, and again more software is needed.  The growth
in use of computers is shown by the following table.

                              1965          1970        1975

U.S. Government               2,412         5,277        8,649
Nationwide                   23,000        70,000      175,000

                                     Programers emp1oyed

Nationwide                   80,000       175,000      215,000

     The steady decline in the cost of pocket calculators
illustrates the second cause (cheaper hardware).  The cal-
culators use technology similar to that of computers,
which are also going through similar decreases in cost per
task done.  The decreasing cost of electronic computing
hardware makes software a proportionately larger part
of the total costs of ADP systems.

APPENDIX I                                        APPENDIX I

Software development

      The life cycle of a unit of computer software is
   tided into development time and operational time.
Development time ends when the software is in production
automation of the user's task. Traditionally, a software
Development project has had these characteristics:

     -- It cost more than was expected and ran late.
        Adding more people to late projects often
        did not restore them to schedule.

     -- The first production version delivered was
        really a prototype in conventional engineering
        terms. Besides the software itself being a
        prototype, its documentation was often sketchy
        or missing.

     -- Because a prototype was delivered, the postdevel-
        opment costs of fixing and modifying hare typi-
        cally been as great as the development cost and
        sometimes far greater.

     Several factors contributed to the situation. First,
the invisible nature of both the work process and its
product made software projects very difficull to manage
and predict. Second, the explosive growth of the use
of computers created a great demand for programers which,
in turn, demanded the use of many new programers, most
of whom learned on the job. Frequently, low productivity
and poor quality of product resulted. Third. there
was little idea then of how to train programers properly.
Many were largely self-taught. Fourth, a tradition grew
of programers as secretive craftspersons whose product3
during development, were their own property. Fifth, little
attention was given to reducing some of the clerical tasks
of programing. Programers' productivity was low because
much of their time was occupied with such things a key-
punching and running errands rather than programing.

Software operation

     The operational part of the life cycle lasts from
the beginning of production with the first version to
the time that the software is replaced] or discarded.

APPENDIX I                                          APPENDIX I

During this period, costs other than normal processing
ones may be incurred to correct errors in the software,
to modify it to add new functions, or to convert it to
run on another computer. They are all postdevelopment

     Corrections of errors and modifications are commonly
combined under the term "maintenance." The percent of
programer time spent on maintaining software developed
in the traditional way has been estimated from 20 percent
to 80 percent.

     Software conversion costs are those special post-
development costs which are incurred to make the software
run on some other computer than the one for which it was
written. They include delays in users' tasks, retrain-
ing, programing labor, interference with other uses of
the computer, documentation revision, and possibly lowered
employee morale.

     We feel that 50 percent of total software costs is a
representative value for all postdevelopment software
costs, including conversion.

     Federal investments in ADP to date include:

    -- Computer equipment.  The table on page 16
       shows the large number of computers now in
       place. GSA's reported fiscal year 1975 Federal
       ADP inventory shows almost $3 billion in owned
       hardware and over $1 billion in leased hardware.
       these computers, and theiz software, range from
       early to recent models.
    -- Pr'rams. There are now large numbers of com-
          . r'application programs in Federal agencies.
       -remendous effort has been spent on developing
       these programs; documenting, maintaining, and
       modifying them; and training operators and
       users. While the total investment cannot be
       estimated with any accuracy, its magnitude is
       indicated by the inventory of programs at the
      National Institutes of Health Computer Center
       in Bethesda, Maryland. At a recent meeting,
      NIH representatives indicated that this single
       installation has about 40,000 programs, with
      an estimated 10 million lines of code.

APPENDIX I                                        APPENDIX I

       Using an original development cost of $8 per line
       of code would yield a software development cost
       over the years of about $80 million for just this
       one installation. While this figure is only an
       estimate, the inventory certainly represents a
       large expenditure.

     --Training. GSA reported that 33,694 Federal staff-
       years were spent on systems analysis and programing
       in fiscal year 1975. The cost of training that number
       of persons in the current methods of developing soft-
       ware, programing languages, and knowledge of pecific
       programs is difficult to estimate but is certainly
       very large.

      In the early days of computers, almost all appli-
cations software was developed by programmers who were
employed by organizations operating the computers. Now,
a separate industry produces applications software to

     At a recent industry conference, the publisher of
a software journal pointed out that total software in-
dustry sales have grown from $4.5 million in 1970 to
$750 million in 1975, that there are now 400 firms that
sell software, and that about 3,500 different software
packages are offered by these firms; of these, 2,200
are application oriented. A strong point in favor of
using software that is already developed is that it is
much less expensive to convert it to the new user's
computer, if that is necessary, than to develop similar
software anew. In some cases, new development can cost
10 times as many dollars and take 10 times as long.
Many common tasks have been automated with programs gen-
eralized so as to be useful to many organizations.

     This software industry is an alternative to Govern-
ment agencies' producing their own applications software;
use of this alternative could lower costs and speed im-
plementation dates.

     Historically, projects to develop original software
as well as conversion projects have been completed later
than scheduled or at a higher cost than predicted, or
both. Many causes contribute to this situation--some

APPENDIX I                                        APPEND"' I

managerial, some sociological, and some technical, as
discussed below.

     The software field is still relatively new and
lacks accurate means both in measuring its product-
ivity and predicting its production. Workers who
produce software practice an ill-defined and diffi-
cult-to-quantify craft. They are commonly con-
sidered to be in demand and difficult to retain and
to manage effectively. Customers (end users) for
whom the software is created often do not have a good
definition of the process or function that they want
automated. Changes requested after projects have
started, which seem trivial to the customers, have often
caused major rework efforts with consequent delays and
increased costs.


     The experts and literature that we consulted indi-
cated that many computer programers view themselves as
craftsmen, with strong feelings of "I'd rather do it
myself." This attitude was echoed by the programers
who responded to our questionnaire. Traditionally,
the programers' attitude was indulged because they were
scarce.   There is a feeling that if a program written
elsewhere is brought into an installation then the local
people must not be competent. This feeling has fre-
quently caused installations to duplicate programing
that had already been done elsewhere.

     Programs are often designed and written hastily
to meet deadlines and tested and documented inadeauate-
lv or not at all. Thus, quality is sacrificed for ur-
gency. Programs have been typically devised to run on
one specific computer for the local task(s) of its
owners.  Little or no consideration is given to the prob-
able eventual conversion of the programs.

      Eaca manufacturer supplies aids to programers which
 include features peculiar to that manufacturer's equip-
 ment. When programs written with these tools are to be
 converted to another manufacturer's equipment, these
 peculiarities must be replaced because they no longer
 work. This causes problems and increases costs.

APPENDIX I                                        APPENDIX I

      Federal ADP procurement methods, intended to insure
competition among prospective hardware suppliers, make it
very possible that an installation's replacement computer
will be purchased from a different manufacturer than the
one the present computer was purchased from. For a vari-
ety of reasons, it is more difficult to convert programs
running on one make of equipment to another make than to
convert them to a later model of the same make. Finally,
mechanisms for transfer of technical knowledge about
conversions from one Federal agency to another are primi-

     Another problem with both technical and sociolo-
gical aspects is documentation, which is material pre-
pared to explain a computer program. Documentation
is human-readable material over and above the actual
code which drives the computer. Since the programer
usually has a requirement to make the program work as
soon as possible, documentation is often deferred until
after the program is running. Once a given program is
running, a new programing task may cause the work of
documenting the first program to be shunted aside. Also,
programers tend to shirk documentation, because it is
less creative than actual programing. When that first
program is later modified or converted, the work is usu-
ally done by someone other than the originator. When
documentation is missing, incomplete, or obsolete, the
program conversion effort often must duplicate a great
deal of the original development work.

     The recognition of a software crisis in the mid-1960s
caused considerable attention to the need for improving
both the management and the technology of computer software.
Several organizations undertook projects to devise better

     Their efforts have produced a group of software
innovations, collectively referred to as the new software
technologies, which include the following concepts:

    -- Software engineering:  the idea that an
       engineering approach can be used in devel-
       oping software, as it has been in developing
       hardware.  Software engineering includes many
       methods for the controlled design and devel-
       opment of high-quality software, including

APPENDIX I                                            APPENDIX I

       both management approaches, such as chief
       programer teams, and technical approaches,
       such as structured programing.

     -- Chief programer team: a small team consisting,
        as a minimum, of a very superior programer as
        a leader, a backup programer, and a programing
        librarian or programing secretary. The team
        is supported by an automated facility called
        a development support library.
     -- Structured programing:   a way of arranging
        the actual code of computer programs (by
        their authors) so that they will b more
        easily understood by others who must later
        maintain and modify them.
     -- Development support library: an automated
        facility which is used to maintain software
        development files, including programs, data,
        and documentation. The library is maintained,
        according to a standard set of procedures, by
        a trained person who is sometimes called a
        programing librarian or programing secretary.

A number of organizations have reported significant
improvements in terms of productivity, ease of main-
tenance, and reduced errors in software development by
adopting these techniques.


     There have been a number of efforts to standardize
facets of ADP, including software. A unique effort was
the adoption of the American National Standards Insti-
tute 1968 standard for the Common Business Oriented
Language (COBOL) as a Federal Information Processing
Standard. As of late 1977, COBOL is the only programing
language for which a Federal standard exists. Attempts
to comply with this standard have reduced the uifferences
between different vendors' versions of COBOL. Meanwhile,
technology has advanced. A 1974 COBOL standard has been
adopted which is considerably different from the 1968 ver-
sion. Some existing COBOL programs require modification
before they will work with the 1974 version of COBOL.
This modification is also a type of conversion.

APPENDIX I                                        APPENDIX I


     The vested interests of users, data processing
entities, standards groups, and management hierarchies
are other factors in the software area. Organizations
have adopted ADP, with its attendant investment in goods
and people, as a part of their structures and a component
of their budgets. Other organizations have been estab-
lished to regulate the users. Both the adoption and the
establishment were long, slow processes, and considerable
inertia may now exist against sweeping changes.


     Some efforts currently address software conversion on
a Government-wide basis. They include work by GSA, the
Navy, the Air Force, and the House Committee on Govern-
ment Operations. Each is discussed below.

     In October 1975, GSA received a contractor's study en-
titled "Feasibility Study For Development of a Program Toward
Competitive Procurement of Higher-Order ADPE." The relevant
findings are paraphrased below:

     -- The movement of a particular ADP system workload to
        another ADP system (conversion) appears to be the
        major impediment to i   ring full and open competi-
        tion in a procurement to replace or upgrade ADP be-
        cause of its costs. The cost of conversion is con-
        trolled by a number of factors, including inadequate
        or improper documentation, personnel not available
        to complete or correct documentation, programs writ-
        ten for specific hardware characteristics, programs
        not written in higher level language 1/, and pro-
        grams in higher level language using nonstandard or
        machine-dependent programing techniques.

     --While there is basic agreement 3mong ADP vendors and
       users alike that conversion problems are the main
       stumbling block to competition, there is little

l/Higher level languages provide a programed with a more con-
  venient means of writing a program which is then trans-
  lated automatically into a code that the machine can follow

APPENDIX I                                            APPENDIX I

      information available on the subject. Conversion
      experience is either not transferable or closely
      held. Hardware vendors do have considerable
      documentation and experience in conversion but tend
      to treat it as proprietary.

     -- Effective management is the kev to minimizing con-
        version costs. Since system life is in the range
        of 5 to 10 years, it is imperative that ADP manage-
        ment plan for system replacement.

     -- The first basic management tool to be implemented
        should be effective program library controls and
        reporting procedures. Any replacement upgrade rec-
        ommendation logically must be preceded by a study
        which determines that higher capability is needed.
        Such a study must include, as key elements, the
        condition, and efficiency on existing equipment,
        of the application programs. Proper program li-
        brary procedures would contribute significantly to
        the study by supporting statements about the number
        of programs to be converted, locating similar con-
        verted programs in other libraries, and showing
        whether or not programing standards are followed.

     -- The next management tool that should be implement-
        ed is a standard for machine-indepenuent program-
        ing [languages] and systems design to prevent
        equipment lock-in to single vendors.   Both his-
        tory and the  anticipation of the future indicate
        that machine-independent software is cheaper in
        the long run.

     -- A third management tool is the elimination of
        interim ADP equipment upgrades. These indicate
        failures of ADP management.      Private-sector ser-
        vices   could be used  for  workload that exceeds
        the   present system  while  a replacement is
        OcL ight.

     -- A fourth tool is the charging of conversion costs
        to ADP operations instead of to the procurement
        process. ADP management is responsible for the
        status of the software, and the status of that
        software, including adeauate documentation and
        higher level language, affects operations today
        as well as in the future. Charging conversion
        costs to procurement hides ADP management pro-
        blems and virtually eliminates competitive pro-

APPENDIX I                                           APPENDIX I

      curements. [GAO comment: This viewpoint is
      in opposition to many ADP managers, who claim
      that conversion cost should be considered part
      of the cost of each procurement alternative.]

     The Information Systems Division, Office of the
Chief of Naval Operations, studied the costs reauired to
convert its installations' operations into regional data
processing service centers. The size of this effort
(13,000 programs totaling about 8 million lines of code
and associated files) and the presence of software con-
version as a recurring Navy problem led to a feasibility
study of a centralized conversion team in the Navy. The
report, entitled "Feasibility and Desirability of Estab-
lishing a Centralized Conversion Team Within the Navy,"
recommended that a centralized Navy conversion staff be
established. It was to provide Navy installations

     -- workload analysis and planning,

     -- general consulting,
     -- training in conversion techniques,
     -- "hands on" conversion performance, and

     -- contractor selection and contract manage-
         ment for conversions done by contractors.

The study group was unable to ,quantify the savings that a
centralized staff would effect but stated that they were
certain that savings in money and staff time would result.
     At GSA's request the Navy's Federal COBOL Compiler
Testing Service 1/ did a "Feasibility Study of a Federal
Data Processing Service Center for Computer Systems Conver-
sion Support" which suggested a Federal entity for software
conversion to provide two categories of service to client
agencies--analysis and solicitation. A cooperative venture
with GSA was suggested similar to, but separate from, the
Federal COBOL Compiler Testing Service.

1/The Federal COBOL Compiler Testing Service tests vendors'
  versions of COBOL to see if they comply with the Federal

APPENDIX I                                           APPENDIX I

     In December 1976, GSA representatives indicated that
an Interagency Agreement and Federal Property Management
Regulation were planned.

     The U.S AeL   :orce made a study of software conver-
sion for its fiscal year 1976 Worldwide ADP Single Man-
agers' Conference. The study, entitled "ADP Con-
version Cost," recommended that:

     -- Conversion costs which can be clearly and
        fully satisfied and documented be included
        in the overall costs that are to be con-
        sidered in the selection of equipment ac-
        cording to GSA's Federal Management Cir-
        cular 74-5.

     --Air Force Regulation 300-2, paragraph 4g, be
       clarified by the addition of the words "and
       conversion" to read: "Total life cycle costs
       (not to exceed 8 years), including costs of
       acquisition and conversion, must be considered
       in determining whether the procurement should be
       sole-source or competitive."   [GAO comment: This
       conflicts with the finding of the GSA contractor
       study cited above.]
     -- Conversion cost tracking be added to Air Force ADP
        Project management to accumulate data to improve future
        conversion estimates.

    -- The question of software system redesign be separated
       from that of software conversion.

     In June and July 1976, the House Committee on
Government Operations, headed by Congressman Jack Brooks,
held hearings on Federal ADP operations. On October 1,
1976, the Committee issued a report entitled "Adminis-
tration of Public Law 89-306, Procurement of ADP Re-
sources by the Federal Government."

     The hearings and the report surfaced conversion to
replacement systems as a major concern in the management
of Federal ADP.

APPENDIX II                                     APPENDIX II


      This appendix presents details from our sources of
information--experts and literature, and the question-
naire data collection. While our sources substantially
agreed about causes of problems and remedies, and these
are shown in the text, there were minor differences of
detail and emphasis. These slight differences reflected
the different perspectives and orientations of the sources.
Substantial agreement emerged on the major points, however.

Causes of problems
     Experts and literature identified the following as
major causes of software conversion problems:

    -- Lack of readily available software conversion
       expertise. Such expertise-is neeaea-and concepts
       of it ranged from that of consulting, which would
       estimate conversion costs to guide procurements,
       to that of an entity which would actually perform
       conversions for agencies. A contractor-operated
       entity to perform conversions was also suggested.
    -- Poor planning of conversions. Unreasonable
       demands of users and failures of programing
       management to estimate resources correctly, to
       schedule realistically, and to assign trained
       people to conversion projects were all cited as
       consequences of pcgr planning. Another plan-
       ning difficulty cited was that of allowing
       conversions to be complicated by demands for
       modifications to the software being converted.

    -- Procurement policy. Several experts criticized
       the Federa1low-b'1d hardware procurement policy,
       saying that ignoring conversion aspects of a
       procurement decision heavily penalizes organiza-
       tions that must convert their applications to
       another manufacturer's computer.  (Our comment:
       We believe that, if software development antici-
       pated eventual conversion and took measures such
       as sharply reducing the use of vendor-unique

                                                   APPENDIX II

       features by programers, this problem would be
       much less important.)

     -- Vendor-unique features.   These features are plen-
        ifuiln older appications software.       They are
                                 of standardization   among
        there because of a lack
                                             features  of
        vendors. and include vendor-unique
        programing languages (called  extensions),  depend-
        ence on unique hardware, etc., and were used to
        make original development easier or to make pro-
        grams use fewer computer resources.    Modifying
        a program that contains vendor dependencies to
        remove them may be easy or it may be so dif-
         ficult that writing a completely new program is
        easier than converting the old one.    However,
         the original writing of the program  can often
         be planned to avoid such dependencies.

     -- Poor   uality of the material to be converted.
       This category Incu-ed poor quaTity of T(i7he
       computer programs themselves and (2) their
       documentation.  Poor quality of the programs
       can include errors and omissions, inefficiency,
       and incomprehensibility to anyone but the
       author.  Poor quality of documentation may
       mean that it (1) does not exist, (2) is incom-
       plete, or (3) is obsolete.     (Obsolete docu-
       mentation means that  changes   to the documentation
       have not kept up with  changes   to the software.)
       Perhaps the worst case  is  that  of a currently
       dated documentation that   was  not  brought up to
       date before it was reprinted.     It  looks current,
       but it is not.

      -- Absence of productivityaid facilities.in many
         ties ldeniified as missing and neede
         conversion situations include interactive term-
         inals, automatic translation programs, and aids
         for the manipulation of source code.  The first
                                      quicker response  to
         aid provides programers with
         tests of the converted programs, and the other
         two automate some of the work of changing the
      -- Lack of people trained in conversion.
                                   mechanism today  for
         seems to be no effective
         transmitting conversion  experience from  one
         project to another.  We know of no formal
         training in conversion available within the
         Government.  Frequently, junior people are

APPENDIX II                                       APPENDIX II

       assigned to conversion projects. One reason
       is that conversion is deemed a less presti-
       gious task; therefore, senior programers avoid
       it. On the other hand, the private sector has
       several firms which specialize in conversion

     -- Confusion of conversion effort by concurrent
        reesign.   Sometmes- the task of converting
        software becomes entangled with augmenting or
        redesigning it. Conversion means making the
        software produce the same outputs on the new
        computer (from the same set of inputs) as on
        the old one. Augmentation means to add func-
        tions to the program. Redesign may add func-
        tions or achieve the old functions in a dif-
        ferent manner. The often difficult task of
        conversion is frequently further complicated
        by concurrent user requests for augmentation
        or redesign.
Suggestions for improvement by
ex2erts and literature

     Experts' recommendations for conversion improve-
ments varied, depending upon their backgrounds. Ven-
dors' ideas included using their own products or serv-
ices; persons in standards organizations recommended
greater emphasis on standards; and a member of a DOD
central software design agency recommended further cen-
tralization of software development.  However, agreement
emerged on some points, which are discussed below.

    -- Federal center for conversion.  Several experts
        eel that a FederaI center for software conver-
       sion would be extremely valuable. They offered
       various oncepts, from that of a small group
       which would estimate conversion costs for spec-
       ific procurements to that of a larger entity.
       Both would estimate and actually perform the
       below-listed services for client agencies.
       Concepts of its organization ranged from that
       of a completely Federal staff and facility,
       through a Government-owned contractor-operated
       facility, accompanied by an interagency agree-
       ment on management.  Such a Federal center for
       conversion could:

      i.   Assess conversion aspects of specific pro-
           curements or upgrades by client agencies.

APPENDIX II                                      APPENDIX II

       2.     Contract for software conversion services
              for client agencies.

       3.     Cut conversion costs by performing con-
              versions for less skilled agencies.

       4.     Train in-house conversion teams from client

       5.     Help client agencies evaluate the suitability
              to their needs of using other software than
              that proposed for conversion.

     -- System procurement alternatives. Some of the
        experts felt that conversion costs should be
        given more consideration in the selection of
        large systems because (1) the high cost of
        conversion to a new vender may cancel any
        hardware savings and (2) conversion difficulty
        may cause a long, expensive delay in user func-
        tions. Such a consideration of conversion costs
        and time implies that some impartial entity
        should estimate them. This entity should have
        extensive experience with large-scale conver-

     -- Human factors. Most of the experts identified
        these as crucial to the success of both software
        development and software conversion. Selection,
        retention, and continued training of analysts and
        programers are felt to be deficient. The large
        variaticn in ability to create software should
        be recognized, and better means of identifying
        and training good performers should be developed.
        Modern productivity aids should then be used to
        support the good performers.

     -- Software development that anticipates conversion.
        Software deveiopmenl project managers can antici-
        pate eventual conversions and take steps to reduce
        problems with them. Such steps can include stand-
        ards for programing practices, such as limiting
        programers' use of vendor-unique features, and re-
        quiring better documentation.
     -- Further centralization of original software design
        and development. This offers a large potential for
        savings through eliminating redundant software
        development and the ability of the central devel-
        oper to concentrate resources, the cost of which

APPENDIX II                                      APPENDIX II

       will be s  red by multiple installations.  Such
       centralize ion could reduce conversion costs--a
       better job could be done of design and implemen-
       tation because multiple users would share its
       increased cost.  Such centralization may implv
       displacing programers from field installations.

     Management and organization must recognize and sup-
port technical methods before their potential will be
realized.   "- thwhile technical methods identified by
experts   nd in literature include:

     -- Government-wide distribution of automated conver-
       sion-aids and coversion manuaiTs.   Such programs
       an other materials coul be selected, for the
       COBOL and FORTRAN  / languages, from items al-
       ready developed.  Management emphasis should ac-
       company their dissemination.

     -- Standards for roqraming practices. These should
        be forced for new software development, for both
        Federal and contractor-developed software.  (Some
        agencies are already active here.) These standards
        could include the new programing technologies for
        software creation and some restrictions on the use
        and documentation of programing language features
        peculiar to a particular hardware vendor.

     -- Programer productivity aids. These should be in-
        stalled and their use encouraged wherever pos-
        sible. They include programs which print flow-
        charts of other programs and interactive term-

     -- Training. Systems analysts, programers, and man-
        agers should be trained in the new programing
        technologies. Management should encourage their
        use in both software creation and conversion.

l/Formula Translator.

APPENDIX II                                          APPENDIX II



     The questionnaire data collection was done to assess:

     --Working-level perceptions of the causes of soft-
                                          alue of var-
       ware conversion problems, and the .-
       ious means of improvement.
     -- The importance and frequency of conversion--how
        uften programers are involved in it, etc.
     -- Data on some related matters, including prcqramer
        demographics, language usage, training available,
        and programex activity breakdown.
     The mechanics of administration emphasized respon-
dent anonymity as much as possible to get honest input
from the working level. The questionnaire was admin-
istered in a classroom situation by our reoresenta-
tives.  The respondents were briefed, and the question-
naires were collected immediately after completion. Thus,
local hierarchies had no way of knowing what a given in-
dividual wrote on a questionnaire.

     Two quite similar questionnaires wre administered--
one to programers and the other to their supervisors.   At
a given installation, the supervisor group and the pro-
gramer group were separated during the completion of
their respective questionnaires. To give the respon-
dents maximum flexibility, most questions were con-
structed with a blank "other" choice where respon-
dents could write in their own answers, as well as a
convenient choice of answers.
     Our representatives who administered the     uestion-
naires reported that:
     -- There was no evidence of special selection of
        respondents by their local hierarchies.
     -- There was no evidence of rebriefing     of the re-
        spondents on the subject.
     -- Respondents did not see copies ui the     uestion-
        naire ahead of time.
     -- In almost all cases, respondents were favorably
        disposed toward the effort and indicated some
        interest in the subject.

APPENDIX II                                            APPENDIX II

     -- In some cases, respondents expressed consider-
        able interest in the subject, including de-
        sire to see the results.

     Processing of the questionnaires further confirmed
the respondents' interest in and good motivation toward
the subject:

     -- Almost all of the collected questionnaires were
        completed carefully enough to be useful (1,983
        out of 2,005 programer questionnaires and 458
        out of 465 manager questionnaires).

     -- The last question on each questionnaire (left
        completely blank for respondents' other dis-
        cussion) was written in by over 21 percent of
        the programers and over 33 percent of the super-
        visors (after they had ompleted over 30 other
        questions).  Also, there were numerous write-ins
        to the blank choices made available in the pre-
        ceding questions.

     -- A number of caustic write-in answers, such as
        "This questionnaire is a waste of time," showed
        that the respondents believed that they would
        be anonymous.

Description _of sites and respondents

     The data collection reached 43 different ADP in-
stallations, 2,005 programers, and 465 supervisors.
The sites ranged from the smallest one, where 2 pro-
gramer and 2 supervisor questionnaires were collected,
to the largest one, where 325 programer and 91 manager
questionnaires were collected. Figures 1 through 6
describe the sites and respondents.
                            Figure 1
                                   Site visited
       Region                DOD            Non-DOD         Total

     Kansas City              16                  10          26
     San Francisco             3                   6           9
     Detroit                   7                   1           8

          Total               26                  17          43

APPENDIX II                                                         APPENDIX II

          Figure 2:       Site populations by region:
                                Average programers                  supervisors
       Region                        per site                         per site

     Kansas ity                               60                         12
     San Francisco                            39                         11
     Detroit                                  13                          7

              Figure 3:     Experience of respondents-years
                             in at- rocessing:
                                                                Number with
                      Mean        Median           Mode         over 3 years

     Programers        9.2         8.1              8.0    a/1,565 out of 1,976
     Supervisors      12.6        13.2             15.0    a/  398 out of 458

              Fi ure 4:     Experience f respondents--years
                            in_present vetob:
                                                               Number with
                      Mean        Median           Mode        over 3 years

     Programers           5.1       4.1             1.0    a/1,100 out of 1,962
     Supervisors          5.3       3.9             1.0    a/ 242 out of 457

              Figure 5: Programers' and systems analysts'
                 categorzaton of their present jo s:
                 Category                                 Number       Percent

     Definite business orientation                            645        32.5
     Definite scientific orientation                          312        15.8
     All other answers, such as
       "senior analyst," "coder," etc.                      1,026        51.7

          Total                                           a/1,983       100.0

a/The numbers of respondents differ in figures 3, 4, and 5
  because slightly different numbers of people answered the

APPENDIX II                                       APPENDIX II

       Figure 6: Programers and systems analysts'
       experience with various prp1ami199guages:

                     Extensive        Moderate
                       work             work          No work
  Language          experience       experience      experience

                    (percent)        (percent)        (percent)
COBOL                  59.3              18.8           21.7
Assembly               38.0              24.5           37.4
FORTRAN                28.0              17.9           54.0
Machine language       14.4              32.8           52.8
Data management
  languages             6.6              11.1           82.3
JOVIAL                  6.2               2.1           91.7
BASIC                   6.0              11.5           82.4
PL/I                    3.2               5.7           91.0
RPG                     2.7              12.4           84.9
ALGOL                   1.9               2.8           95.2
GPSS                    0.4               3.1           96.6
SIMSCRIPT               0.1               0.9           99.1

Causes of software conversion problems

    Both groups evaluated two lists of causes of conver-
sion probiems--one list for conversion to a replacement
system and the other for conversion of foreign programs.
Both groups' choices on the lists were ranked by count-
ing those who answered that a choice was "at least mod-
erately important." Figures 7 through 10 show super-
visors' major causes of difficulty for replacement sys-
tems, programers' major causes for replacement systems,
supervisors' major causes of difficulty of converting
foreign programs, and programers' major causes for con-
verting foreign programs, respectively.

     Figure 7 shows that the supervisors ranked poor
documentation of the old application programs as the
most important cause of difficulty of conversion to
replacement systems. A close second was the inad-
equate weighting of conversion considerations in
selecting the replacement system to which the soft-
ware had to be converted.  The five highest ranked
causes shown can be regrouped into two broad cate-
gories:  (1) poor quality of the material to be con-
verted, which includes the first, third, and fifth
causes and (2) poor choice of the replacement sys-
tem, which includes the second and fourth causes.

APPENDIX II                                        APPENDIX II

           Figure 7:  Supervisors' major causes of problems
                with conversion to re acenient systems:

Percent ranking
cause important                  Cause_of_problems
    87.4                Inadequate or missing documenta-
                        tion of application programs.
    87.1                Conversion considerations are not
                        adequately weighted in the sys-
                        tem selection process.

    83.1               Many application programs are mono-
                       lithic and "patched;" that is,
                       they are NOT well structured,
                       modular, or well organized.
    82.0               Policy of selection of low bidder
                       could force us to accept a less
                       compatible system, such as one
                       made by a different manufacturer.

    79.2               Combination of personnel turnover
                       and poor documentation has made
                       many application programs vir-
                       tually unintelligible.

     Figure 8 shows that the programers selected the
same five causes as most important, with the same two
ranked first and second, as the supervisors. The third,
fourth, and fifth choices are in different order, but
the differences are slight.

      Figure 8:    Pro2ramers'
                         maor         causes of problems with
                  conversion o replacemen  t systems:
Percent ranking
cause important               Cause of   roblems

    80.3                Inadequate or missing documentation
                        of application programs.

    77.4               Conversion considerations are not
                       adequately weighted in the system
                       selection process.

 APPENDIX II                                       APPENDIX II
     73.4               Policy of selection of low bidder
                        could force us to accept a less
                        compatible system, such as one
                        made by a different manufacturer.
     73.2               Combination of personnel turnover
                        and poor documentation has made
                        many application programs vir-
                        tually unintelligible.
     73.1               Many application programs are mono-
                        lithic and "patched"; that is,
                        they are NOT well structured,
                        modular, or well organized.

     Figure 9 shows that the supervisors rank
to add new features to foreign programs as the the need
cause of difficulty with their conversion. These five
causes can be regrouped into three broad categories:

     -- Selection of unsuitable foreign software for
        conversion (first and fifth causes).

     --Poor quality of the material to be converted
       (second and third).

     -- Differences between vendors' products (fourth).

           Figure 9: Supervisors' major causes of problems
            with conversio--o- o oreg_     ams: _(note _a
Percent ranking
cause important                Cause of problems
    75.7                The task of conversion is complicated
                        by the frequent need to add new fea-
                        tures to the programs being converted.
    73.7                Foreign programs are often poorly or
                        inadequately documented.
    72.5                Foreign source code is often poorly
                        organized or does not contain embed-
                        ded comments/notes/remarks; therefore,
                        it is hard to read and comprehend.
a/A foreign program was defined on the questionnaire
                                                     as a
  program brought in from nother installation.

APPENDIX II                                             APPENDIX II

     67.0                 Differences in the features readily
                          available with different vendors'
                          operating systems affect the conver-
                          sion of applications programs.

     62.9                 Foreign programs need too' much
                          modification to the needs of
                          another installation to be worth

     Figure 10 shows that the programers ranked their
own lack of knowledge highest, with documentation a
close second. The programers' five causes can be re-
grouped into four broad categories:
        -- Lack of knowledge of conversion (first choice).

         --Poor quality of the material to be converted
           (second and fourth choices).
         -- Poor management (third choice).

         -- Unsuitable material to be converted (fifth choice).

We believe that the sligntly different opinions of the
programrL3 reflect t-he fact that they and the super-
visors hve a somewhat different perspective on con-
version projects.   (The supervisors ranked the "lack
of knowledge" choice at 56.0, showing that they consider
it considerably less important thai any of their own
top choices.)

   -----------                                -------

            Figure 10:  Proramers' major causes of roblems with
                     converslonof foreign  rams:

Percent ranking
cause important                    Cause of proolems

      76.8                People assigned to conversion projects
                          often have little knowledge of what
                          they might encounter.

      76.5                Foreign programs are often poorly or
                          inadequately documented.

 APPENDIX II                                                        APPENDIX II
              72.7                   Programers' supervisors allow them-
                                     selves to be talked into unreasonable
              70.7                   Foreign source code is often poorly
                                     organized or does not contain embed-
                                     ded comments/notes/remarks; there-
                                     fore, it is hard to read and compre-
              70.2                   The task of conversion is complicated
                                     by the frequent need to add new fea-
                                     tures to the programs being converted.

-----------              ---------
                           ---                   …-             ------------

     Figure 11 shows that the supervisors ranked better train-
ing for programers as the most valuable source of improvement
of conversion to replacement systems. The five means can
be regrouped into three.

               -- Improvement of the performance of programers
                  doing the work (first, third, and fourth choices).

               -- More consideration of conversion in the selec-
                  tion of replacement systems (the second).

               -- Improvement of management (the fifth).
The strong ranking given to the three choices in the
first category indicates that the supervisors feel that
programer training would be a very valuable means of

                 Figure 11: Supervisors' major means of improving
                        conversion  tore/cement systems:
Percent ranking
method valuable                              Method of improvement
              88.7                     Better training for programers i.n
                                        superior programing practices.
              83.7                     More weight to conversion cost
                                       and problems in the selection
                                       of replacement systems.
              82.7                     Better training for programer           in
                                       conversion problems and tech-

APPENDIX II                                     APPENDIX II

    82.7               Ability to send the conversion
                       team to appropriate specific
                       training before starting work.

    81.7               Better training for installation
                       managers in conversion planning
                       and estimating.

     Figure 12 shows that the programers also value train-
ing highly, for themselves (highest), for their super-
visors, and for user management. These five choices can
be combined into (1) training for programers (first, second,
and fourth) and (2) training for management (third and fifth).
This result indicates that the programers attach even more
importance to training than their supervisors do.
     We believe that the slight difference seen between
the programer and superviscr evaluations is due to their
different perspectives.  The managers' probable involve-
ment with the selection decision gives them a broader view.
     The emphasis on training here, coupled with the im-
portance of the poor quality cause, indicates that train-
ing programers to do a better job of originally writing
programs is valued highly as a way to reduce future trou-
ble with converting those programs.

       Figure 12:  Programers' mjor means of improving
             converson r        -tements:ste
                              n eiace

  Percent ranking
  method valuable            Method of improvement

      83.4            a/Better training for programers
                        in superior programing prac-

      80.8              Better training for programers in
                        conversion problems and tech-

      77.8              Better training for installation

a/These were defined for the respondents in a previous aues-
  tion, which they were referred to.

APPENDIX II                                       APPENDIX II
                        managers in conversion planning
                        and estimating.
      76.8              Ability to send the conversion
                        team to appropriate specific
                        training before starting work.
      74.4              Required training for user/
                        customer management to increase
                        their awareness of the possible
                        implications of their requests
                        and deadlines.

     Figure 13 shows that the supervisors value training
highly in the area of conversion to foreign programs also.
Again, the means can be regrouped:

     -- Better training in conversion (first and third
     -- Better enforcement of documentation practices

     -- More attention to conversion in selection of
        software (fourth).
     -- Better management (fifth).

Of these, the first and second are aimed at improving
the original quality of the material to be converted,
and the others are aimed at better conduct of the
conversion effort itself.

        Figure 13: Supervisors' maor means of improving
        rankig conversion o Toroelgnprograms:
Percent ranking
method valuable            Method of improvement

    86.6                Better training for programers in
                        superior programing practices.
    84.1                Better enforcement of good
                        documentation practices.
    83.3                Ability to send the conversion
                        team to appropriate specific
                        training before starting work.

APPENDIX II                                     APPENDIX II

    81.1                  More weight to conversion costs
                          and problems in the selection of
                          foreign programs to be converted.

    80.4                  Better trainir  for installation
                          managers in conversion planning
                          and estimating.

     Figure 14 shows that the programers also value train-
ing highly. They selected four of the same five most im-
portant causes and ranked them somewhat differently. As
with the supervisors' choices, the first is aimed at im-
proving what will eventually be converted better deve-
lopment), as is the third; the other three ae aimed at
better conduct of the conversion itself.

           Figure 14: Proramers' maor means of improvin¶
                   conversion o.f oreign prorams:

 Percent ranking
 method valuable               Method of improvement
      84.7                Better training for programers
                          in superior programing prac-

      80.7                Better training for programers
                          in conversion problems and

      79.1                Better enforcement of good docu-
                          mentation practices.

      78.9                Better training for installation
                          managers in conversion planning
                          and estimating.

      78.7                Ability to send the conversion
                          team to appropriate specific
                          training before starting work.

APPENDIX III                                             APPENDIX III

                           OFFICE OF THE SECRETARY
                             WASH INOTON, D.C.   Slad

                                                         JUlT   1   1911

     Mr. Gregory J. Ahart
     Director, Human Resources
     U.S. General Accounting Office
     Washington, D.C. 20548
     Dear Mr. Ahart:
     The Secretary hs asked that I respond to your request for our
     comments on 'o3ur draft report, "Federal Spending for Conversion
     of Computer rograms Could Be Reduced." We have carefully re-
     viewed your report and have no substantive comments.
     Thank you for the opportunity to review this draft report before
     its publication.
                                      Sincerely yours,

                                        omas D.Morris
                                      Inspector Gneral

APPENDIX III                                                   APPENDIX III

                         ASSIANT SCRETARY OF one
                             WAINeVTON,   D.C.    01.

                                                          MAY 13 1977
 Mr. D. L. Scantlebury
 Director, Division of Financial
   6 General Management Studies
 General Accounting Office
 Washington, D. C. 20548
 Dear Mr. Scantlebury:
 This is in reply to your letter to the Secretary of Defense
 regarding your report dated April 8, 1977, on "Federal Spending
 for Conversion of CoMputer Programs Could be Reduced," OSD Case #4597.
 While we are somewhat less optimistic than you about the
 potential for hard dollar saving as estimated in your draft,
 we support the contention that sufficient benefit will accrue
 to warrant establishment of a conversion center, vigorous promotion
 of quality and standards in software development, and standardization
 of software tools.

                                                  P. Welsch
                                Deputy Assisfint Secretary of Defense

APPENDIX III                                                APPENDIX III

                        .~   %.. I UNITED STATES DEPARTMENT OF COMMERCE
                                   The Asistnt SecrearyVfr Adminstration
                                  Washington., D.C. 20230

   5 JUL   77

 Mr. Henry Eschwege, Director
 Community and Economic Development Division
 U. S. General Accounting Office
 Washington, D. C. 20548

 Dear Mr. Eschwege:
 We have reviewed the draft report to Congress, entitled
 "Federal Spending for Conversion of Computer Programs Could
 Be Reduced" and concur in the three recommendations
 contained therein.

 With regard to the recommendation concerning establishment
 of a Federal software conversion center, we believe this
 subject was exhaustively studied by the Department of
 Defense and the General Services Administration.  This
 center is currently being used by several Federal agencies,
 including this Department in our Employee Information System
 conversion project.  [See note below.]
 Concerning the recommendation that the National Bureau of
 Standards select a set of tools and techniques for
 Government-wide use to improve the productivity of computer
 programmers, NBS recognizes the need for greater use of
 productivity aids and will devote its efforts in this area
 as priorities dictate and resources allow.


 Assistant Secretary
  for Administration

 GAO note:      The Navy's Federal COBOL Compiler Testing Service
                is doing some conversion work, but as of this
                writing, there is no interagency agreement for-
                mally establishing the conversion center itself.

APPENDIX III                                                           APPENDIX III

                          UNITED STATES OF AMERICA
                              WASHINGTON. DC 2005

   June 9, 1977

   Honorable Elmer B. Staats
   Comptroller General of the United States
   General Accounting Office
   Washington, DC 20548

   Dear Mr. Staats:

   We have reviewed the GAO draft report entitled "Federal

   Spending for Conversion of Computer Programs could be

   Reduced", and offer the attached comments.

   If there are any questiona,    please let us know.


    oel W Solomon


                 Keep Freedom in Tour Fuiure With U.S. Savirks Bonds

APPENDIX III                                                 APPENDIX   III

                         GSA COMMENTS
                         GAO Draft Report

                   COULD BE REDUCED"

A   The GAO report identifies some of the major problems encountered
    in software conversion and recommends that a Federal Center be
    established for software conversion. In particular, it cites poor DP
    management practices, (conversion planning and training), enforcing
    the use of standard higher-level programming languages, and the
    lack of good documentation as contributing substantially to the software
    conversion problem.

    Overall the report is a credible effort addressing a complex subject
    and we support its conclusions and recommendations. Yet its treat-
    ment of conversion is too narrow. Taken by itself, many of the
    observations and recommendations are true but the principal and
    underlying factor complicating the conversion issue is the lack of
    planning -- the management trade-off of major long term benefits
    at the expense of near term costs. Conversion and all its underlying
    symptoms (such as lack of documentation and unique programming
    features) are a result of a failure of management to adequately plan
    for future needs, even if it increases near term costs. The rport
    should recognize this broader problem and note that conversion is
    but one of its sub-issues.

    While adoption of the report recommendations would address some of
    the software conversion problems, it would not serve as a viable
    substitute for implementation of good DP management at the
    installation level.

*   The report is supportive of efforts to establish the Federal Conversion
    Support Center. The proposed functions of the Center will more than
    satisfy GAO's recommendations. However, there are complex
    software conversion problems, not directly discussed in the report,
    which the Center will be confronting:

        Conversion of systems which are compris d of various
        software programs developed by the incumbent equipment
        vendor, proprietary software firms, as well as the user

                                    47             5/31/77
APPENDIX III                                               APPENDIX III

            Conversion of efficient non-standard programs (such
            as proprietary data base management packages and
                            to higher level standard languages
            which, if accomplished, could be extremely costly.

                              [See GAO note below.]

      Although the Center will dramatically improve the present conversion
      environment, its establishment will not serve as a panacea anc
      result in the immediate resolution of all Federal ADP conversion
      cost issues. Many of the pr¢rblems confronted by the ADP cornmunity
      will require in-depth analyse.s and evaluations before the Government
      can expect to see the situation improved or the problems resolved.

 *    The report indicates that te use of unique programming features
      add considerably to the ccnversion effort required and that
      programmers should not use these features (or that at least they
      should be more closely controlled). While valid, the report fails
      to recognize that these unique features often provide programming
      and operational advantages over the near term.

 *    The report suggests that use of industry provided applications
      software cculd lower costs and speed implementation. This i the
      exception and not the rule. Generalized software packages can
      sometimes satisfy small applications requirements but frequently
      require modifications to fit specific needs.

  *   Data processing activities do not adhere to existing established
      Federal programming language standards. For example, although
      a Federal standard exists for COBOL, some data processing
      activities have waived this requirement and other(s) use vendor
      extensions to the standard COBOL, which make application software
      programs vendor dependent and incompatible with one another.
      These practices pose significant software conversion evaluation
      problems with any follow-on procurement. It would be helpful if
      this type of problem were addressed more fully in the report.

GAO note:      Deleted material    is not relevant to this final

APPENDIX III                                              APPENDIX III

                         [See GAO note 1.]

        A copy of the questions included in the report would have been
        helpful.     [See GAO note 2.]

                     [See GAO note 3.1

GAO notes:
1. Deleted comments are not relevant to this final report.

2. The questionnaires were omitted from the report to
   duce its bulk.
3. Deleted comment is not relevant to this final report.

APPENDIX III                                         APPENDIX III
                          WASHINGTON, D.C.   003OI

                          JUN 3 0 1977

  Mr. D. L. Scantlebury
  Director, Division of Financial and
   General Management Studies
  U. S. General Accounting Office
  Washington, D.C. 20548
  Dear Mr. Scantlebury:
  We are in receipt of your draft report entitled "Federal
  Spending for Conversion of Computer Programs Could be
  Reduced" transmitted by your letter of April 8, 1977.
  Mr. Lance has asked that I provide you with OMB's comments.

  We believe this report sheds some valuable light on a
  subject which has been of substantial concern to OB over
  the last few years. We are particularly pleased that you
  have provided an estimate of both the total cost of soft-
  ware conversion ($450 million) and an etimate of possible
  savings that can be ahieved by proper management (24%).
  At a convenient point, I would like to have my taff gain
  a better understanding of the basis for this stiate so
  that we can work towards achieving the savings which you

  With respect to your recommendation that OMB support the
  establishment of a software conversion center, we agree.
  We understand that GSA and Navy are currently involved
  in negotiations to set up a center which would provide
  the serviLcs you recommend. One aspect of this recomen-
  dation, however, is unclear. We are uncertain whether
  you believe the center should, by regulation, be made the
  exclusive source for the various conversion services it
  will perform, i.e., estimates, contracting, performing
  conversion, or experience transfer. We have found that
  any publicly funded service monopoly has a tendency over
  time to degrade in performance and cost effectiveness
  unless it is subjected to some degree of competitive
  pressure. If this is intended in your recommendation we
  would suggest that this aspect be re-examined. We
  believe the Federal Computer Performance EValuation
  and Simulation Center provides an excellent example
  of how a center of expertise can, through the force of
  competition, review itself and maintain efficiency. It
  APPENDIX III                                      APPENDIX III

does not have exclusive jurisdiction ever any of the
services it provides but it has a steadily increasing
demand for its ervices because of the quality of its
We would also call to your attention the views which
OMB expressed in a letter to the Chairman of the
Government Operations Committee (copy enclosed). OMB's
responses to Committee recommendations 10 through 14(See GAO note.)
are particularly relevant to the subject matter of
this report.


                                Wae Gr       ista
                              Associate Director for
                              Administrative Management

    GAO note:    The deleted recommendations are not
                 relevant to the subject matter of this

APPENDIX III                                    APPENDIX III

                                  January 19, 1977

 Honorable Jack Brooks
 Chairman, Committee on G <-ignment
 House of Representatives
 Washington, D.C. 20515
 Dear Mr. Chairman:
 This letter is in response to your letter of October 5,
 1976 requesting OMB views on House Report No. 94-1746
 entitled Administration of Public Law 89-306, Procurement
 of ADP Resources by the Federal Governrifnt." Our comments
 and suggestions in regard to each of the 19 recommendations
 contained in the report are enclosed.

 The hearings conducted by your Committee last summer and
 the subsequent report have served to identify a number of
 significant problems in the management of Federal ADP re-
 sources. These problems must be addressed and we have
 taken positive steps to do so.

 Due to the significant impact which the recommendations
 could have on the future direction of Federal ADP manage-
 ment, OMB invited the larger ADP user agencies and a
 number of trade associations to provide comments on the
 Committee's recommendations. The responses which we
 received are enclosed for your information.
 It is apparent from these responses that there is a
 strong consensus regarding the significance of the pro-
 blems outlined in the report, but there is a wide
 divergence of views as to the causes of these problems.
 There are also strong differences of opinion regarding
 some of the solutions proposed.  In short, there is
 agreement on the need to address these problems but no
 consensus on how to solve them.
  In concluding the hearings on July 1, 1976, you indicated
  that "o]nly time will tell whether these hearings will
  have a beneficial effect" and expressed the hope that
  "the report to follow will provide the necessary impetus

APPENDIX III                                           APPENDIX III

  for the future ainistration of the law." We believe
  the report has achieved that initial objective. A
  of recommendations have already been implemented or number
  in the process of being implemented. Where there are
  differences of opinion regarding some of the proposed
  solutions, we have either suggested alternatives or have
  taken steps to identify workable alternatives.
  We would also like to stress that there is no quick solu-
  tion to many of the complex issues which you have
  identified. For example, the development, coordination
  and implementation of standards, which are a prerequisite
  to the solution of a number of the problems identified,
  are not easily or quickly achieved in an area of rapidly
  changing technology. Similarly, the development, coordi-
  nation and implementation of an effective long range
  planning process will not be brought about easily or
  quickly. These, and other basic reforms needed, will
  require a sustained effort by the Federal ADP Community
  accompanied by extensive consultation with the Congress,
  the private sector, State/local governments and others
  which would be affected by such reforms.
 As OMB Deputy Director Paul O'Neill indicated during his
 testimony, we look forward to working in close
 with the Committee in furtherance f our mutual cooperation
 of making effective use of computer technology.
 With best wishes.

                                    Sincerely yours,

                                    /t/ Jlam T.Lo
                                    James T. Lynn
 cc:   Secretary of Commerce
       Administrator, GSA

    APPENDIX III                                   APPENDIX III

                      (See GAO note, p. 51)

Recommendation 10 - NBS must develop necessary hardware and
software standards to insure maximum economies and efficiencies
in the procurement and utilization of ADP resources.
OMB agrees with this recommendation. We believe that the
Federal ADP standards program needs to be strengthened to
achieve greater efficiency and eco.,omy. Such strengthening
of the standards program must, however, be accomplished in
a manner which will not stifle competition or preclude the
Government from taking advantage of new technology.
Comments received from agencies and representatives of
industry are very supportive of this recommendation and pro-
vide many constructive suggestions on approaches to achieving
an appropriate balance between the sometimes conflicting
objectives of reducing cost, exploiting technological develop-
ment and encouraging competition.
A number of actions to strengthen the standards program have
been initiated by OMB and NBS. In general, they focus on:

o   A reappraisal of the goals and objectives of various
    ongoing standards development activities.

o A greater emphasis on defining the potential benefit pf
    proposed standards or guidelines before undertaking the
    development of such standards or guidelines.
o   A prioritizing of these activities so that resources can
    be focused on those activities which will produce the
    greatest benefits.

    APPENDIX III                                   APPENDIX III

    A greater emphasis on clearly prescribing (in the
    applicable FIPS PUB) all policies, responsibilities
    and administrative actions required for appropriate
    implementation of each standard or guideline. These

    - Whether the standard is mandatory or voluntar.
    - Specific implementation actions which agencies are expected
      to take.
    - The conditions or criteria under which waivers to mandatory
      standards may be granted.
    - The procedures for granting waivers.
    - The time frame for implementation.
    - The requirements for use or disposition of existing
      inventories of nonstandard supplies, hardware or software.
    - Requirements for including the standard in procure-
      ments by GSA and/or the agency.
o   Establishing a process for monitoring implementation of each
    standard and evaluating whether it is meeting its intended
    objective and, subsequently revising the standard, as appro-
    priate, based on operational experience or changing conditions.

o   A greater emphasis n evaluating technology trends and
    their mplicatins in regard to the Federal ADP standards
Recommendation 11   OMB must establish procedures for the
effective enforcement of ADP standards and designate GSA as
the agency to enforce compliance with such standards.

OMB is in complete agreement with what we believe to be
the objective of this recommendation - to achieve compliance
with mandatory standards - but only partially agrees with the
proposed means for achieving this objective.

We believe that the Department of Commerce (NBS) under P.L.
89-306, E.O. 11717 dated May 9, 1973, and the policy guidance
provided to the Secretary of Commerce by OMB in a letter dated
December 15, 1966 has adequate authority for the Federal ADP
standards program. In our view, NBS has the responsibility
to develop and implement the type of standards program en-
visioned by P.L. 89-3"' and E.O. 11717 and this would
necessarily entail, among other things, the articulation of
the goals and objectives of such a program (e.g., compatibil-
ity in equipment), the development of appropriate standards

APPENDIX III                                   APPENDIX IIL

or guidelines to achieve those goals and objectives, the
development of the means for assuring the effective imple-
mentation of these standards or guidelines and the development
of the means to monitor and evaluate the impact of such
standards or guidelines. We believe that P.L. 89-306 con-
templates that the exercise of this authority by the Department
of Commerce (NBS) be undertaken in coordination with industry,
the user agencies, GSA and OMB in order to ensure that the
requirements of these entities are met and to permit effective
implementation. Some questions have recently been raised by
representatives of the Department of Commerce in regard to
the scope of responsibility and authority in particular
matters vested in the Department of Commerce (NBS) by P.L.
89-306, L.O. 11717 and related OMB policy guidance. We will
explore and resolve these questions with the Department in
conjunction with our plans to reissue OMB Circular No. A-71
as indicated in response to recommendation 3. We are satis-
fied that the standards or guidelines contemplated can be
effectively implemented through existing authorities, but
should the need for additional authority become evident,
such authority shall be sought.
In our view, good management requires that overall respon-
sibility for the Federal ADP standards program be retained
by one organization and not be divided. It has been and
continues to be our belief that the Department of
Commerce (NBS) is the logical organization to carry out
these responsibilities. Retaining the overall responsi-
bility for the Federal ADP standards program within the
Department of Commerce (NBS) does not, in our view, pre-
clude the Department from coordinating, assigning, or
delegating certain authorities for developing, implementing
or monitoring compliance with individual standards to the
agencies, GSA or others as appropriate. We believe the
method for implementing individual standards will depend
upon the nature of the standard. For example, we would
agree that mandatory standards which affect products or
computational services purchased by the Federal Government
should e implemented largely through GSA procurement regu-
lations. On the other hand, we question whether GSA should
categorically be nade responsible for "enforcing" all FIPS
PUB's including those which provide guidance to agencies on
the use or management of their ADP resources. Such assign-
ment, depending on the nature of the standard, could be in
conflict with the provisions of the Act which precludes GSA
from interfering in agency use of ADP. Further study of
this question is necessary.

  APPENDIX III                                      APPENDIX III

 We believe that determinations on the most appropriate means
 for implementing Federal ADP standards must be made on a
 case-by-case basis. We are working with NBS to establish
 a program for proceeding with analysis as outlined in our
 response to recommendation 10.
Recommendation 12 - All ADP procrams should be converted to
higher level langua es except in those cases where OMB
specifically determines that the national interest requires
(MB agrees that more emphasis should be placed on agency use
of high level languages since such languages facilitate the
conversion of software from one hardware system to another and
reduce the costs inherent in such conversions. However,
precise criteria must be established for determining whenmore
                                                          it is
in the national interest to use high level languages, either in
the conversion of existing software or in writing new software.
Agency comments indicated general agreement with the recom-
mendation that greater use be made of high level languages
but urged that mandatory use of high level languages be
limited to new software. They expressed the concern that, even
were it possible to do so, the conversion of all existing
software to higher level languages would be very costly,
unnecessary and counterproductive to the goals of economy and
efficiency. Most agencies that commented on recommendation 12
felt that existing software should be converted only when it
is economical and efficient to do so.
We believe that the appropriate way to implement this recommenda-
tion is to have NES:

  o   Establish standards, or refine existing ones, on the use
      of high level languages for new software.

  o   Establish criteria to determine under what conditions
      existing software should be converted to high level
We believe that this is a more appropriate way to approach
the problem than having OMB review software on a case-by-
case basis to determine if it is in the national interest
to convert it. As indicated in our response to recommendations
10 and 11. the NBS guidance should include appropriate mechanisms
for implementing and monitoring compliance with the standards.
Given the advantages that can accrue from the use of high
level languages we believe that NBS should place a high riority
on efforts in this area.

 APPENDIX III                                    APPENDIX   III

Recommendation 13 - Software conversion costs should not be
considered in the evaluation of bids for the procurement of
ADP systems except to the extent that such costs involve direct
out-of-pocket costs for program conversion.
OMB and the agencies have had some difficulty formulating a
response to this recommendation since the meaning of the
phrase "direct-out-of-pocket" costs is unclear. It is our
understanding that this recommendation:
   o Stems from a concern that agencies frequently justify
less than fully competitive procurement on the grounds that
software conversion would be too costly to consider alter-
natives requiring such conversion.
   o Assumes that the implementation of recommendation 12
will significantly reduce software conversion costs.

   o Is intended as an interim measure to enhance competition
until such time that recommendation 12 is implemented.
As indicated in our response to recommendation 12 we endorse
the use of high level languages and the development of appro-
priate standards for converting existing software and writing
new software. The approach recommended by OMB would permit
the orderly conversion to high level languages in an economic
and efficient manner over a period of time. This approach
and the other steps we are taking, such as promoting functional
specifications, promoting research on standardized data base
management systems and improving long range planning, should
reduce the costs of conversion and lead to fuller competition
in ADP procurements.
OMB believes that this recommendation should not be implemented
prior to the conversion of most software to high level languages.
If agencies were required to ignore the costs of software con-
version in the current environment they might be placed in the
position of having to select a significantly more costly alter-
native without any offsetting public benefit. This would, of
course, be contrary to the P.L. 89-306 goal of economy. OB
believes that ADP procurements should be conducted in a manner
such that each ADP system is evaluated on the basis of its
total system life cycle costs, including software conversion
costs and the least cost alternative is selected. Generally,
the agencies took issue with the Committee's recommendation and
expressed the view that all costs associated with converting
from one system to another should be considered and that it
would be unfair to have an agency absorb software conversion

 APPENDIX III                                    APPENDIX III

We believe that it is GSA's responsibility to develop a costing
methodology for ADP procurements which will provide guidance
on what cost elements should be considered in comparing
alternative systems and under what conditions specific costs
may be excluded. We would urge GSA to work closely with the
Committee staff in order to assure that the staff's intentions
regarding direct out-of-pocket costs are fully considered.
We also understand that the GAO has undertaken research in
this area. When the results of this research become available
GSA should review the GAC efforts and take action to implement
appropriate recommendations.

Recommendation 14 - Research should be undertaken pursuant
to OMB's direction aimed at the development and use of
management information systems which contribute to competitive
ADP procurements and utilization.

OMB agrees that research relative to the development and use
of standardized data base management systems should be
undertaken. Standardized data base management systems
should ultimately facilitate the conversion of data files
from one hardware system to another and lead to greater
opportunities for competitive procurements.

P.L. 89-306, E.O. 11717 and the OMB policy letter of December
15, 1966 assign the responsibility for the Federal ALP
standards program including ADP research to the Department
of Commerce. The National Bureau of Standards has recently
created a task force to study problems associated with data
base management systems. We will work closely with NBS
in this area.

                    (See GAO note, p. 51)