United Stales General Accounting Officte .GAO,. Report to the Chairman, Subcommnittee oneTransportation · and Related Agencies, Committee on., , Appropriations,-H ouse 'f. Representativses .June 1990 ' , t s o * - PROUREMENTh H /. ' Competition for Major. )ataProsssg - . S . - I L u d ' :' ~ ' ' . ' "~~~1 *1** ,...t ' - ' ,k : - .4 .'. 9- p. ,,,~~~ .:.~ ,* 9. . . .. #A~~~~~~~~~~~2 ii r r~~~~~~~~ -I ~~~~~~~~JI ~~ ~ " ~ ~ Ilp. GAO;?IMTEC-90-71 0 ' - · · - ·- · ·· ·* ·- · c''-: ~~~- · ·- ·· United States Washington, D.C. 20548 Information Management and Technology Division B-239902 June 11, 1990 The Honorable William Lehman Chairman, Subcommittee on Transportation and Related Agencies Committee on Appropriations HIouse of Representatives Dear Mr. Chairman: This report responds to your request that we review the Federal Avia- tion Administration's (FAA) acquisition approach for its Computer Resources Nucleus (CORN) project. The CORN project is intended to meet the agency's general-purpose data-processing needs for 10 years and provide optional processing support to other organizations within the Department of Transportation. Specifically, you asked that we deter- mine if a key design requirement in the CORN request for proposals may have unnecessarily limited competition. Appendix I explains our objec- tive, scope, and methodology. Results in Brief F'A.'s original objective for the CORN procurement was to achieve full and open competiion and encourage innovative vendor proposals. This was to be done by communicating what FAA needed (functional require- ments) while allowing vendors flexibility in determining how best to meet agency needs. Although initially recognizing that varied combina- tions of hardware and software could meet its needs, FAA later decided to require a single architecture solution on the basis that it would reduce operational costs and provide a technical platform for an integrated data base. A single architecture, however, will not necessarily meet these objectives. Further, in its request for proposals, FAA did not define key functional requirements for achieving its objectives, such as those pertaining to data accessibility. As a result, FAA (1) unjust fiably limited competition and restricted the range of solutions that vendors could offer and (2) dictated a system design that may not satisfy the agency's needs. We have previously recommended that the CORN procurement not be awarded because FAA had not adequately planned and justified the acquisition.' In planning future procurements such as (ORN, FAA should 'FAA l'rocurement: Major [)ata lrocessing Contract Should Not Be Awarded (GAO/IMTEC-90-38, May 25, 1990). In addition, we isued a fact sheet on the project', C4,nmputer Procurement: FAA's $1.5- Billion Computer Resources Nucleus Project (GAO/IMTEC-89-44FS, Mar. 31, 1989). Page I GAO/IMTEC.90-71 Limited Competition on FAA Data-Procesing Procurement B-239902 define the agency's needs in functional terms wherever possible and inciude restrictive provisions only if justified by the agency's mission needs. ack1round linder CORN, r'..A intends to divest itself of its general-purpose data- processing resources, located at 12 agency facilities. In their place, FAA plans to enter into a single contract under which the contractor would provide the agency with data-processing services. The contractor would provide, maintain, and operate computer facilities, equipment, systems software, and technical support to meet IAA mission and program needs, as specified in CORN'S request for proposals. The contractor would also convert current applications to the new system, but FAA would continue to develop and maintain its applications software. The contractor must also be able to provide similar data-processing services for other organi- zations within the Department of Transportation. The contract would cover an initial 5-year period, followed by five 1-year renewals. FAA esti- mates the contract value to be $1.5 billion. FAA issued the CORN request for proposals in February 1989. The con- tract was scheduled to be awarded by mid-1990. However, the House Committee on Appropriations has directed FAA and the Department of Transportation to defer awarding the CORN contract until they resolve issues raised in our earlier report on the project. FAA's CORN Federal Information Resources Management Regulation part 201- 30.013-1 states that specifications shall be developed in such a way as to Acquisition Goal Is maximize, not limit, competition. Establishing functional require- Full and Open nmants-that is, delineating precisely the needs that must be met, rather Competition than how those needs will be met X rh a particular system design-is the preferred method for expressing users' requirements. The regulation recognizes that the use of restrictive proN isions or conditions may be necessary in acquiring property or services, but only to the extent needed to satisfy the agency's needs. In other words, an agency may restrict the technical options that potential contractors can use if the agency can demonstrate that the restriction is necessary and justified. One of the original and continuing objectives of the CORN project is to obtain full and open competition. As stated in its September 30, 1987, CORN itequirements Analysis, FAA intended to ensure, in accordance with the requirements of the Competition In Contracting Act and other rele- vant statutes, "that the project attracts a broad competitive range and Page 2 GAO IMTEC-90 71 Limited Competition on FAA Data-Procewng Procurement B-239902 does not unfairly eliminate potential solutions." This position is in keeping with the January 1987 CORN project charter, where FAA stated that it "would not specify how the vendor would perform the job, only what computing and other services would be provided at what levels. The vendor would be responsible for obtaining the best hardware and software to do the job and operating facilities that made data processing most economical and responsive to users." FA.'s declared acquisition strategy was to prepare a request for pro- posals in functional terms that would "allow the widest possible selec- tion fi solutions, while preserving the functional requirements of the Agency."' In its April 1988 mission needs statement fcr CORN, FAA reaf- firmed its intention to "conduct this procurement in a manner that ensures the broadest competitive range of bidders and encourages the submission of innovative configuration proposals." FAA Decides to Limit Although its acquisition strategy was to allow the widest possible selec- tion of slutions, FAA decided to include a key design requirement for Potential Computer coRN's computer architecture. Computer architecture is the organiza- Architecture Solutions tional structure of a computer system, including hardware and software. FAA decided that the ultimate solution to the agency's functional data- processing needs must employ a single rather than a multiple architec- ture. The C(ORN request for proposals, however, did not include a defini- tion of either "single architecture" or "multiple architecture." Because there are no generally accepted definitions of these terms, we asked pro- jec!t officials to define them. They gave us the following: · Single Architecture (synonymous with single computer architecture) - a configuration of hardware and software components wherein all major processor (('c i) Icentral processing unit] components run the same con- trol program (operating system) at the same version level, and the same system software (e.g., language versions, database management sys- tems, utility software) such that FAA application processes (programs and OCL 1Iperational control languagel) can be run on any such ci: without modification. · Multiple Architecture (synonymous with multiple computer architec- ture) - a configuration wherein the major components, e.g., (l',! do not meet the single architecture criteria. F-'AA's Ie'enmitwr 1987 agency pnI urement request to t he General Setrvices Administration states that (()oN "contracting will he accomplished under proxedurbes for full and opeln competition. Requirements are bhing specified in funcllt ional ierformanve terms. A fully competitive procurement will be used." Page 3 GAO/IMTEC-90-71 Limited Competition on FAA Data-Proceseing Procurement B239902 FrAA'S current general-purpose data-processing system, which CORN is to replace, is a particular type of multiple architecture environment made up of one IBM 3084 mainframe computer and 22 Data General MV/ 15000 minicomputers. The computers are interconnected by the agency's Administrative Data Transmission Network. In justifying CORN, FAA has maintained that limitations in its current multiple architecture system are impeding the agency's ability to meet all its mission needs. Evolution of the Single At first, FAA did not mandate that the CORN configuration have a single Architecture Requirement architecture. In the two initial draft CORN specifications documents developed in 1987, FAA stated that it recognized that there are varied combinations of automatic data processing hardware and software that could provide the services needed. Accordingly, the September 1987 draft specifications, which FAA provided to vendors for comment, state: A single type hardware and software architecture solution is not mandated. If mul- tiple architectures are proposed as part of the solution then each must fully meet the stated criteria. Since a single architecture provides relatively greater return on investment for the Agency in the long term the evaluation of proposals will consider this as a factor. A vendor could, therefore, propose either a single or multiple system architecture as a solution to FAA'S need, thr'llghout the life of the contract.:' In its June 1988 version of the draft solicitation document, however, FAA changed its position and included a basic system architecture require- ment. FAA deleted the sentence stating that a single architecture solution was not mandated and added the requirement for a single architec- ture-eithei initially or within the first 3 years of the contract. This requirement is included in the final version of the CORN request for pro- posals, specified as follows: If multiple architectures are provided then each shall fully meet the performance level requirements stated in this Section Isection C]. If the Contractor provides mul- tiple architectures initially, the transition to a single architecture shall be completed within the first three (3) years of the Contract. 'One architecture-related restriction included in the fist two draft specifications documents addresses the possibility that a contractor might propose to piovide a multiple architecture system initially with a plan to switch eventually to a single architecture. In this situation, FAA required that the transition be completed within the first 5 years of the contract. Page 4 GAO/IMTEC-90?I71 Limited Competition on FAA Data-Proceen Procurement B-239902 According to FAA, the purpose of the requirement is to ensure that there would be no confusion in meeting CORN objectives and to ensure con- formance with agency policy regarding the need for an integrated data base environment-. Vendor Concerns After the CORN iequest for proposals was issued in February 1989, FAA the Single Regarding received written comments from two industry vendors questioning the Regarding tecture Restricnecessity and rationale for the single architecture requirement. The ven- Architecture Restriction ~dors claimed that a multiple architecture system could result in signifi- cant benefits and asked FAA to relax this requirement, or at least mrke it only a desirabiL option. For example, one vendor claimed a multiple architecture option could substantially reduce the cost of the conver- sion, allow of ferors to design a technical solution that best addresses the application environment of FAA, and reduce the system life cycle cost of equipment and maintenance. In addition, the veltdior claimed that a mul- tiple architecture would drastically improve the time frame for transi- tioning from the current system to CORN?. FAA's Rationale for In a July 1989 internal issue paper, to support the single architecture requirement :' FAA cited the following key reasons Requiring a Single Architecture Solution * A single architecture will provide a technical platform for an integrated data base environment, where accurate and current information could Is Not Justified be readily accessed by whoever needs it. * A multiple architecture will consume 300 more employee years than a single architecture system and significantly increase costs to the government. This rationale is inadequately supported and therefore inclusion of thfs requirement limiting all CORN design solutions to a single architecture is not justified. 'FAA alsou emphasized that the initial draft solicitation documents, which did not contain the require- ment, were intended as requetsts for comment from interested parties, ar.d should not be considered final, polished statements of requirements. 'Project officials currently estimate that it will take 3 rears tm convert current applications to CORN. 'In its delegation of prKocurement authority for CORI'. the General Services Administration urged F.4A to thoroughly document the project's procilrement files with supporting justification for actions that may tend to restrict competition. FAA officials state that the July 1989 issue paper represents the agency's rationale for the single architecture requirement. Key points in the paper were provided to vendors in a July 1989 "Questions and Answers" document. Page 5 GAO/IMTEC-90-71 Limited Competition on FAA Data-Processilng Procurement B-239902 Specifying an Architecture According t') FA-, the single architecture requirement is directly sup- Does Not Assure an ported by policies found in the agency's Information Resources Manage- ,Integrated Data mase "ment Plan, which requires that information systems incorporate the Integrated Data Base following concepts in their design: Environment · data elements are entered once and thereafter used and reused by anyone who needs them; * information derived from multiple sources cart be interrogated and accut-sed as a whole; and * high flexibility is provided to accommodate changes through the elimi- nation of interdependencies among user language, data-processing pri(cesses, and data base organization. However, these concepts are not inciuded as functional requirements in the request for proposals. Moreover, agency officials do not recognize that specifying an architecture will not ensure that these goals can be achieved or necessarily provide a technical platform for easily attaining an integrated data base. There may be cases where a single architecture would not meet these goals whereas a multiple architecture could. For example, a distributed system could be proposed wherein several of the same processors with the same operating and system software are con- nected via a local area network. In this system, some FAA applications would be resident on one machine, others would be resident on a second machine, and so on. with the samec data base management system resi- dent on each machine. Such a system would satisfy FAA's requirement for a single architecture. However, if data are stored in this system on separate machines as separate data bases and not .s a single, distributed data base, it would not be possible to interrogate and access all the data in the system as a whole. Also, depending on the locations of the dif- ferent applications, the data, and the applications' data needs, it may be necessary to enter data several times, not just once, for each application to have ac(ess to the data it needs. Conversely, an open distributed system of different processors con- nected via a local ares network, which meets the definition of a multiple architecture, could achieve the r)lan's goals. In this system, if a common user interface and an open distributed data base management system are employed. then it may be possible to interrogate and access all data in the system as a whole and to enter the data only once. Although we are not suggesting that one architecture is preferable to another, FAA's rationale that only a single architecture can meet its information man- agement goals is not supported. Page 6 GAO/IMTEC-9071 Limited Competition on FAA Data-Processing Procurement B-239902 Increased Costs to FAA According to FAA, another reason for requiring a single architecture is Not Supported that the costs to the government will be significantly higher in a mul- tiple architecture environment due to additional programming costs and programmer/analyst tLaining, decreased productivity, and higher opera- tional costs resulting from less efficient processing. As discussed below, these programming, productivity, and operational cost estimates are flawed. * Programming Costs: F9. states that the additional time for >FAA programmer/analysts to maintain a common user inteiface in a multiple architecture environment "is estimated at 15%, whicn translates into the equivalent of over 300 additional staff years" or an estimated cost of $137,280,000 over 10 years. No rationale or data have been provided for the derivation of this estimate and the use of 15 percent. Further- more, FAA programmers would not nc,'essarily be responsible for main- taining a common user interface. The interface could be considered part of the contractor's equipment and facilities, and as such would be the contractor's responsibility to maintain, not FAA'S. Also, FAA programmers and analysts would not necessarily need to learn more than one environ- ment. A vendor with a multiple system architecture could propose a single, integrated development environment for the programmer/ana- lysts, which would permit them tr target software for any machine in the architecture. In this case, the. programmer/analysts would only have to learn one environment for development. * Productivity Costs: l.4A states that if a multiple architecture is provided with,r Acommon user interface, "each user would waste 15 minutes per day moving between different architectures while completing daily automation tasks .vithout a common interface." FAA equates this with logging ort and off the different architectures and estimates that it will result in a loss of productivity of $87 million. This argument is not valid since it is not applicable solely to a multiple architecture. A distributed system could be proposed that meets the de finition of a single architec- ture but which requires users to log on and off different processors in the system to reach the processor where the application is resident and to meet security procedure s. Therefore, the additional cost of $87 mil- lion for a multiple architecture is not supported. * Operational Costs: FAA maintains that it is likely that superimposing a common user interface on a multiple architecture environment will require more computer resources over the life of the contract than per- fo-rning the same functions in a single architecture environment. 'rhere- fore, i'AA concludes that a multiple architecture system would increase AA's l()0-year computer operations costs. FAA, however, offers no sup- port for this assumption. Page 7 GAO/IMTECr90-71 Limited Competition on FAA Data-Processing Procurement B-239902 Data-Processing Restricting the design solution to any particular architecture is not an adequate Slubstitute for carefully delineating the agency's functional Requirements Need to requirements wherever possible and specifying them in the request for Be Clearly Defined proposals. As previously noted, establishing functional requirements is the preferred method for expressing users' requirements. Further, defining functiopal requirements in the request for proposals enables vendors to determine how to respond with proposed solutions that would meet the requirements. Htowever, 'AA did not fully define its func- tional reouirements. For example, FAA did not translate the Information Resources Management Plan goals into its request for proposals as func- tional requirements. Examples of areas where F'AA may need to define specific requirements are: o single entry of data; · the interrogation, accessing, and interchanging of data resident any- where in the system; and the porting (moving) of applications, and system and support software (e.g., operating sy!:tem and data base management systems) among the different data-processing equipment in the system. FiA officials stated that it was unnecessary to include these require- rr.ents in the request for proposals. They argued that F'AA'S intent has been identified in its overall program objectives and th. t if a vendor's proposal did not satisfactorily accomplish these objectives, FAA could remedy this dulring subsequent negotiations. Itowever, the request for proposals, not the agency's intent, is the official document that vendors use to determine whether and how to respond. Conclusions ,FAA'S ntended acquisition approach is to define the agency's data- processing needs in functional terms in order to promote full and open competition. Ilowever, instead of defining key functional requirements in the ('OrSN request for proposals, FAA has substituted a single arc!hitec- ture design solution which it maintains will enable the agency to meet mission needs. In requiring a single architecture, FAA unjustifiably lim- ited competition and restricted the range of solutions that vendors couid offer. Moreoverl, FAA dictated a system design that may not satisfy the agency's needs. As a result. potent ial cost-effective solutions :nay have been unnecessarily eliminmted arnd systems propesed by vendors may not satisfy the agency's needs. Page 8 (AO/' IMTE'-90-71 Limited Competition on FAA Data-Processing Procurement W239902 Recommendation to In our May 1990 report on CORN, we recommended that the contract not be awarded because FAA had not adequately planned and justified the the Secretary of procurement. We pointed out that the agency should adequately define Transportation its data-processing needs before proceeding with an approach such as CORN. In defining the best way to meet these needs, we recommend that the Secretary of Transportation direct the Administrator, FAA, to first fully specify the agency's functional requirements wherever possible. Examples of functional requirements that may need to be specified include single entry of data; interrogation, accessing, and interchanging of data; and porting of software among different equipment. In co.lin. this, if FAA determines that the procurement should have restrictive pro- visions, then it should justify their inclusion. :FAA should then allow the vendors to propose systems that they believe will best meet the agency's requirements. FAA should plan to adequately test and evaluate vendors' proposals to determine how well they meet the stated requirements, at a reasonable cost and acceptable risk to the government. We obtained the views of Department of Transportation and FAA offi- cials on the key facts, conclusions, and recommendation contained in this report. These officials disagreed with our conclusions and recom- mendation. They maintained that the single architecture requirement is necessary to achieve FAA's information management goals. A senior department official for information resource management stated that the single architectl e requirement was a judgment based on how the agency should do its business and did not require detailed written justi- fication. FAA officials also questioned the need to put the type of func- tional requirements identified in this report into the CORN request for proposals. FAA maintained that the vendors were aware of FAA's intent and that if a vendor's solution did not adequately provide needed capa- bilities, any such problems could be addressed during negotiations or the contract could simply not be awarded. Regarding the view that the decision was based on the agency's judg- ment and did not require documentation, the General Services Adminis- tration urged F.A to thoroughly document the project's procurement files with supporting jus' ifications tor aci,ons that may tend to restrict competition. While FAA documented its decision for a single architecture to some extent, we have demonstrated that FAA'S rationale was faulty. In response to our requests for further justification of its decision, FAA did not expand on its rationale. Regarding functional requirements, we believe that a system architecture requirement is an inadequate substi- tute for detailed specifications of the agency's functional requirements. Page 9 GAO/IMTEC90-71 Limited Competition on FAA Data-Processing Procurement B-239902 Such specifications should precede any decision to require a particular type of system architecture. As arralged with your office, unless you publicly announce its contents earlier, we plan no further distribution of this report until 30 days after the date of this letter. We will then send copies to interested congres- sional committees; the Secretary, Department of Transportation; the Administrator, FAA; the Director, Office of Management and Budget; the Administrator of General Services; and other interested parties. This work was performed under the direction of JayEtta Z. ' ,cker, Director, Resources, Community, and Economic Developme ii nforma- tion Systems, who can be reached at (202) 275-9675. Other i.,, jot con- tributors are listed in apprendix II. Sincerely yours, Ralph V. Carlone Assistant Comptroller General Page 10 GAO/IMTEC-G9071 Limited Competition on FAA Data-Processing Procurement BLANK P.GE Page 11 GAO/IMTEC-90-71 Limited Competition on FAA Data-Proceimng Procurement Appendix I Objective, Scope, and Methodology The Chairman, House Committee on Appropriations, Subcommittee on Transportation and Related Agencies, asked that we review FAA'S $1.5- billion CORN procurement. Our specific objective was to determine if a key design requirement in the CORN request for proposals may have unnecessarily limited competition Accordingly, we reviewed the provisions of the Competition in Con- tracting Act, the Federal Acquisition Regulation, and the Federal Infor- mation Resources Management Regulation regarding competition. We interviewed FAA and Department of Transportation officials to deter- mine their rationale for having a restrictive system architecture require- ment. We also examined all relevant project documents, inc.lding the requirements analysis, project charter, mission need statement, agency procurement request, the delegation of procurement authority, draft solicitation documents, the request for proposals and subsequent amendments, vendors' comments on the request for proposals and FAA'S responses, and an internal FAA paper discussing the rationale for requiring a single architecture system. Our review was conducted at FAA headquarters in Washington, D.C., from April through June 1990. We performed our work in accordance with generally accepted government auditing standards. Page 12 GAO/IMTEC90-71 Limited Competition on FAA Dat-Procesnag Procurement Appendix II Major Contributors to This Report Joel Willemssen, Assistant Director Information John P. Finedoi'e, Evaluator-in-Charge Management and Dr. Rona B. Stillman, Chief Scientist Technology Division, Frank Reilly, Senior Technical Adviser Susan Maciorowski, Presidential Exchange Executive Washington, D.C. William D. Hadesty, Technical Adviser David M. Bruno, Computer Scientist Office of the General Office of the General Jerold D. Cohen. Assistant General Counsel Counsel (510556) Page 13 GAO/IMTEC9O-71 Limited Competition on FAA Data-Procesing Procurement *.i.*J,\ t's for copis.of reports should heI'seni 1to: .% i, -l I ,el-pll 2 . ¢'1 i1 o' l'}<'cr ¢).ffidci oil .11; i I'hit ( ·) ,-(' a211d'ii )*" ) . ,) T.lthot9 for ()it'zoi ) \,)6.-J ( *~-. · 1(, ,C -11 I , , .~ 0(il('h. single ad(hdrts., ! 4)1 )) .IC(' (Orders IKI.,.Iie, .prepaid l)v ('alh or Ii(ut-.% 4o)r4h'r · muaf. (Iout to the suiperilnil(enu'll of ID(wi).llmen Inls. 2. I~~' · . rit · t~d · St a t t~~s -- First-'Class . Mail (GeneratAccouint inig (Offie t-as h .ostage & Fee.s Mil Paid Washington, D.('. 2054 ( A() · P. '(,itAN'(10 Official.Business Penalty for Private Use $;0() ' k ' I .. . ' 'IL - I.~~· I ~ .·;· · · · ,~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~V ··
FAA Procurement: Competition for Major Data-Processing Project Was Unjustifiably Limited
Published by the Government Accountability Office on 1990-06-11.
Below is a raw (and likely hideous) rendition of the original report. (PDF)