NASA Ames Travel Request System: Federal IT Project Report

Introduction and Project Background

The NASA Ames Research Center in Moffett Field, California was established on December 20, 1939 by the National Advisory Committee for Aeronautics (NACA) as an aircraft research laboratory. In 1958, the center became part of NACA's successor, the National Aeronautics and Space Administration (NASA) (Center overview, 2010). Today, the Ames Research Center is actively involved in cutting-edge technological research involving sophisticated aviation simulation programs and provides support for a number of space initiatives as well (Tsang & Vidulich, 2003). Scientists at Ames Research Center are also engaged in a wide range of expert system and human-computer interaction studies (Parasuraman & Mouloua, 1999).

Ames Research Center is one of NASA's ten field centers situated across the nation (Frankel & Bluck, 2002). The complex occupied by Ames is relatively large, consisting of a main campus area of 430 acres and hosting a number of organizations and agencies in addition to NASA (Frankel & Bluck, 2002). For instance, Moffett Field also leases space and facilities to the California Air National Guard, the Federal Emergency Management Agency, and research and technology partners including Carnegie Mellon University (Frankel & Bluck, 2002).

All told, approximately 4,500 individuals are employed at the Ames Research Center, a total that includes NASA personnel, other government employees, federal contractors, military personnel, students, and part-time workers (Frankel & Bluck, 2002). According to NASA, "With over $3.0 billion in capital equipment, 2,300 research personnel and a $600 million annual budget, Ames's economic impact is significant. Ames plays a critical role in virtually all NASA missions in support of America's space and aeronautics programs" (Center overview, 2010, para. 2). The project that forms the basis for this study involves a change initiative at Ames Research Center intended to facilitate the administration of travel documents pursuant to the terms of a contract between NASA and ABC Services, which is described further below.

The background of this project concerns a federal contractor, ABC Services ("the company"), which has been in operation since September 1993. The company provides business-driven solutions to government as well as small and medium-sized businesses (ABC Services, 2003). The company currently provides contracting services for NASA at the Johnson Space Center (JSC) in Houston as well as the Ames Research Center in Moffett Field, California, the latter being the focus of this study. Ames was established on December 20, 1939, as the second in a line of ten NASA field centers; it was originally established as an aeronautics research laboratory and became part of NASA in 1958 (Ames fact sheet, 2010). Besides its numerous theory-based research projects, the facility also has several active real-world space missions underway, including GeneSat (already placed in earth orbit), the Lunar CRater Observation and Sensing Satellite (a mission to search for water on the moon), and Kepler (a mission searching for planets in habitable zones beyond the solar system) (Ames fact sheet, 2010).

In 2008, the company was awarded a five-year financial services support contract by NASA Ames Research Center in Moffett Field, California, valued at $29 million. Pursuant to the provisions of the contract, the company is responsible for services in the following areas:

1. Resources Management;
2. Financial Management;
3. Program Analysis and Controls;
4. Business Information Services;
5. Special Financial Analysis; and
6. Central Travel Office (CTO) (NASA Press, 2008).

The Central Travel Office (CTO) is responsible for processing all travel requests from NASA Ames employees, including contractors. The provisions of ABC's contractual agreement require a 48-hour turnaround time for processing and completing all travel requests forwarded to the CTO. In recent years, the CTO has played an increasingly important role in facilitating travel for Ames Research Center NASA employees who require travel to perform their core job responsibilities (Haines & Burton, 2003).

At present, the company does not have a system in place that validates when a request is made. In addition, there is no standard format for submitting a travel request. Finally, there remains an absence of accountability for tracking a request within a given timeframe, and the company lacks the ability to accurately measure its monthly metrics to determine performance levels.

There is a clear need for this solution based on the requirements set forth in the contract awarded to ABC as well as NASA Financial Management Manual FMM 9010 (2002), Section 9011-4, which stipulates:

Where functions are contracted out which are not inherently governmental, but closely support the performance of inherently governmental functions, management shall provide an enhanced degree of oversight of contractor performance of these activities to ensure that any final action regarding these activities complies with Federal laws and policies and reflects the independent judgment of agency officials and that there is reasonable identification of contractors and their work products. (p. 3).

Other stipulations in FMM 9010 (2002) that mandate compliance by ABC include Section 9011-5, which provides: "The accounting system will provide internal controls for safeguarding assets, ensuring that bills are promptly processed for goods and services sold, promoting the accuracy and reliability of financial data, and encouraging adherence to approved policies" (p. 4). Section 9011-5 also requires documenting time of transaction preparation, stipulating that "Recorded transactions will be adequately documented so they may be traced from original documents to financial statements" (2002, p. 4). The online transaction resource under development will satisfy these requirements and provide ABC management with timely analysis of quality indicators that can help identify opportunities for improvement as well as serving as benchmarks for future comparisons.

The current objectives of the project are four-fold:

1. Provide a centralized location (via a web address) where travel preparers can initiate a travel request;
2. Process all travel requests within the designated time allowed (48-hour window);
3. Produce an accurate account of all monthly metrics; and
4. Provide NASA Ames with a summary report of all travel requests made and processed within the system.

Project Objectives

Although these objectives are relatively straightforward, a number of systems, networks, databases, and individuals are affected by the implementation of this solution, and these issues are discussed further below.

Based on the lack of a centralized and standardized method for the Ames team at the Central Travel Office in California to validate the precise date or time a travel request is initiated or processed by preparers, the solution involved developing a means to capture this historical data to provide the analysis needed to confirm performance levels according to the provisions of the contract with Ames. The envisioned solution will therefore provide the company with the ability to develop and implement a system that will automatically authenticate performance levels with regard to this monthly performance metric.

The solution requires the following software and human resources:

Project Solution and System Design

1. SQL Server;
2. Database, Software and Web Developer; and
3. Network and System Administrator.

During a design meeting held on September 14, 2010, several access options were evaluated in response to the requirement that users be able to access the system and pre-populate the Travel Request Worksheet with customer profile information. Three options were considered:

Option 1 — No Login Required: Any employee could log into the system, since the program runs in an intranet environment and no user authentication programs would be required, reducing development time. However, there would be no way to verify that the employee is actually a NASA employee, and any outside user could access the website and generate a travel request.

Option 2 — Generic Login and Password: Users would access the system using a generic password and user ID, allowing the program to recognize NASA employees and restricting access to those with the credentials. However, the system could not store personal information because it would be unable to distinguish between users, and security would be compromised if the generic credentials were exposed. Travel Request Worksheets could not be pre-populated with user profile information.

Option 3 — Full Authentication (User ID/Password Creation and User Registration): Users would access the system after initial validation and verification in a secured environment. The system would be fully secured, outsiders could not access it without proper authentication, and user profiles could be stored and pre-populated on the Travel Request Worksheet. The main drawback is the extra development effort required to create a user registration page and a user maintenance application for managing profiles and resetting passwords.

Decision: Option 3 was selected because it satisfies the requirement for storing user profiles and pre-populating the Travel Request Worksheet (TRW).

Following this decision, a number of additional project requirements were identified:

1. Users should be recognized as either work coordinators or travel preparers.
2. Any travel preparer (lead) can become a work coordinator.
3. Work coordinators can also serve as travel preparers.
4. One work coordinator should have the authority to designate another person as a work coordinator.
5. One or more travel preparers (leads) will have the ability to see all domestic, international, or other types of travel requests.
6. Each travel preparer will individually manage one or more travel codes (such as T, R, H, Q, etc.). At any time, a travel preparer can be assigned new travel codes or be removed from managing current travel codes.
7. Work coordinators should have the ability to assign a new travel request or remove an assigned travel request.
8. At any given point in time, only one person can serve as the active work coordinator.

Following an assessment of the various options available to satisfy these additional requirements, the design committee elected to adopt the following approach:

1. Creation of a user profile with a field to classify different types of users in the system — namely travelers and travel preparers.
2. Creation of an exclusive user group called the "Admin Group" to monitor and control travel requests and assignments.
3. Ability to assign the work coordinator role on an as-needed basis among users of this group.

The following associated screens were identified as requiring changes based on the original goals and new requirements:

Travel Request Screen (Impact: Medium): Any person with a Travel Preparer role can enter a new request into the system. In general, only one person will enter new requests after reviewing the CTO mailbox. Screen changes include the addition of Travel Begin Date, Travel End Date, and Travel Type as a drop-down with options: (a) Complex Travel, (b) International Travel, (c) Domestic Travel, and (d) Invitation.

Travel Preparer Screen (Impact: Severe): The travel preparer will open the travel request in non-editable mode, with a checklist based on the travel type displayed at the end of the request. The preparer can check boxes, add comments, and change the request status to In-Process or Hold. New requests will not show "Time Left" immediately upon assignment by the work coordinator, but will continue to appear on the preparer's work screen. The Travel Reference Number will function as a link or button that opens the travel request. If the preparer determines that the request meets checklist criteria, they will click the Accept button, at which point the request moves into the in-process area, the cycle time commences, and the system displays time remaining.

TRW Edit Page (Impact: Severe): Travel preparers access this screen via the edit button. Overall screen layout remains the same, but the TRW request status field will be added, and travel type based on checklist criteria will be incorporated. A separate link will display travel requests that are assigned, in process, or on hold; requests can be reassigned to any travel preparer, and the history of such assignments will be captured.

Request Transfer Page (Impact: New): A new screen will display currently active requests. Users can select one or more requests and assign them to another travel preparer. An email will be sent listing the transferred requests and their current status. There will be no change to cycle time for requests already in process.

Display List of Travelers Ending Travel (Impact: New): Travel requests will be evaluated daily against the travel end date. Requests whose travel end date matches the current system date will be listed by traveler name and sent to a pre-configured list of travel preparers, work coordinators, and other affected individuals. Alternatively, a date-range report will display travelers whose end date falls within the specified range.

Work Coordinator — Travel Request Status Report (Impact: New): Work coordinators will have access to travel request counts, request status, and time remaining for each request. A new report will display request status with remaining cycle time for each travel preparer.

Work Coordinator — Travel Request History Report (Impact: New): A new report will display travel request history with cycle times grouped by travel preparer. This report will also be accessible to travel preparers currently processing a request.