Defense Travel System Limited - Paying the Way.

Overview

Though DTS-L is a version of the full DTS, it does have it comparative differences. Like the full version  it provides the following: Electronic travel order preparation and authorization, preparation of should cost obligation estimates, a budget module, static database of airline, hotel and rental car data, ability to print travel related forms, route and review functions, computations of final travel settlement, user training and installation assistance and user developed external financial interfaces. The differences lies in its’ inability to interface to the Department of Defense (DOD) public key infrastructure for digital signature, interface to the Official Defense Table of Distances (DTOD), Electronic Data Interchange (EDI) to Defense Accounting and Disbursing Systems (DADS), live availability of travel reservation data through the commercial Global Distribution Systems (GDS) and interface to the official DOD travel archive operated by the Defense Manpower Data Center (DMDC).

        The following are a listed to provide clarification of terms used in DTS-L:

• Routing Official:  Any individual assigned to stamp documents in a routing list.  Includes Transportation Officers, budget clerks, resource advisors, and others responsible for processing travel documents prior to approval and certification of funds (French, 2002).
• Authorizing Official (AO):  Anyone given authority to authorize / approve travel.  Authorizing Officials using DTS have a broad authority to determine when TDY/TAD is necessary to accomplish a unit’s mission, authorize travel, obligate unit travel funds, approve trip arrangements and authorize travel expenses incurred in connection with that travel. AOs play a key role in the processing of automated travel documents (French, 2002).
• Certifying Official (CO):  Anyone given authority to officially certify the availability, obligation, and disbursement of funds for authorized travel.  COs must have separate training and be appointed in writing to perform the function (French 2002).  
• Organizational Defense Travel Administrators (ODTA) are individuals that are responsible for the management of DTS-L. The term is used to describe the “committee” of functions that are necessary for a properly functioning travel system at the local level: finance / resource management, budget, transportation, travel, personnel, communications, security, etc (French 2002).

                Functionality

       System requirements that are needed to utilize the program are based on which configuration is used. The standalone version, which means the database and application will reside on a single workstation system and can be installed by the individual user.  The DTS-Limited CD-ROM contains the DTS-L standalone version software.  It also includes a Computer-Based Training (CBT) program to help users become familiar with the features and uses of DTS-Limited for document preparation and route and review procedures.  If both DTS-Limited and the CBT are loaded,  computers will need 230 MB hard disk space, 486/66DX Processor, 32MB RAM (64MB Recommended), 2 Speed CD-ROM and Windows 9.x or higher operating system (French, 2002). If the organization chooses to install the basic client/server version the following will be needed:

• Client Workstation will need 486/66DX Processor, 32MB RAM (64MB Recommended), 2 Speed CD-ROM, 230MD Hard Disc Space and Windows 9.x or higher operating system.
• Server with 50 Concurrent users MAXIMUM will need Pentium III Processor, 512 MB RAM, 2 Speed CD-ROM, 315MB Hard Disc Space, with both the Database and Application loaded on the Database Server or 115MB Hard Disc Space, with only the Database files loaded on the Server and Windows NT w/ Service Pack 5 or higher. Prior to initiating this installation the Systems Administrator must decide on one of two options, or a combination of the two, with regard to location of the database server files.  This should be predicated on server capabilities.

     Option 1: With the Client-Server installation, the database will reside on the server and the application may either reside on the same server or a separate file server.  In this mode, a workstation PC desktop icon will be installed to connect to the server.

     Option 2: The second Client-Server option places the database server files on a data server and the application on the workstations.  This option is discouraged and should only be used if server space/speed is a concern.  Each PC will need to be updated with static database updates (i.e. per diem, regulations, etc.) versus the single application in

Figure 3. Layout differences for DTS-L (French, 2002)                                        

                                                Implementation

        

        When the United States Army of Europe (USAREUR) team decided to field DTS-L, the priority was to choose a project manager, information technicians, trainers, and functional experts and begin the planning. This will depict what phases the USAREUR DTS-L project team, went through. The implementing of the system was divided into four phases, which were planning, marketing, setup and roll over. The premise of the project was to convert a major support command, which entailed about 3500 users, from a previous Travel Automated Payment System (TAPS) to DTS-L and bring another estimated 82,000 non-participants on board. The first priority was to plan for the conversion of current users. Once a definite live start-day was established, the meticulous planning was initiated. The main objective for the team was to provide quality support to each on-site activity, error-free import of site data into the, and effective and efficient use of DTA resources assigned to a site.  To obtain the objective, the following was critical information to ensure success:

• Document key information for the organizations
• Request DMDC download of personal information and DFAS download of lines of accounting
• Identify subordinate organization DTA’s, AO’s, Reviewing Officials and Certifying Officials
• Establish the Certifying Officer appointment process
• Discuss the “as-is” travel process and identify DTS document routing
• Establish organization structures for document routing lists access groups / budgets

With that as a basis for planning, the project manager needed to be cognizant of his general responsibilities, which were site setup, live process verification, start-up augmentation to the LDTA / local help desk and hand-off. In pursuant of the aforementioned, a timeline was established and milestones were identified to bring a test site up before the live conversion was done. The following depicts the timeline utilized.  

Figure 4. Actual Approved Timeline (Musgray, 2003)  

Though there were other timelines used for the conversion of previous users, the focus of this paper is to generalize what is ideally to happen to automate those organizations that are currently using the manual process. At present these timelines are being reworked due to deployment of elements.

Eight weeks prior to start-up date

        A command visit must be scheduled. Experience indicates that sometimes the lead defense travel administrator (LDTA) / POC for DTS-L at a site needs help ensuring that the site leadership is committed to the process.  Therefore, early in the process, the Project Manager should start the on-site activities with a one or two day high profile visit to the leadership to ensure there is an understanding of the process, commitment and buy-in. During this time, the team will request a DMDC download according to UIC-which provides 55 fields of personal information on every individual assigned to that UIC. Additionally to initiate DTS-Limited, commanders should identify and appoint in writing a Defense Travel Administrator (DTA) – this individual has primary responsibility for the installation or agency’s temporary duty travel program. Additionally, it is very important that marketing begins publicizing DTS-L’s arrival in the setup area and training team begins coordinating with the servicing finance battalion (where the DTS-L server resides) for training facilities.

Seven weeks prior to start-up date

          An initial site visit should be held with the ODTA and

other key personnel.  Generally what should be discussed is business rules of the organization, using a template, flowcharting the “as-is” travel document process for all types of travel, initial issue of the DMDC download of personal information to the site or request information from unit if DMDC file is not available, and an review & update the site fielding guide based on issues raised during the command visit.  Additionally, training for DTA are scheduled, help desk personnel identified and organization structure is built into DTS-L.

Six and five weeks prior to start-up date

        During this time, the LDTAs, help desk staff, and servicing      finance battalion trainers will take a thorough 5 day session on the duties, responsibilities that are inherent with their job.

Four weeks prior to start-up date

        This time is dedicated to building the organization server, training organizations database administrators (DBAs) and reviewing business processes.

Three weeks prior to start-up date

        The team will concentrate much effort on the building of a help desk to support the users at a Tier II level. This involves the continued training of help desk members, software loading and problem solving scenarios.  After this setup, the team will move on site and stay with organization until live date.

Onsite week one

        This week entails, identifying and building shells for routing and group structures, data file scrub of collect data from S1 or DMDC file. The identifying of business practices that do not conform with DOD and brigade policies is a milestone that must be completed for success. Also worksheets that assist DTA in defining groups, routing lists, organizational naming structure, identifying the hierarchy of the units and permission levels relative to their jobs are reviewed. This stage is scheduled to last two weeks, dependent on the DTA comprehension skills and other unforeseen problems.

Onsite week two and three

It is recommended that icons be loaded on client PCs. Once the software is loaded, DTA (Defense Travel Administrators) must populate the database with the following critical items within the system:

        Organizations/Sub-organizations

• Design a structure that supports the installation/agency population based on specific organizational needs and requirements (i.e. finance, administration, transportation office, information technology and security).  Smaller organizations will most likely require fewer personnel, but may need the same infrastructure as larger organizations.  
• Identify organizational structure with a logical attachment of budgets, missions, personnel, and leadership affiliation.  This procedure is a very important step in developing the DTA at an installation and deserves the attention of the entire DTA and organizational leadership.  An organizational chart is a recommended method of mapping this function.  By incorporating all sub-organizations, their missions and population into a chart, one can gain an appreciation for density of travelers and proposed workloads.  See Figure 5.

Figure 5. Hierarchal Organization Chart (French, 2002)

        Groups

• A group is generally composed of travelers who have something in common, the same project, department, or administrative support person.  Groups can exist within any level of the organizational structure, e.g. the main organization or within any sub-organization. According to TRW, it is highly recommended that DTAs create a MAIN GROUP, associated with the main organization, in which everyone is listed (French, 2002).  A Main Group will enable the DTA to access, view and edit all travelers’ information.  It will allow the DTA to move a traveler from one sub-organization to another.  Other groups are formed to allow authorized individuals access to specific travelers and possibly to act as a Government entity in creating travel requests for individuals.  A Government entity is a DOD employee designated by local command authority who will input and electronically sign trip requests and reimbursement claims.  When establishing Groups, determine the Certifying Official (CO) and the Authorizing Official (AO) for each group.  Because everyone can belong to the main group, the system allows the routing of documents to any CO or AO.  In each group of travelers, an AO should be assigned the responsibility for reviewing and approving travel.  The AO should be the individual responsible for sending the traveler on temporary duty travel, and have oversight of the travel budget. In each group of travelers, there must be a CO to certify claims for payment.  As stated above, the AO and the CO may be the same person  

        Routing List Names for each Group of Travelers

• Once DTAs have established the organizations, sub-organizations, and groups, continue building the DTS-Limited infrastructure by establishing routing lists for each group of travelers.  Document routing is designed to facilitate the electronic review of documents.  Signed documents prepared in the DTS-Limited system are automatically transmitted to another DTS-Limited user based on the Routing List.  

Traveler Information and Permission Levels for the DTA personnel, Certifying Officials (CO) and Authorizing Officials (AO)

• At this level the DTA, CO and AO are entered into the system and assigned unit, group membership, designated routing list and permissions level required for their position.

        Traveler Information for the Travelers

• In the Traveler Information fields, it is recommended that the DTA enter the following minimum information SSN, Name, Gender, Organization, Title/Rank, charge card holder, routing list.

         Conditional Routing Lists

• Conditional Routing is optional for the organization.  It can be used for routing documents (authorizations, vouchers from authorizations, and local vouchers) to select persons within the organization for Review before Approval.  For example: If all foreign travel must be reviewed by an individual outside the normal routing list, then DTAs need to include that individual in the conditional routing list.  DTAs must ensure that the reviewer is placed in the appropriate order before routing to the authorizing official, who is the final approving official.  It is strongly recommended that the organizational DTA read the DTS on-line help before establishing any conditional routing.

                Lines of Accounting

• Control of budgets will not vary drastically from the current method implemented by organizations.  What is significant in the finance arena is a requirement to set up lines of accounting accessible to the DTS-Limited software.  DTS-Limited uses the term “line of accounting,” which equates to a reformatted version of current accounts class.  The financial member of the DTA, who must be appointed in writing, will have responsibility for aligning appropriate budgets and lines of accounting with the associated sub-organizations. Once all is complete, the traveler is ready to process travel documents. As a traveler, users will be using the following GUI.

Fig 5. Traveler Interface Screen (GELCO, 2002)

Onsite week four

        This is the do or die week. Four main things are to happen during this time. Firstly, all travelers’ information is entered into the system. In the Traveler Information fields, it is recommended that the DTA enter the following minimum information social security number, name, gender, organization, title/rank, charge card holder, routing list and personal account information; ensuring information is correct. This is done a process called “transload”, which is tool that takes the traveler information from an Excel spreadsheet, via Access and converts it to usable data that is imported into DTS-L. Next, it is highly recommended to run Live Process Verification (LPV). The LPV encompasses a series of events leading up to an intensive multiple day period of creating actual documents immediately prior to D-Day (the actual start of real, "live" travel using DTS-L at the site).  The actual DTS-L software and database are used for the Live Process Verification scenarios, so caution must be exercised to ensure no actual costs are charged to participant's charge cards and all obligations are reversed at the conclusion of the Live Process Verification.  Both good and bad lines of accounting are used to test the obligation and reject process.  Actual or zero cost local vouchers are used to test the disbursing system connectivity. A scenario tracking system is established to ensure the appropriate final status of all Live Process (TRW, 2002). Its’ goal is to:

• Verify log on for have each ODTA, routing official, and AO.
• Increase the familiarity of users with live DTS-L functions
• Exercise each routing list for authorizations
• Allows the PM to observe the travel processing and work out any problematic business rules with the CTO.
• Verify selected LOAs and the site Budget Module setup.

After LPV is done, the system is made available goes live to the public or Start-Up is activated.  This is the target beginning date for the first organizations on a site to use DTS –L for actual travel.  Generally it is the two-week period after Start-Up day.  The USAREUR DTA will support the Tier II help desk.  They monitor the setup for problems; provide “over the shoulder” assistance to the LDTA/Help Desk, and record help desk calls for capture in the central Tier III data base (French, 2002).  This data capture will be used to identify training and documentation improvements. Generally, successful startup depends on the preparation of the Tier II local Helpdesk.  Personnel need to be trained and experienced.  Participation in Live Process Verification would help.  After startup, the team will out brief the organization and prepare an AAR

                                                Lessons Learned

        The implementing of DTS-L is an ongoing process with many learning curves. The lessons learned and problems incurred are listed below and span from the start to current. It depicts those problems the DTS-L team incurred and how we solved them (Musgray, 2002).

Problem: Initial problems occurred in forming of the team or          

DTA. Due to other mission requirements, it consisted of three personnel of which one was the technical expert on the previous system, a project manager who was dependent heavily on other team members for knowledge. The third member was assigned the mission to train all level users, but was extremely new to the system and the use of automation.

Solution: Command structure reevaluated team

Problem: The PM leader relied heavily on one member to coordinate events, planning was extensive that

              seemed to have no end. PM had little knowledge on what was going on and lacked initiative on what to execute and when.

Solution: New management reevaluated resources in organization, assigned 3 more members to handle marketing, database problems and help-desk support. Then made the project as very high priority.        

Problem:        Timelines were not being met and team was divided.

Solution:        Project manager was reassigned to section leader, new project manager appointed. Existing timelines were revaluated for validity and adjustments were made. PM requested daily update and focused on meeting timelines.

Problem:        Pilot test site did not provide enough timely resources to successfully test DTS-L prior to conversion

Solution:        Reassigned test site to internal assets and evaluated procedures.

 Problem:        Knowledge on functionality of previous system and DTS-L was sustained in technical expert, which was hospitalized (2 weeks) for sickness.

Solution:        Sent new members to system training facility to compensate and relied on communicating problems to hospitalized member for help

Problem:        Team lacked guidance as to what should be done at each stage of deployment.

Solution:        Requested and received on-site help from system developer team. TRW assisted in verifying status and what needed to be done.

Problem:        USAREUR travel system required unique parameter settings that were being reset back to original settings. DTA, IMO and TRW help desk were perplexed as to why. This was a critical issue that needed to be resolved before conversion and further fielding of Europe.             

Solution:        Contacted programmers to resolve issue, meanwhile team developed means to retain current settings. After talking with programmers, it was revealed that thick client loads were the problem. Removed IMOs ability to load thick clients and requested special disk that turned off function.  

Problem:        Three days after going public, help desk noticed problems in routing on documents that should have been corrected during LPV.

Solution:        DTA made immediate corrections

Problem:        USAREUR Information Management department, issued message to halt deployment of system into units due to CTO (Certificate To Operate) not on file.

Solution:        Commander and PMO set meeting with IM and received interim permission. Additionally, received buy-in from DCG (Deputy Commanding General) in writing concerning implementation.

Problem:        USAREUR elements called to deployment in support of IRAQ situation, which made implementation a low priority and support minimal or non-existent.

Solution:        DTS-L team reduced to two personnel and tasked to find units that are not involved and willing to use the system.

                                                Conclusion

        DTS-L is the current DOD travel payment system that adheres to DOD travel regulations (JFTR 2001) and will continue until the implementation of the DTS full version. As depicted, there is no absolute way to devise a team, plan a project and execute it. But, experience tells one that firstly, the project team must be well rounded with leadership, cohesiveness and technical expertise. It is well advised to have a detailed plan, assignment of duties and benchmarks established and met. Unfortunately, as with the initial stages of this project, the lack of command support will most likely prove a devastating to the success of the project. In any case, the team must be proactive and able to adjust to unforeseen problems. DTS-L will continue to move forward and with the fast past of technological advancement, it will be a success. Failure is not an option.              

                                                

                                                References

DTS. (n.d.). Retrieved October 20, 2002, from Defense Travel System Web Site:  (DTS, 2002)

Department of Defense, Per Diem, Travel and Transportation Allowance Committee (2001). Joint Travel Regulation, Department of Defense Civilian Personnel (430 ed.). Washington, D,C: Department of Defense. (JTR,2001)

Department of Defense, Per Diem, Travel and Transportation Allowance Committee (2001). Joint Federal Travel Regulation, Uniformed Service Members  (176 ed., Rev.). Washington, D.C.: Department of Defense. (JFTR, 2001)

Musgray, Jeffrey L. (2003). Implementation Problems. Daily Meetings, 18, 2.  (Musgray, 2003)

TRW. (2002). Site IPR Checklist (1st ed.) [Brochure]. Fairfax, VA: Author. (TRW, 2002)

French, D. J. (2002). On-Site Fielding Simulation Reference Material: Field Training SOP (3 ed.). Fairfax, Virginia: TRW Inc.(French, 2002)

 

GELCO (2002), Defense Travel System Limited Software Version 6.3, TRW Inc  (Gelco, 2002)

PMO. (2001, July 9). Defense Travel System Limited. Retrieved October 20, 2002, from Project Management Office Web Site:  (PMO, 2001)