AUDIT REPORT IG-04-017

Report Recipients: 

B/Audit Liaison 

Representative 

OJD/Audit Liaison 

Representatives 

GSFC/201/Audit Liaison 

Representative 

INTEGRATED FINANCIAL MANAGEMENT 

PROGRAM BUDGET FORMULATION 

MODULE 

March 30, 2004

cc: 

A/Integrated Financial 

 Management Program

 Executive 

B/Deputy Chief Financial 

 Officer for Financial 

 Management

B/Director, Integrated 

 Financial Management 

 Program (Acting) 

B/Deputy Director, 

 Integrated Financial 

 Management Program

GSFC/201/Budget

 Formulation 

 Project Manager

 National Aeronautics and 

Space Administration

OFFICE OF INSPECTOR GENERAL 

Released by: ___[Original Signed By]________________

David M. Cushing, Assistant Inspector General for Auditing 
IG-04-017 March 30, 2004 

 A-01-061-05 

Integrated Financial Management Program (IFMP) 

Budget Formulation Module (BFM) 

Managing under a full cost concept is a Federal requirement that has been embraced by 

NASA under its full cost initiative. The full cost initiative consists of three 

components—full cost accounting, cost-based budgeting, and full cost management. The 

Budget Formulation Module (BFM), a component of the Integrated Financial 

Management Program (IFMP), supports NASA’s initiative for cost-based budgeting. 

The BFM supports formulation of NASA’s institutional, program, enterprise and Agency 

level budget requirements. NASA is currently implementing BFM in three releases. 

Release .5 was implemented in October 2003 and designed to contain 80 percent of the 

module’s functionality as the basis for ‘bottom up’ Center budgeting. Release .5B, was 

implemented on February 23, 2004, to capture the remaining functionality that would be 

part of Release .5. Release 1 is to contain the remaining 20 percent of the module’s 

functionality, and be the basis for ‘top down’ Headquarters budgeting. 

Since the initial stages of our audit, which began in May 2003, full implementation dates 

for BFM have slipped twice. Originally scheduled for implementation in February 2004, 

the target date is now January 2005, meaning that NASA’s planned use of the IFMP to 

implement cost-based budgeting—the final component necessary for full cost 

management—will be delayed until fiscal year 2006. 

At the time of our audit, we were concerned that the NASA BFM Team had not: 

• Engaged key users of the BFM, specifically Headquarters enterprise personnel, in 

the development of the system until October 2003, nearly 21 months after the 

project’s inception and less than 5 months before the initial planned 

implementation (Audit Issue 1); 

• Included, as planned, five key BFM requirements in Release .5, which was the 

first of the three BFM releases (Audit Issue 2); and 

• Included sufficient functionality in the BFM document repository system that 

would have enabled elimination of a legacy budget document repository system 

(Audit Issue 3). 

Due to the fast moving nature of the BFM implementation, we immediately 

communicated those three issues to the NASA IFMP Program Executive with four 

recommendations for improvement. NASA management responded to the issues and, as 

of the issuance of this report, has adequately addressed all issues. We consider two of the 

four recommendations closed. The other two recommendations are resolved but will 

remain open pending our review of NASA’s stated actions. 
Audit Issues and Recommendations 

Audit Issue 1. BFM Headquarters-Level Functionality 

When we reported this issue to management on January 14, 2004, enterprise resource 

personnel—integral BFM users who require budget data to make business decisions and 

provide information to NASA stakeholders (NASA Office of the Chief Financial Officer 

(CFO), Office of Management and Budget [OMB], and Congress)—had concerns with 

the functionality of BFM with phasing plans, the report form and content area, and 

adjustments to Center budget data. Those concerns came about because enterprise 

personnel had little involvement until October 2003 in the BFM requirements definition 

process. As a result, we were concerned about whether the Agency would have sufficient 

time to build the necessary functionality into the BFM and test the software in time for 

full implementation of the module, which at that time was scheduled for May 2004. 

Although the system design was essentially complete, some of the NASA enterprise 

personnel we interviewed stated they had concerns with the BFM. Specifically, those 

concerns involved developing phasing plans, the BFM report form and content, and 

adjustments to Center budget data. The issues that the enterprise personnel cited as 

potential problems could have impeded job performance and degrade the timeliness and 

accuracy of budget data provided to NASA’s primary stakeholders. 

Phasing Plans. Enterprise personnel stated that the steps necessary to complete phasing 

plans would be greatly increased using the BFM. Under the current NASA Budget 

System, phasing plans for current and prior year funds, as well as obligations and costs, 

are entered on one screen. To enter the phasing plans in the BFM, however, not only are 

current and prior year funds entered on different screens, but obligation and cost plans 

are also entered on separate screens. The enterprise personnel stated that having to enter 

data in such a manner would increase the workload, especially with the system’s reported 

slow processing time. 

Report Form and Content. Some enterprise personnel stated that BFM reports that 

were produced by the Core Financial Module business warehouse (which stores the 

budget data) would not be useful to the enterprises. Those enterprise personnel stated 

that obtaining needed data requires a manual process that includes exporting data from

the business warehouse to an Excel spreadsheet, then manipulating the data to the format 

needed to perform trend analyses. Those enterprise personnel stated that the manual 

process took a significant amount of time to perform and still did not always produce the 

desired results, and it would be more beneficial if the BFM or the business warehouse 

could produce reports in a more useable format. 

Adjustments to Center Budget Information. Enterprise personnel stated that the BFM 

did not support the automated update of Center budget data resulting from enterpriselevel adjustments. When enterprise personnel made adjustments to budget data, the 

2 
Centers had to run a manual report in order to reconcile their records to the enterprise 

records. Enterprise personnel stated that it would be desirable if the BFM automatically 

adjusted Center-level budget data when adjustments are made at the enterprise level. 

Manually updating budget records is labor intensive and increases the risk that 

enterprises’ budget changes to the Center data will be inaccurate or incomplete. Ensuring 

that enterprise budget adjustments are automated would ensure that the following year’s 

budget starting point is accurate. 

Enterprise personnel were not involved from the beginning in the design of the BFM. In 

February 2002, the BFM Project Team began conducting workshops that included NASA 

personnel from each Center to aid in developing system requirements and design. 

Management at each Center determined which personnel would attend the requirements 

and design sessions. Based on our review of the workshop rosters and through 

discussions with IFMP personnel, we found that primarily Center CFO office personnel, 

not enterprise personnel or program managers, attended the workshops. The IFMP 

Program Executive stated that although enterprise personnel were invited to all of the 

module’s requirements planning sessions, for the most part, those personnel either chose 

not to attend or were unable to attend. Enterprise personnel stated that they did not 

attend planning sessions because they believed that the system’s requirements had 

already been defined and when they did raise questions concerning requirements for the 

BFM, IFMP personnel told them that they would have to “live with” those requirements. 

The BFM Project Manager stated that enterprise personnel would be involved only with 

the design of Release 1, and would therefore not have any involvement with the BFM 

until later in the implementation cycle. 

On October 27, 2003, management directed that a design team of enterprise personnel 

and the NASA Headquarters Director of Resources Management convene to help define 

Headquarters BFM requirements. Enterprise personnel we interviewed stated that this 

exercise was beneficial and that the team identified basic requirements for all of NASA’s 

enterprises. The basic requirements that the team identified did not, however, include the 

three requirements identified by enterprise personnel, as noted. 

At that time we were concerned about whether the Agency would have sufficient time to 

accommodate enterprise requirements in time for the scheduled full implementation in 

May 2002. If Release 1 of the BFM were implemented without including all of the 

enterprise requirements, the Agency would have been unable to obtain and provide in a 

timely manner complete and accurate data for both internal use and to NASA’s primary 

stakeholders. We believe that this situation could have been avoided had enterprise 

personnel been involved in the requirements definition process at the beginning. 

3 
Recommendations, Management’s Response and Evaluation of Management’s 

Response 

1. Ensure that as a top priority for any future IFMP module, integral users are 

identified and involved at the earliest stages of design and functionality 

determination. 

Management’s Response. Management concurred with the recommendation. 

Management stated that integral users of the BFM were identified and involved at the 

earliest stages of design and functionality determination for the Budget Formulation 

Project. Headquarters user involvement in BFM began on June 11, 2003. Consistent 

with their role as primary users, Center representatives comprised the requirements 

design team for Release .5. Similarly, the enterprises and the Office of the CFO with 

their role as primary users comprised the requirements design team for Release 1. The 

complete text of management’s response is in Appendix D. 

Evaluation of Management’s Response. Management’s action is responsive to the 

recommendation, and the recommendation is closed. 

Although we believe management’s actions are responsive we believe some of their 

statements are inaccurate. Management’s statement that integral users were involved at 

the earliest stage of design of the project is misleading because: (1) Release .5 and 

Release 1 for the BFM are interdependent, and all users should therefore have been 

involved in the design of both releases; (2) Although some Headquarters users did start to 

become involved in the BFM project in June 2003, most Headquarters users did not 

become integrally involved in the design process until October 2003; and (3) even if all 

necessary Headquarters users became integrally involved in the BFM design process in 

June 2003, that date was too late. 

Interdependency of Release .5 and Release 1 for the BFM. Release .5 (which involves 

mostly Center personnel) and Release 1 (which involves most Headquarters personnel) 

are interdependent and share common information. For example, data Center personnel 

enter into Release .5 transfers to the enterprises at NASA Headquarters (Release 1) for 

analysis and changes. Later in the budget process, the Release 1 data are transferred to 

Release .5. Because of the interdependencies of the two releases, all of the module’s 

users (both Center and Headquarters) should have been involved from the beginning. 

Although we agree that enterprises and CFO personnel are not direct users of Release .5 

but are for Release 1, the information that Center users enter into Release .5 directly 

affects the enterprises, and vice versa. Involving enterprise personnel for only the design 

and requirements determination for Release 1 is a clear example of NASA management 

treating Release .5 and Release 1 as two separate systems, even though they are 

interdependent. 

The General Accounting Office (GAO) Executive Guide for Creating Value Through 

World-class Financial Management (GAO/AIMD-00-134 dated April 2000) emphasizes 

the importance of involving, early in the development process, all critical users of a 

4 
proposed system. The Guide states that to demonstrate and reinforce commitment to 

improving financial management, heads of agencies and senior executives could involve 

key program managers and business managers in implementing financial initiatives. 

GAO’s 1987 Policy and Procedures Manual for Guidance of Federal Agencies, Appendix 

III, Chapter 4–“Accounting System Development and Modification,” though superseded 

by requirements established by the Joint Financial Management Improvement Program, 

contains some valid points about involving users early in a project’s development cycle: 

accounting system acquisition and development should be managed by

a structured process that provides for continuous involvement of users 

throughout the process . . . .Also critical to the success of the system

development is user involvement. Users should be an integral part of 

the project team, participating in all phases. Involving the user from

the start is one of the most effective ways of identifying system

requirements and problems and perhaps the only practical means of 

ensuring system acceptance by the organization. 

Headquarters User Involvement. We disagree with management’s assertion that 

Headquarters users became involved with the BFM definition process of functional 

requirements beginning in June 2003. Although some Headquarters users did start to 

become involved in the BFM project in June 2003, most Headquarters users did not 

become integrally involved in the design process until October 2003. On August 15, 

2003, the BFM Project Manager stated that the necessary decisions regarding 

Headquarters requirements would be made by the end of September 2003. In addition, 

we conducted numerous interviews supporting that enterprise personnel had little 

involvement in the requirements definition process for the BFM until October 2003. 

Timeliness of Headquarters Involvement. Headquarters user involvement in the BFM 

was not timely. We believe that Headquarters enterprise personnel not being involved 

until later in the requirements definition process was what contributed to the slip in the 

implementation date of Release 1. 

In August 2003, the BFM Project Manager stated that enterprise personnel would 

become heavily involved during September 2003, with the project’s requirements 

definition process. As the enterprise personnel were getting ready to be involved in the 

process, Release 1 was scheduled for implementation barely 6 months away—on 

February 23, 2004. That implementation date would have left less than 6 months to 

develop the requirements, modify the software1

 accommodating those requirements, test 

the software, and provide enough time for users to become familiar with the software 

before having to use it for an actual budget cycle. 

 1

 Budget Formulation Project Management described the BFM SAP Strategic Enterprise Management

software as a ‘toolkit’ to which SAP programmers conform to NASA’s budget process. According to the 

BFM Project Plan, the Agency solution (budget process) is imprinted into the SAP Strategic Enterprise 

Management software, creating the budget formulation system, along with the necessary interfaces to the 

Core Financial and Office of Management and Budget reporting capabilities, and data analysis tools. 

5 
The planned implementation of Release 1 subsequently slipped to May 2004. However, 

as of January 2004, NASA enterprise personnel had concerns with the functionality of 

BFM and its ability to produce phasing plans, with the BFM report’s form and contents 

of the reports, and with adjustments to Center budget data. On January 30, 2004, the 

planned implementation of Release 1 slipped to January 2005. According to IFMP 

management, the justification for the release date slippage was to provide NASA 

Headquarters personnel an adequate period of time to become familiar with the BFM 

before having to use it for producing major budget deliverables. 

2. Direct that the BFM project management works closely with NASA 

Headquarters enterprise personnel to ensure that the BFM will meet 

enterprise needs for phasing plans, internal and external (including OMB 

and congressional) reporting requirements, and adjustments to Center data. 

Management’s Response. Management concurred with the recommendation. The BFM 

Project realigned its release strategy and schedule. In consultation with the CFO, the 

IFM Program Office delayed until January 2005 the implementation of the Headquarters 

functionality of BFM. The decision was made to provide Headquarters personnel an 

adequate period of time to become familiar with the BFM before having to use it for 

producing major budget deliverables. A “dress rehearsal” environment will be available 

from September through December 2004. The dress rehearsal will allow, as a training 

exercise, Headquarters personnel to produce fiscal year 2006 budget deliverables. 

Enterprise representatives on the design team endorsed this as their preferred approach. 

Evaluation of Management’s Response. Management’s action is responsive to the 

recommendation. The recommendation is resolved but will remain open pending our 

assessment of Headquarters personnel’s familiarization period with the BFM software 

beginning in September 2004.

Audit Issue 2. Inclusion of Key BFM Functionality in Release .5B 

When we reported this issue to NASA management on January 14, 2004, five key system

requirements that were originally planned to be included in BFM Release .5 were not in 

the release. The requirements were (1) data integrity business checks that would ensure 

that budget planners do not assign the wrong appropriation to a project, (2) full system

traceability (audit trail), (3) restricted access to embargoed budget data, (4) acceptable 

system response time, and (5) an on-line quick reference tool. Those five key system

requirements were critical to Center program and project staff in developing their 

‘bottoms-up’ budget data—the primary reason that NASA needed those requirements 

included in Release .5. On October 20, 2003, we issued a memorandum to the NASA 

IFMP Executive reporting our concern that those requirements were not going to be 

included in Release .5. On October 22, 2003, the NASA IFMP Executive and the IFMP 

Director stated that because of new full cost requirements that had been developed late in 

the Release .5 development cycle, the requirements originally planned for that release 

were deferred to an additional release—Release .5B. 

6 
Considering the late change in planning that resulted in having key functionality delayed 

until Release .5B (implemented February 23, 2004), we were concerned about whether 

those requirements were in fact included in Release .5B. Including those five key system

requirements in Release .5B would both ensure that the final release (Release 1, which at 

the time we reported this issue to management was scheduled for January 2005) 

contained the requirements and allowed ample time for addressing user feedback, coding 

required changes into the software, and testing those changes. 

Recommendation, Management’s Response, and Evaluation of Management’s 

Response 

3. The IFMP Program Executive should include and fully test in BFM Release 

.5B the required data integrity business checks, full system traceability, 

restricted access to embargoed data, system response time, and on-line quick 

reference tool functions as planned before Release .5B is implemented. 

Management’s Response. NASA partially concurred with the recommendation. 

Management stated that the on-line quick reference tool will be available soon for 

Release .5B. Management found that full audit trail capability and data integrity business 

checks would result in significant degradation of system performance, and restriction to 

embargoed data was no longer a NASA-identified requirement. Management stated that 

Centers could restrict viewing of their data in the pre-POP [Program Operating Plan] 

process to their Center only. In subsequent Agency versions, viewing outside of a Center 

will be restricted to “released” (official) versions only (see Appendix D). 

Evaluation of Management’s Response. We consider management’s actions 

responsive to the recommendation. In a January 2004 video conference, IFMP officials 

acknowledged that a slow system response time was still a problem and stated they were 

working with SAP (the BFM software vendor) to rectify the problem. The 

recommendation is resolved but will remain open pending further OIG monitoring, 

follow-up, and evaluation of NASA’s actions related to this issue. 

Audit Issue 3. Maintaining the Legacy Data Warehouse Document 

System. 

When we reported this issue to management on January 14, 2004, the BFM system

designed to store sensitive electronic documents pertaining to key budget decisions and 

directives—the Business Information Collector (BIC)—did not have sufficient 

functionality necessary to preclude the unauthorized manipulation of documents. 

The unauthorized manipulation of documents can be controlled through the use of 

Portable Document Files commonly referred to as .PDF files. A Portable Document File 

is a file format that captures all of the elements of a printed document as an electronic 

image, making it difficult to alter a document. A SecurID token would provide an 

additional level of security requiring the user to combine a known password with a 

7 
number generated by the token. The electronic document warehouse (the Business 

Information Collector) could not maintain Portable Document Files and did not require 

the use of SecurID tokens. 

In order to keep this critical budget function, the Agency had planned to maintain the 

legacy data warehouse document system—the Code BR Information Collector (BRIC). 

The BRIC both supported the .PDF format and required a SecurID token to access 

sensitive documents. Because one of IFMP’s primary objectives is to eliminate the many 

supporting systems that existed in the Agency, keeping the BRIC—which NASA 

personnel estimate could cost approximately $51,000 annually to maintain—is both 

counter to the IFMP goals as well as costly. 

Recommendation, Management’s Response, and Evaluation of Management’s 

Response 

4. The IFMP Program Executive should ensure before Release .5B is 

implemented that BIC contains adequate security safeguards that protect 

sensitive data so the Agency can eliminate the legacy Code BF data document 

warehouse system. 

Management’s Response. NASA partially concurred with the recommendation. The 

BIC was not implemented in Release .5 or Release .5B but is planned for a future update. 

The Budget Formulation Team is working with the Headquarters design team to 

determine how the capability should be used in Release 1. Inability of the BIC to serve 

as a large repository for documents is the result of functionality limitations and not 

security limitations. Appending a large volume of documents in BIC can negatively 

impact performance of the system. As of March 2004, the BRIC provides for distribution 

of a high volume of documents. Replicating this document repository within the BIC is 

not considered feasible (see Appendix D). 

Evaluation of Management’s Response. We consider management’s actions 

responsive to our recommendation. Our analysis of management’s response and followup with several NASA personnel, found that our recommendation was no longer feasible. 

Although one of the original objectives of the BIC was to replace the BRIC, because of 

functionality differences between the two systems, replacing the BRIC is no longer a 

feasible option. The recommendation is considered closed. 

Appendixes 

Among the other appendixes, note that Appendix A contains other matters related to our 

audit objectives for which management is aware and is implementing corrective action. 

Appendix C contains our audit scope and methodology related to the issues contained in 

this summary report, and Appendix D, contains background information on the BFM and 

full cost management. Appendixes E through G contain management’s responses in their 

entirety that were submitted to the Office of Inspector General by way of emails dated 

February 13, 2004, February 25, 2004, and March 1, 2004. 

8 
List of Appendixes 

Appendix A – Other Matters 

Appendix B – Status of Recommendations 

Appendix C – Objectives, Scope, and Methodology 

Appendix D – Background Information on the Budget 

Formulation Module and Full Cost Management 

Appendix E – Management’s Response Received February 13, 2004 

Appendix F – Management’s Response Received February 25, 2004 

Appendix G – Management’s Response Received March 1, 2004 

Appendix H – Report Distribution 

Acronyms Used in the Report 

BIC Business Information Collector 

BRIC NASA Code BR Information Collector 

BFM Budget Formulation Module 

CFM Core Financial Module 

FY Fiscal Year 

GAO General Accounting Office 

IFMP Integrated Financial Management Program

OIG Office of Inspector General 

OMB Office of Management and Budget 

9 
Appendix A. Other Matters 

The following are matters related to our audit objectives for which management is well 

aware and implementing corrective action. 

Program and Project Definition 

The BFM and CFM are not functionally compatible. The incompatibility exists because 

the CFM architecture hierarchy is based on the Agencywide Coding Structure, whereas 

the BFM was designed using a Theme-based hierarchy. Agency officials stated that this 

is a well-known problem and the primary reason NASA has had difficulty defining what 

exactly designates either a program or project in the CFM. 

NASA officials stated that the Theme-based BFM data easily maps to the budget 

execution data. The different design hierarchies in the BFM and CFM, however, make 

consistently defining programs and projects quite difficult. For example, multiple unique 

three-digit project numbers could exist for a given project within a program depending 

where (which Center) the data were obtained. NASA made standardizing program and 

project data among Centers a high priority. One official we interviewed considered 

proposing the overhaul of the entire reporting format and hierarchy. The result of such 

an overhaul would be consistency between budget execution [CFM] and budget 

formulation data. 

We will not know for some time whether NASA can ensure compatibility of program and 

project data among Centers. Regardless, we believe NASA is on the right track because 

they realize the importance of designing a reporting structure and hierarchy that is 

consistent between the budget execution [CFM] and budget formulation hierarchies. 

Full Cost Determination in Management Reports 

NASA has been working to devise reports that will be useful and understandable to 

NASA management, while at the same time providing the full cost of a given program or 

project, including its individual components. The former IFMP Director designated a 

team to devise reports that provide, by components, the full cost of a program or a 

project. NASA has successfully done that, and the reports will soon be in production. 

As of February 23, 2004, the reports include a program or a project’s full cost with the 

exception of the Construction of Facilities cost, which report users need to obtain from a 

separate report. However, NASA is working to include the Construction of Facilities 

cost in the reports so obtaining this cost from a separate report will not be necessary. 

NASA managers need the full cost reports to facilitate business decisions and provide 

NASA stakeholders with timely and accurate information. 

10 
Appendix B. Status of Recommendations 

Recommendation No. Resolved Unresolved Open/ECD* Closed 

1 X X

2 X 9/30/04

3 X 9/30/04

 4** 

*ECD–Estimated Completion Date. 

**Recommendation 4 was withdrawn. 

11 
Appendix C. Objectives, Scope, and Methodology

Objectives 

The objective of our audit was to determine whether the BFM will meet the needs of

NASA’s program and project managers and effectively support full cost budgeting, 

specifically whether: 

• The BFM Project Team solicited input from users other than budget and financial 

management personnel (for example, NASA’s program and project managers) 

when configuring the module to meet those users’ needs; and 

• BFM was functionally compatible with the IFMP CFM fully implemented in June 

2003 (for example, programs and projects are consistently defined in both 

modules). 

Scope and Methodology 

We reviewed BFM requirements, the process for determining the BFM requirements, 

design documents and other miscellaneous documentation, and determined which users 

are considered integral users of the BFM. To meet our objectives, we conducted 

interviews with numerous NASA Headquarters and Center officials, including enterprise 

directors, chiefs, and deputy directors, business leads, program and resource analysts, 

business managers, support service contractors, business process leads, and subject 

matter experts. 

A formal audit reporting process became difficult to achieve due to the tight schedule that 

the BFM Team was following to meet the targeted BFM implementation dates. To 

minimize our impact on the BFM Team in meeting its schedule, we used a quick 

response reporting process to address the objectives. Management took responsive 

corrective actions in response to each of the observations, but the recommendations will 

remain open for further OIG monitoring, follow up, and evaluation. The purpose of this 

report is to consolidate observations, recommendations, and management actions to meet 

our reporting obligations. We did not review any specific management controls during 

our field work.

Audit Field Work 

We performed audit fieldwork related to the objectives of this report from May 2003 

through February 2004 at the BFM facility and Goddard Space Flight Center in 

Greenbelt, Maryland; NASA Headquarters; Glenn Research Center; and in accordance 

with generally accepted Government auditing standards. 

12 
Appendix D. Background Information on the Budget Formulation 

Module and Full Cost Management 

One of the primary objectives of the IFMP is to support the Agency’s Full Cost Initiative, 

which began in response to NASA requirements and Federal law. In February 1999, 

NASA published its “Full Cost Initiative Agencywide Implementation Guide” (Full Cost 

Guide). The guide describes three elements of the Full Cost Initiative as follows: 

Full Cost Accounting. In full cost accounting, all costs are tied to a particular NASA 

project and consist of direct costs, service costs, and G&A costs. Direct costs are costs 

that can be readily related to a specific project. Examples of direct costs are materials 

and labor. Service costs are costs that cannot be immediately related to a project. 

Examples of service costs are information technology and publishing services. These 

costs are later related to a project and are distributed to a project based on usage or 

consumption. G&A costs are costs that cannot be related to a specific project, but benefit 

all activities. Examples of G&A costs are financial management and procurement. 

Cost-based Budgeting. All costs are budgeted against NASA projects and NASA plans, 

manages, and controls funds based on a project perspective. 

Full Cost Management. The project manager should use cost information to make 

informed decisions regarding resources management in order to optimize the costeffective performance of a particular project. Full cost management cannot be achieved 

until full cost accounting and cost-based budgeting is successfully implemented. 

The Budget Formulation Module (BFM), a component of the Integrated Financial 

Management Program (IFMP), supports NASA’s initiative for cost-based budgeting. 

The BFM supports formulation of NASA’s institutional, program, enterprise and Agency 

level budget requirements. NASA plans to implement is currently implementing BFM in 

three releases. Release .5 was implemented in October 2003 and designed to contain 80 

percent of the module’s functionality as the basis for ‘bottom up’ Center budgeting. 

Release .5B, was implemented on February 23, 2004, to capture the remaining 

functionality that would be part of Release .5. Release 1 is to contain the remaining 20 

percent of the module’s functionality, and be the basis for ‘top down’ Headquarters 

budgeting. 

NASA started work in the BFM in February 2002. Since the initial stages of our audit, 

which began in May 2003, full implementation dates have slipped twice. Originally 

scheduled for implementation in February 2004, the target date is now January 2005 

meaning that NASA’s planned use of the IFMP to implement cost-based budgeting—the 

final component necessary for full cost management—will be delayed until fiscal 

year 2006.

13 
17

Appendix E. Management’s Response Received on February 13, 2004

Following is management’s verbatim response to Audit Issues 1 through 3, Recommendations 1 

through 4, which we received by email on February 13, 2004. Management’s response is 

embedded in our issued report and is shown in bold text.

A-01-061-05

Budget Formulation Module: OIG Concerns

We are conducting an audit of the Integrated Financial Management Program (IFMP) Budget 

Formulation Module (BFM). BFM is the final component necessary for NASA to implement 

full cost management by way of the IFMP. The BFM Project Office’s initial plans were to 

implement the BFM in two separate Releases (Release .5 and Release 1). Release .5 was 

designed to contain 80 percent of the module’s functionality and was scheduled for 

implementation in October 2003 as the basis for ‘bottom up’ Center budgeting. Release 1 was 

scheduled for implementation in February 2004, contain the remaining 20 percent of the 

module’s functionality, and be the basis for ‘top down’ Headquarters budgeting. 

Since we started our audit, the Agency’s BFM implementation schedule changed. Release .5 

was scaled back significantly [NOTE: “significant” might be too strong a statement here. 

Only the C of F functionality, G&A allocation methodology (both due to policy delays, 

not system related) and Plan vs. Actuals (Center workload issues) were deferred to 

Rel .5B] and implemented on October 27, 2003. An additional release, Release .5B, was 

introduced with the intention of capturing the remaining functionality that was part of the original 

Release .5. That release is planned for February 23, 2004. Release 1 was delayed until May 

31, 2004. In conducting the audit, we identified the following potential issues that could impact 

the successful implementation of the BFM.

Audit Issue 1. BFM Headquarters-Level Functionality

As of January 2004, NASA enterprise resource personnel—integral BFM users who require 

budget data to make business decisions and provide information to NASA stakeholders—had 

concerns with the functionality of BFM with phasing plans, the report form and content area, 

and adjustments to Center budget data. Those concerns came about because NASA 

enterprise resource personnel had little involvement until October 2003 in the BFM 

requirements definition process. [The definition of requirements for HQ functionality in 

BFM began with a meeting of the Enterprise and Code B representatives on June 11, 

2003. Numerous workshops were held over the summer of 2003 to define HQ 

requirements (June 30 – July 2, July 15, August 6, August 13 –14 and September 3, 

2003). A dedicated team of senior members of the resources staff from the major 

Enterprises (Code M, Y, S, U, and R) and Code B was convened in October 2003 to 

finalize the design of the HQ component of BFM. 
Appendix E 

This dedicated team worked through mid-November for 3 days per week to finalize 

requirements and design. On November 20, 2003, the requirements for the HQ 

component of BFM were presented to the Agency Comptroller, Steve Isakowitz, for 

his approval. All Enterprises were represented at that meeting and verbally gave 

their approval of the requirements. 

The BF Project has now realigned its release strategy and schedule. In consultation 

with Code B, the IFM Program Office has delayed the implementation of the HQ 

functionality of BFM until January 2005. This decision was made to provide HQ 

personnel an adequate period of time to get familiar with the BFM before having to 

use it for producing major budget deliverables. A “dress rehearsal” environment 

will be available from September through December 2004 to allow HQ personnel to 

produce FY 06 budget deliverables as a training exercise using BFM. Enterprise 

representatives on the design team have endorsed this as their preferred approach. 

The current NASA Budget System (NBS) will be used to produce the FY 06 budget 

deliverables from HQ. Data entered into BFM by the Centers for their POP submit 

will be uploaded to NBS after May 31, 2004 to allow HQ to begin the development of 

their budget deliverables.] 

As a result, we are concerned about whether the Agency will have sufficient time to build 

the necessary functionality into the BFM and test the software in time for full 

implementation of the module currently scheduled for May 2004. 

Although the system design is essentially complete, some of the NASA enterprise 

resource personnel we interviewed stated they had concerns with the BFM. Specifically, 

those concerns involve developing phasing plans, the BFM report form and content, and 

adjustments to Center budget data. The issues that the enterprise personnel cited as 

potential problems could impede job performance and degrade the timeliness and 

accuracy of budget data provided to NASA’s primary stakeholders (NASA CFO office, 

Office of Management and Budget [OMB], and Congress). 

• Phasing Plans. Enterprise personnel stated that the steps necessary to complete 

phasing plans would greatly increase using the BFM. Under the current NASA 

Budget System, phasing plans for current and prior year funds, as well as 

obligations and costs, are entered on one screen. [There is no current NASA 

Budget System for phasing plans. Each Center submits phasing plans to the 

respective Enterprises using a variety of methods, but the most common 

method is Excel spreadsheets.] To enter the phasing plans in the BFM, 

however, not only are current and prior year funds entered on different screens, 

but obligation and cost plans are also entered on separate screens. The enterprise 

personnel stated that having to enter data in such a manner would increase the 

workload, especially with the system’s reported slow processing time. [The 

description of the phasing plan design is incorrect. Planners plan all 

15 
Appendix E 

obligations and costs on one screen, for all program years. The phasing plan 

screen design is very close to the current Excel template required by Code B 

and the Enterprises. Perhaps the Enterprises were referring to the method 

used in the Core Financial module for entering phasing plans.] 

• Report Form and Content. Some Enterprise personnel stated that BFM reports 

that are produced by the core financial module business warehouse (which stores 

the budget data) would not be useful to the enterprises. Those enterprise 

personnel stated that obtaining needed data requires a manual process that 

includes exporting data from the business warehouse to an Excel spreadsheet, 

then manipulating the data to the format needed to perform trend analyses. Those 

personnel stated that the manual process takes a significant amount of time to 

obtain the desired results and it would be more beneficial if the BFM or the 

business warehouse could produce reports in a more useable format. [The 

Budget Formulation module uses its own Business Warehouse environment. 

The report formats for Release .5 and 1.0 are separate from any formats 

configured for Core Finance. The issues stated in this bullet pertain only to 

Core Finance and there was no evidence given in the paragraph that users 

are having the same experience with BF.] 

• Adjustments to Center Budget Information. Enterprise personnel stated that BFM 

does not support the automated update of Center budget data resulting from

enterprise-level adjustments. Currently, when enterprise personnel make 

adjustments to budget data, the Centers must run a manual report in order to 

reconcile their records to the enterprise records. Personnel stated that it would be 

desirable if the BFM automatically adjusted Center-level budget data when 

adjustments are made at the enterprise level. Manually updating budget records is 

labor intensive and increases the risk that enterprises’ budget changes to the 

Center data will be inaccurate or incomplete. Ensuring that enterprise budget 

adjustments are automated will ensure that the following year’s budget starting 

point is accurate. [The level of the budget structure that decisions are made at 

and documented by HQ are not consistent with the level of detail that budget 

decisions are documented by the Centers. In many instances, the HQ 

decisions are at a much higher level of aggregation, and the Centers are 

insistent that they are able to implement the decisions at the Center level. 

The Release 1.0 system provides a capability to set controls that do not allow

totals to exceed when the Centers are implementing decisions from HQ. The 

budget process incorporated into the Release 1 design supports the Centers 

updating their estimates after the OMB summary submit (early September), 

to support the submission of the detailed OMB submit in October. This will 

provide a established baseline for the Centers to begin their pre-POP 

planning activities, as well as to complete development of their phasing plans 

for the upcoming fiscal year.]

16 
Appendix E 

Enterprise resource personnel were not involved from the beginning in the design of the 

BFM. In February 2002, the BFM Project Team began conducting workshops that 

included NASA personnel from each Center to aid in developing system requirements 

and design. Management at each Center determined which personnel would attend the 

requirements and design sessions. Based on our review of the workshop rosters and 

through discussions with NASA IFMP personnel, we found that primarily Center CFO 

office personnel and not enterprise resource personnel or program managers, attended the 

workshops. The IFMP Program Executive stated that although enterprise resource 

personnel were invited to all of the module’s requirements planning sessions, for the 

most part, those personnel either chose not to attend or were unable to attend. Enterprise 

resource personnel stated that they did not attend planning sessions because they believed 

that the system’s requirements had already been defined and when they did raise 

questions concerning requirements for the BFM, IFMP personnel told them that they 

would have to “live with” those requirements. [Enterprise participation in the 

definition of requirements for Release .5 and .5B was minimal because Enterprises 

view Rel .5 as a Center’s bottom up planning tool not directly relevant to their 

budgeting activities.] The BFM Project Manager stated that enterprise resource 

personnel would be involved only with the design of Release 1, and would therefore not 

have any involvement with the BFM until later in the implementation cycle. NASA 

management recently recognized that enterprise requirements needed to be established as 

soon as possible As a result, on October 27, 2003, management directed that a design 

team of enterprise resource personnel and the NASA Headquarters Director of Resources 

Management convene to help define Headquarters BFM requirements. Enterprise 

officials we interviewed stated that this exercise was beneficial and that the team

identified basic requirements for all of NASA’s enterprises. The basic requirements that 

the team identified did not, however, include the three requirements identified by 

enterprise personnel, as noted. [This is inaccurate – Phasing plans are included in 

Release .5B, Center reporting is included in both Release .5 and 1.0 and Center 

budget reconciliation is integral to the design of Release 1.0.] Furthermore, NASA 

will not know until February 2004 whether the BFM software (SAP) will actually 

support those basic requirements. The February date is less than 4 months from the 

planned full release of BFM. 

We are concerned about whether the Agency will have sufficient time to accommodate 

enterprise requirements [This should state “Headquarters” requirements. 

Requirements are not confined to just the Enterprises.] in time for the scheduled full 

implementation in May 2004. If Release 1 of the BFM is implemented without including 

all of the enterprise requirements, the Agency may be unable to obtain and provide in a 

timely manner complete and accurate data for both internal use and to NASA’s primary 

stakeholders. [At the Critical Design Review for Release 1, it was pointed out an 

initial set of 38 requirements was provided by HQ for evaluation. Four of those 

requirements were duplicated and eliminated. Of the remaining 34 requirements, 

30 are fully supported. Of the 4 that are not supported, 3 requirements relate to 

17 
Appendix E 

control and reporting of information that is not included in the .5 dataset (budgeting 

of full time permanent positions). The other requirement involves explicit 

identification of which user changed any individual piece of information. It was 

accepted by the HQ team that the security features of the SEM tool provide a 

sufficient degree of identification to be acceptable.] In addition, if the BFM software 

(SAP) cannot accommodate basic enterprise requirements, NASA’s use of the BFM 

could be delayed for another entire budget cycle, postponing further full cost-based 

budgeting. We believe that this situation could have been avoided had the appropriate 

personnel been involved in the requirements definition process at the beginning. [The 

Enterprises and Code B have now agreed on the requirements for the HQ 

component of the BFM.]

Recommendations

The IFMP Program Executive should: 

1. 

2. 

Ensure that as a top priority for any future IFMP module, integral users are 

identified and involved at the earliest stages of design and functionality 

determination. [This has been accomplished in both Release .5 and Release 1. 

Center representatives comprised the design team for Release .5, consistent 

with their role as primary users. The Enterprises and Code B comprised the 

design team for Release 1, as appropriate, given their role as primary users 

of this functionality.] 

Direct that the BFM project management works closely with NASA Headquarters 

enterprise personnel to ensure that the BFM will meet enterprise needs for 

phasing plans, internal and external (including OMB and congressional) reporting 

requirements, and adjustments to Center budget data. [This has been done as 

well.] 

Audit Issue 2. Inclusion of Key BFM Functionality in Release .5B. Five key system

requirements that were originally planned to be included in Release .5 were not in the 

release. The requirements are (1) data integrity business checks that would ensure that 

budget planners do not assign the wrong appropriation to a project, [This was evaluated 

and it was determined this data check would result in significant system 

performance degradation as well as high maintenance effort to maintain the 

appropriation to WBS element labels.] (2) full system traceability (audit trail), [The 

existing security configuration provides sufficient traceability to determine which 

user would have changed specific data. A full audit trail capability results in 

significant growth in the size of the database and performance impact.] (3) restricted 

access to embargoed budget data, [There is not a requirement for Rel .5 to restrict 

access to embargoed budget data. The requirement is that Centers can restrict 

viewing of their data in the pre-POP process to their Center only. In subsequent 

18 
Appendix E 

Agency versions, viewing outside of a Center is restricted to “released” version only 

(C999 and C000) and not works in progress. These requirements have been met in 

Rel .5.] (4) acceptable system response time, and (5) an on-line quick reference tool. 

[This is being completed and provided for Release .5.] Those five key system

requirements are critical to Center program and project staff in developing their ‘bottomup’ budget data—the primary reason that NASA needed those requirements included in 

Release .5. On October 20, 2003, we issued a memorandum to the NASA IFMP 

Executive reporting our concern that those requirements were not going to be included in 

Release .5. On October 22, 2003, the NASA IFMP Executive and the IFMP Director 

stated that because of new full-cost requirements that had been developed late in the 

Release .5 development cycle, the requirements originally planned for that release were 

deferred to an additional release—Release .5B. 

Considering the late change in planning that resulted in having key functionality delayed 

until Release .5B (scheduled for February 23, 2004), we are concerned about whether 

those requirements will in fact be included in Release .5B. Including those five key 

system requirements in Release .5B would both ensure that the final release (Release 1, 

scheduled for May 31, 2004) contains the requirements and allows ample time for 

addressing user feedback, coding required changes into the software, and testing those 

changes. 

Recommendation 

3. The IFMP Program Executive should include and fully test in BFM Release .5B 

the required data integrity business checks, full system traceability, restricted 

access to embargoed data, system response time, and an on-line quick reference 

tool functions as planned before Release .5B is implemented. 

Audit Issue 3. Maintaining The Legacy Data Warehouse Document System. The 

BFM system designed to store sensitive electronic documents pertaining to key budget 

decisions and directives—the Business Information Collector—does not have sufficient 

security safeguards to protect those documents. [This is an incorrect assumption. The 

NASA “BRIC”, which has appropriate security safeguards, will continue to be the 

repository for these documents.] The condition exists because the Business 

Information Collector does not (1) have the functionality necessary to preclude the 

unauthorized manipulation of documents, and (2) does not require use of a SecurID token 

to obtain access to the sensitive documents. [There will be system security to preclude 

unauthorized users from accessing the planning folders as the first line of security, 

and the BIC will not be used for transmitting budget guidance or large documents.]

The unauthorized manipulation of documents can be controlled through the use of 

Portable Document Files commonly referred to as .PDF files. A Portable Document File 

19 
Appendix E 

is a file format that captures all of the elements of a printed document as an electronic 

image, making it difficult to change the document. A SecurID token provides an 

additional level of security requiring the user to combine a known password with a 

number generated by the token. The electronic document warehouse (the Business 

Information Collector) cannot maintain Portable Document Files and does not require the 

use of SecurID tokens. 

As a result, in order to keep this critical budget function, the Agency has planned to 

maintain the legacy Code BR data warehouse document system—the code BR 

Information Collector (BRIC). The BRIC both supports the .PDF format and requires a 

SecurID token to access sensitive documents. Because the primary objective of the 

IFMP was to eliminate the many supporting systems that existed in the Agency, keeping 

the BRIC—which NASA personnel estimate could cost approximately $51,000 annually 

to maintain—is both counter to the IFMP goals as well as costly. 

Recommendation

4. The IFMP Program Executive should ensure before Release .5B is implemented 

that the BIC contains adequate security safeguards that protect sensitive data so 

the Agency can eliminate the legacy Code BR data document warehouse system. 

20 
Appendix F. Management’s Response Received on February 25, 2004 

Following is management’s verbatim response to Audit Issues 1 through 3, 

Recommendations 1 through 4, which we received by email on February 25, 2004. 

TO: W/Alan Lamoreaux 

FROM: AG/Program Executive Officer, Integrated Financial Management Program

SUBJECT: NASA Response to Report titled "Budget Formulation Module: OIG 

Concerns", (Assignment number A-01-061-05) 

Alan, 

Please find below NASA’s response to the subject report. This written response is 

provided in addition to our earlier comments which were e-mailed to you on February 13, 

2004. 

Recommendation 1: Ensure that as a top priority for any future IFMP module, integral 

users are identified and involved at the earliest stages of design and functionality 

determination. 

NASA concurs with this recommendation. Recognizing that this was done on the Budget 

Formulation Project. Center representatives comprised the requirements and design team

for Release .5, consistent with their role as primary users. The Enterprises and Code B 

(CFO Office) comprised the requirements design team for Release 1, as appropriate, 

given their role as primary users of this functionality. 

Nevertheless, NASA respectfully disagrees with the statement in the OIG report that 

“NASA enterprise resource personnel had little involvement until October 2003 in the 

BFM requirements definition process”. The HQ Functional Requirements definition 

process for the Budget Formulation module was started with a meeting of the Enterprise 

and Code B representatives on June 11, 2003. Afterwards, several workshops were 

subsequently held during the summer of 2003, (June 30 – July 2, July 15, August 6, 

August 13 –14 and September 3, 2003) to further define HQ requirements. Finally, a 

team of senior Enterprise resources staff from Codes M, Y, S, U, and R and Code B met 

in October 2003 to finalize the design of the HQ component of the BF Application 

Module. This team worked through mid-November, 3 days a week, to set the initial 

product requirements and design. On November 20, 2003, those were presented to the 

Agency Comptroller for “customer” approval. Enterprise resource communities were 

also represented at that meeting and were asked for approval. 

21 
Appendix F 

Recommendation 2: Direct that the BFM project management works closely with NASA 

Headquarters enterprise personnel to ensure that the BFM will meet enterprise needs for 

phasing plans, internal and external (including OMB and congressional) reporting 

requirements, and adjustments to Center budget data. 

NASA concurs with this recommendation. See response to Recommendation 1 above. 

Recommendation 3: The IFMP Program Executive should include and fully test in 

BFM Release .5B the required data integrity business checks, full system traceability, 

restricted access to embargoed data, system response time, and an on-line quick reference 

tool functions as planned before Release .5B is implemented. 

NASA partially concurs with this recommendation. An on-line quick reference tool will 

be available shortly for Release 0.5b. Regarding full system traceability (or audit trail), 

the existing security configuration was deemed to provide sufficient traceability to 

determine which user changes specific data. A full audit trail capability would result in 

significant growth to the size of the database and would have a significant negative 

performance impacts on the system. For similar reasons, the data integrity business 

check to validate WBS against an appropriation is not being included in Release 0.5b. 

This functionality was evaluated in detail and we determined that this type of data check 

would result in significant system performance degradation as well as noticeably high 

maintenance requirements in order to dynamically maintain the appropriation to WBS 

[work breakdown structure] element labels. In mid-April, the BF Project will release 

additional reports that will allow the Centers to view their data by Enterprise, Theme, and 

Appropriation. This will include an exception report to identify any WBS that has been 

planned against an incorrect appropriation. 

With respect to the recommendation to restrict access to embargoed budget, it should be 

noted that this was not a requirement identified by NASA. However, there is related 

functionality provided as part of Release 0.5. For example, Centers can restrict viewing 

of their data in the pre-POP [program operating plan] process to their Center only. In 

subsequent Agency versions, viewing outside of a Center is restricted to “released” 

version only (C999 and C000) and not work in progress. 

Finally, with respect to the recommendation to provide acceptable system response time, 

the Budget Formulation Project recognizes that certain processes performed in the system

are unacceptably slow (for example, Center G&A [general and administrative] 

allocation). The Project will continue to focus on improving performance, such as rewriting batch routines in a more efficient language and incorporating the latest updates 

from SAP. The project will also continue to communicate realistic performance 

expectations to the budget formulation user community. 

22 
Appendix F 

Recommendation 4: The IFMP Program Executive should ensure before Release .5B is 

implemented that the BIC contains adequate security safeguards that protect sensitive 

data so the Agency can eliminate the legacy Code BR data document warehouse system. 

NASA partially concurs with this recommendation. It should be noted that NASA is not 

using Release 0.5b for storing sensitive electronic documents pertaining to key budget 

decisions and directives. For the FY06 Budget Cycle (FY04 POP process), this 

document storage capability will continue to be provided by the NASA HQ BRIC 

system. Any future releases of the Budget Formulation Module, which provide budget 

guidelines, and any other decisions and directives, will have appropriate security 

safeguards which comply with Agency security policies. 

23 
Appendix G. Management’s Response Received on March 1, 2004 

Following is management’s verbatim response to Audit Issues 1 through 3, 

Recommendations 1 through 4, which we received by email on February 25, 2004. 

Following is management’s additional verbatim response to Audit Issue 3, 

Recommendations 4, which we received by email on March 1, 2004. 

The Business Information Collector (BIC) component of SAP's Strategic Enterprise 

Management (SEM) module, the software used for NASA's new Budget Formulation 

System, was not implemented in Release .5A or .5B. Use of SEM/BIC is planned to be 

used in a future update. The Budget Formulation Team is currently working with the HQ 

design team to determine how the capability should be used in Release 1.0 to support the 

availability of narrative information as it relates to numeric budget guidance. Though 

SEM/BIC excels at associating textual information, including certain document types, 

with budget numbers (in versions, layouts, WBS's), it is not architected to serve as a large 

document repository or document management system. Appending a large volume of 

documents in SEM/BIC can negatively impact performance of the system. Currently, the 

BRIC provides for the distribution of a very large volume of documents. Replicating this 

document repository within the BIC is considered not feasible. It should be noted that 

access security within SEM/BIC, though not as strong as the BRIC, is considered 

adequate for operational use. SEM/BIC provides read/write access controls to planning 

layouts and associated information. Only authorized users can read and/or alter data and 

documents. 

24 
Appendix H. Report Distribution

National Aeronautics and Space Administration Headquarters 

A/Administrator 

AA/Chief of Staff 

AD/Deputy Administrator 

AG/Program Executive Officer for Integrated Financial Management 

B/Chief Financial Officer 

B/Chief Financial Officer for Financial Management 

B/Deputy Chief Financial Officer for Resources (Comptroller) 

OJD/Management Systems Division 

NASA Centers 

ARC/D/Director, Ames Research Center 

DFRC/X/Director, Dryden Flight Research Center 

GRC/0100/Director, John. H. Glenn Research Center at Lewis Field 

GSFC/100/Director, Goddard Space Flight Center 

JPL/Director, Jet Propulsion Laboratory 

JSC/AA/Director, Lyndon B. Johnson Space Center 

KSC/AA/Director, John F. Kennedy Space Center 

LaRC/106/Acting Director, Langley Research Center 

MSFC/DA01/Director, George C. Marshall Space Flight Center 

SSC/AA00/Acting Director, John C. Stennis Space Center 

Non-NASA Federal Organizations and Individuals 

Assistant to the President for Science and Technology Policy 

Deputy Associate Director, Energy and Science Division, Office of Management and 

 Budget 

Branch Chief, Science and Space Programs Branch, Energy and Science Division, Office 

 of Management and Budget 

Managing Director, Acquisition and Sourcing Management Team, General Accounting 

 Office 

Senior Professional Assistant, Senate Subcommittee on Science, Technology, and Space 

25 
Appendix H 

Chairman and Ranking Minority Member – Congressional Committees and 

Subcommittees 

Senate Committee on Appropriations 

Senate Subcommittee on Veterans Administration, Housing and Urban Development, and 

Independent Agencies 

Senate Committee on Commerce, Science, and Transportation 

Senate Subcommittee on Science, Technology, and Space 

Senate Committee on Governmental Affairs 

House Committee on Appropriations 

House Subcommittee on Veterans Administration, Housing and Urban Development, and 

Independent Agencies 

House Committee on Government Reform

House Subcommittee on Government Efficiency and Financial Management 

House Subcommittee on Technology, Information Policy, Intergovernmental Relations, 

 and the Census 

House Committee on Science 

House Subcommittee on Space and Aeronautics, Committee on Science 

Congressional Member 

Honorable Pete Sessions, U.S. House of Representatives 

26 
Additional Copies 

To obtain additional copies of this report, contact the Assistant Inspector General for 

Auditing at (202) 358-1232, or visit www.hq.nasa.gov/office/oig/hq/issuedaudits.html.

Comments on This Report 

In order to help us improve the quality of our products, if you wish to comment on the 

quality or usefulness of this report, please send your comments to Mr. Lee T. Ball, 

Director, Quality Control Division, at Lee.T.Ball@nasa.gov, or call (757) 864-3269. 

Suggestions for Future Audits

To suggest ideas for or to request future audits, contact the Assistant Inspector General 

for Auditing. Ideas and requests can also be mailed to: 

Assistant Inspector General for Auditing 

 Code W

 NASA Headquarters 

Washington, DC 20546-0001

NASA Hotline

To report fraud, waste, abuse, or mismanagement contact the NASA Hotline at (800) 

424-9183, (800) 535-8134 (TDD), or at www.hq.nasa.gov/office/oig/hq/hotline.html#form; 

or write to the NASA Inspector General, P.O. Box 23089, L’Enfant Plaza Station, 

Washington, DC 20026. The identity of each writer and caller can be kept confidential, 

upon request, to the extent permitted by law. 

Major Contributors to This Report

Neil Ryder, Office of Audits (OA) Director, Financial Management Audits 

Karl Allen, Project Manager 

Daniel Birnbaum, Auditor 

Gene Griffith, Auditor 

27