Review of Contract Monitoring 

in the 

Office of Information Technology 

 

OR10-01 

 

Office of Inspector Inspector General General

FEDERAL MARITIME COMMISSION 

March 2010 
FEDERAL MARITIME COMMISSION 

Office of Inspector General 

Washington, DC 20573-0001

March 4, 2010 

Office of Inspector General

TO: Ronald D. Murphy 

 Managing Director 

FROM: Adam R. Trzeciak 

 Inspector General 

SUBJECT: Review of Contract Monitoring in the Office of Information Technology 

The Office of Inspector General (OIG) completed its review of the agency’s monitoring of the 

contract for database design, build and maintenance. Our objective was not to perform a 

thorough review of the contract; rather we focused primarily on contract requirements, oversight 

and deliverables. Over three fiscal years (2007 through 2009) the agency paid the contractor 

$513,000 to build databases and applications that share and process data, provide technical 

advice and develop technical requirements, and provide system software maintenance.

1

During our fieldwork, the OIG learned that the FMC will scale down its existing contract and 

instead move forward on a new Enterprise Content Management initiative, essentially 

maintaining the data collected by previous applications, but scrapping the applications 

themselves. In light of this shift, we present best practices for moving forward with a new 

vendor rather than specific recommendations. 

Background

As part of the annual financial statement audit, the OIG reviewed several large contracts for 

compliance with regulations and performed select tests to ensure that funds were appropriately 

spent. During this review, we identified one large contract that had obligations for FY07 – FY09 

totaling approximately $750,000. 2

 Due primarily to the size relative to other procurement 

actions in FY 2009, the OIG selected the database contract for a closer review. 

Due to scope and methodology considerations, we did not attempt a thorough review of all facets 

of the contract lifecycle. Rather our focus was to assess agency monitoring of the contract and 

review deliverables to determine whether the agency received what it expected to receive and, if 

                                                           

1

   Per OIG policy and discussion with the contractor, the OIG is not identifying the contractor by name in the report. 2

   With option years, the contract was expected to total $1.35 million. 
not, identify the reasons why it did not. We focused on the agency’s activities to establish and 

maintain the contract. We did not assess the contractor’s performance. 

To collect information for this review, the OIG met with several participants involved in 

selecting, approving and monitoring the contract, to include the contracting officer, the Chief 

Information Officer (CIO), Contracting Officer’s Technical Representatives (COTR) and 

program staff who would be using the database applications to perform mission-related 

activities. We did not interview the contractor for this limited scope review, however the 

contractor was provided the opportunity to comment on the draft report. His comments are 

attached in their entirety to this memorandum. 

The FMC uses eleven customized applications to collect and process data. 3

 Some of these 

applications are inwardly facing (e.g., only accessible by FMC employees) and others are 

outwardly facing (accessible by public users for submitting their required data via online forms). 

FMC employees use the data from these applications to perform mission-related duties and 

responsibilities and, on occasion, must print and re-enter the data manually, from publicly 

submitted forms, into other applications to ensure consistency among databases. 

Because of inefficiencies resulting when databases are not integrated, the FMC entered into a 

contractual relationship with the contractor to build databases and applications that share and 

process data consistently. Advantages include the elimination of manual data entry and 

integration among different applications housing identical information, ensuring that updates 

would occur simultaneously. 

The OIG focused on the agency’s contract for the design and development of agency databases. 

However, to fully understand the requirement and deliverables, we also reviewed the predecessor 

contract for background purposes. 

On April 7, 2005, the FMC awarded a contract to assist the agency to develop a database. Prior 

to this time, the agency was running applications in Microsoft Access on individual workstations. 

For security and efficiency reasons, the agency sought to move to an enterprise platform 

environment with shared database capability among several applications. This database was to 

enhance indexing features and augment online capabilities for end users. In its proposal, the 

predecessor contractor indicated that it would perform the following functions: 

• Enhance server performance. 

o Ensure there are little or no downtime issues related to server computing. 

• Increase access to data. 

o The various applications interface (talk) with each other, thus enabling a user on 

one application to send data to another application. 

• Develop security enhancements. 

o Agencies must comply with Federal Information Security Management Act 

(FISMA) requirements on its information systems. 

                                                           

3 These applications are in various stages of development although all have been placed in production.

2
• Migrate to Structured Query Language (SQL) server 2000. 

o When all of the server applications are on the same technology, then the 

applications should be able to interface with each other. 

Based on discussions with CIO staff, the foundation for the shared database and several of the 

applications were laid, but the work was not completed. For reasons unrelated to performance, 

the predecessor contract was not renewed. Rather, a new contract was awarded on September 

29, 2007, to continue with design and development work begun by the predecessor. This 

transition was essentially seamless; the two predecessor staff, who worked on the initial contract, 

were hired by the new contractor at the contract’s inception and assigned to the FMC. 

According to the Performance Work Statement (PWS), the new contractor would provide the 

following services and products to the FMC (which are listed as requirements in the PWS): 

• Design, develop, implement, modify and manage databases. 

o Ensure that databases would be updated in order for them to be integrated with 

each other to eliminate manual processes in place. 

• Ensure accuracy and accessibility of data sources. 

o Ensure that data is accurate across databases and is accessible to multiple users 

across different applications simultaneously. 

• Plan for anticipated changes in data sources. 

o Expect that issues or changes subsequent to database integration will occur and 

processes will be in place to address them timely. 

• Develop, modify or implement new or existing database applications. 

o Be flexible to meet the FMC’s needs should any of the databases require further 

development or modifications.

• Develop database queries. 

o Provide reporting capabilities once databases have been updated based on 

queries from the user community. 

• Define and develop user interface requirements and design interfaces. 

o Ensure that interfaces between databases are defined and developed with data 

completeness, accuracy and availability in mind. 

• Prepare system flowcharts, standard operating procedures and a quality assurance 

plan. 

o Develop flow charts and diagrams once the databases have been designed to 

ensure that a roadmap of the configuration has been documented for subsequent 

modifications. 

In September 2007, the COTR responsible for overseeing the initial (predecessor) engagement, 

and development of the PWS for the requirement awarded to the new contractor, separated from 

the agency. A new COTR was assigned and remains the current COTR. 

According to Office of Information Technology (OIT) staff, the new (i.e., current) contractor 

delivered the “front end” of several applications. For example, it developed (and redeveloped) 

applications used in Consumer Affairs and Dispute Resolution Services (CADRS), the Office of 

Inspector General (OIG) and the Registered Person’s Index (RPI). As of the completion of our 

3
fieldwork, it has not yet completed development of the supporting databases that would allow 

data collected from these sources (specifically, RPI and Office of Transportation Intermediaries 

(OTI)) to be integrated and searchable for other agency applications. 

The contractor told the OIG that the OTI list uses data from RPI and Form 1. However, the OIG 

notes that data from Form 18, the online OTI application, is still entered manually almost three 

years after the electronic form was made available to the industry. According to the contractor, 

the agency failed to define how to handle the data communication between Form 18 and the RPI, 

even after discussions with program staff. 

In the fall of 2009, the FMC instructed the contractor to cease further development work and to 

focus on maintenance of the databases. The CIO felt that the two developers were being pulled 

in too many directions (development, maintenance, changes to designs, etc.) to finish the 

database. 

According to the contractor, it has a contractual obligation to deliver all of the documents 

reflected in its proposal. However, the contractor stated that it is limited by the number of work 

hours provided by FMC to complete these deliverables as FMC determines the daily priorities of 

the developers. The contractor concludes that the current team cannot produce and maintain 

code, develop documents and more at the same time. The OIG believes that the contractor raises 

a valid point – and FMC management agrees. It was spread too thin to focus on development 

work, which was where the expectations of program staff were focused. 

Findings

Since 2005, the agency has spent just over $1 million (with both contractors) to develop a fully 

integrated database. Agency needs for data to carry out its missions often cross bureau and 

office lines; hence the agency’s ability to share data among its program and enforcement staff is 

critical to meet challenges in periods of scarce resources, i.e., needing to do more with less. 

When fully functional, the database would reduce manual processes and enhance document 

processing speed and accuracy. Although the current applications utilize similar technical 

specifications (e.g. SQL – the necessary foundation for integration), there is little or no 

communication between the applications, as of the completion of our fieldwork.4

 

Recently the contractors automated the FMC OTI application. Prior to this development, the 

form was completed manually by applicants. While the intent is to download the data from the 

application form directly into a shared database, this has not yet occurred. Staff in the Bureau of 

Certification and Licensing (BCL) must manually enter information from the automated form 

into the database. On the other hand, other agency applications have been updated and their 

utility has been enhanced for users of the information. 

                                                           

4

   Subsequent to fieldwork completion, OIT informed the OIG that it planned to integrate the applications from the 

start. But it first needed to upgrade to the new SQL server, a lengthy process that was completed, according to the 

OIT Director, in October 2009. 

4
The question that we rhetorically ask is, “five years and $1 million later, is the agency where it 

expected to be at this point?” Without exception, staff expected to be further along with the 

integrated database. During our discussions, we learned of expectations of program staff for a 

finished product to assist in streamlining work processes for overburdened employees that have 

not been met. Yet in some instances, the efforts of program staff to add functionality slowed the 

development process. Further, we were given no assurances that the systems in development 

were designed to meet federal information security requirements (e.g., FISMA). 

The OIG has identified the following major contributing factors as to why this contract has yet to 

meet staff expectations: 

• Non-specific requirements and deliverables. A proper Performance Work Statement 

provides vendors with the requirements of the task and the deliverables, i.e., products 

expected of them. Our review of the PWS found unclear requirements and nonspecific 

deliverables. Program manager expectations were not met. 

• Applications were placed into production before they were fully developed and FISMA 

compliant. 

• Contractor status reports lacked specificity that would enable the COTR to recognize 

potential problems. 

• Technical design changes were made routinely to the front and back-ends of systems, 

some of which were already in production. Developers were unable to work with one 

approved design document. 

• Significant time was spent on maintenance rather than development. Systems in 

production suffered implementation issues that had to be addressed by developers, 

reducing the time they could devote to completing applications and databases. 

Each of these causes is discussed in more detail below. 

PWS Clarity 

A PWS (sometimes referred to as a Statement of Work) is a work order for the contractor. 

Besides telling the contractor what needs to be done, it enables the government to hold the 

contractor accountable for the agreed-upon payments. The onus is on the government to produce 

a clear statement with understandable deliverables. 

The OIG found that the PWS lacked specificity and clarity. It spelled out requirements in ways 

that could be interpreted differently. Many tasks could be considered complying with the PWS. 

For example, 

• Develop database queries 

o (OIG Analysis) It is very difficult to develop database queries when the PWS does 

not specifically identify or describe the number, frequency, quantity and type of 

queries. Database queries occur when a user pulls specific data from a database 

for analysis. That query can be large or small and contain a variety of attributes. 

5
• Ensure accuracy of data sources 

o (OIG Analysis) Data can come from an array of sources ranging from individual 

user input to downloads from another information system. It is hard to ensure 

accuracy when the data sources have not been described and explained. 

As a result the contractors were often treated like staff that was repeatedly given direction “on 

the go” rather than once at the outset. The contractor told the OIG that it has not received an 

initial time table or suspend date to deliver a fully integrated database. 

The contracting officer (CO) indicated to us that the initial PWS lacked deliverable specificity. 

The CO contacted the COTR to discuss but was told that OIT preferred to identify the 

deliverables in a general rather than specific fashion. The current OIT Director told the OIG that 

he believes that the deliverables should have been more specific. 

The OIG notes that problems with non-specific deliverables were brought to the agency’s 

attention beginning in March 2002, in Audit Report No. A02-01, Evaluation of Agency’s 

Procurement of the Form FMC-1 System. In the report, we noted that (t)he success or failure of 

projects are based on the development of the SOW. If the descriptions of the tasks contained in 

the SOW are deficient, the consequences could result in failure of the project; (and) receipt of 

substandard services... (p. 5). The report concluded that the Form 1 SOW lacked sufficient 

clarity which impacted performance and contract funding. A similar finding was presented in 

A07-02, Audit of Contracts for Consulting Services, where we noted that the SOW contained no 

deliverables or timeframes to hold the contractor accountable. 

Applications in Production before Completed

A previous FMC chairman made automating many of the agency’s manual systems a priority. 

While many other sister agencies had taken advantage of technology to streamline agency work 

processes, the FMC still relied heavily on manual systems. Under his leadership, the agency 

moved forward to automate work processes, including several outwardly-facing applications like 

the online license application. 

Several individuals we spoke with said that they felt rushed to push applications into production 

to meet the expectations of the former Chairman.5

 Further, it appears that federally-mandated 

security considerations were ignored when placing these systems into production. As a 

consequence, the agency is supporting applications that are not FISMA compliant. Moving 

forward, decisions on the timing of placing applications into production must be made not with 

an eye on meeting the expectations of executives but when they are ready. 

                                                           

5

   The OIG did not interview the former Chairman to discuss his knowledge of the procurement in question, 

including the timing of putting the application into production. We found nothing to suggest that the former Chair 

compelled staff to rush any applications into production. Nor do we suspect the former chair would have approved 

putting any application into production before it was fully tested and ready.

6
In its response, the contractor indicated that the contract does not require it to specifically 

produce FISMA-compliant products. Further, to fully implement interoperability, FISMA 

compliance, and document the systems, the contractor stated that more staff is needed. 

Oversight of Contractors

As part of administering this contract, the contractor submitted monthly status updates. In the 

OIG’s opinion, those status updates lacked clarity and substance, making an informed review of 

the contractor’s work difficult. Examples of the information in the status update include: 

• Complete overhaul of passport application to let authorized FMC staff administer user 

accounts (July 2009 status update) 

• Writing a complex database to filter and clean inconsistent database records (March 2009 

status update) 

• Solving ongoing bugs on Form 1 (service contract transmittal form) (February 2009 

status update) 

It was difficult for the OIG to discern what the contractors did, based on the “updates.” It would 

have been much more helpful, had the status agenda included: 

• What was the overhaul of the application? 

• What specifically was performed on the database applications? 

• Why was FMC staff not authorized originally to administer user accounts? 

• What specifically was written within the database and what were the filters? 

• Which database records were inconsistent? Why were they inconsistent? 

• What are the ongoing bugs? 

• How long have these bugs caused issues? 

Subsequent invoice approvals were made by the COTR without appropriate supporting 

documentation to support invoice totals. Had clearer status updates been written, or had the 

COTR requested a different format, those details could have been reconciled or mapped to 

specific monthly bills. Further, if fixing ongoing bugs turned into a routine work task for the 

contractors, this should have necessitated a discussion with the contractor to add staff or modify 

the contract to add funding – depending on the cause for the bugs. The supporting 

documentation should be directly linked to monthly invoices, line by line, or detail by detail. 

The contractor pointed out that its summary reports are not designed to help the COTR recognize 

potential problems. Rather, their purpose is to document the level of effort of the contract to 

help the COTR determine if he is getting what FMC is paying for in the contract. The contractor 

also responded that it could prepare status reports in whatever format the agency deemed 

necessary. 

While the COTR was in close proximity to the contractors, it is likely that he was aware of its 

work products and performance. The contractor indicated that the FMC management team, not 

the contractor, controls the developer’s (contractor’s) daily workload. However, the next 

“contributing factor” (see below) indicates, developers were spending large blocks of time 

7
modifying design due to changing requirements. These changes should have been identified on 

states reports as a way to parse development costs. In other words, the developers were spending 

large amounts of time on modifying designs and performing maintenance instead of developing 

the database. 

Changes to Applications throughout Design

System plans should be essentially complete prior to design. An occasional “tweak” is often 

necessary but generally designers work better if they have a static blueprint. The OIG was told 

by program and IT staff alike that several meetings were held to discuss database requirements. 

Once the developers began building the “front end” of some of the applications, significant 

design work continued due to changing requirements. This caused delays and reconstruction of 

work already performed; i.e., waste. 

Based on our discussions with staff, it appears that communication between the FMC program 

staff and the COTR could have been improved. Suggestions for design changes by program staff 

may not have been understood. More likely, the COTR’s attempts to accommodate program 

design changes sent a signal that such changes could be accommodated without much of a 

problem. 

One technique used by other agencies with success is the Information Technology Steering 

Committee. This committee would include both IT and program office personnel who discuss 

and approve all changes to major applications. This ensures that both IT and program offices 

recognize the level of effort and associated costs with design changes. Meetings are 

accompanied by minutes and include documentation of all agreed-upon changes. Formalized 

communication would have enabled the program offices to clearly identify expectations 

regarding those applications. Further OIT could have then managed the contractors based on the 

expected results from the program offices. In an agency the size of the FMC, an alternative to 

the “committee” is to appoint one individual that can speak for all.

The OIG cannot opine on the necessity for any “mid-course” changes. We were told by OIT that 

they resulted in delays and increased contract costs. Moving forward, it is essential that the 

parameters of the product that the agency is purchasing be finalized before development begins. 

This again emphasizes the importance of clearly defining requirements in the PWS. 

Focus on Maintenance

Although the applications have been modified and enhanced since the beginning of the contract, 

most of the work performed is to maintain the applications. After speaking with several FMC 

employees, we learned that the two full-time contractor employees spent most of their time 

fixing and responding to issues associated with the applications. One example of an ongoing 

issue has been that of encryption. The data submitted by public users is sometimes encrypted. 

The encrypted data cannot be used as part of database queries due to the state of the data 

(encrypted). 

8
Due to the wording of the PWS, the FMC had some flexibility to assign the developers where 

needed. Much of their time was spent on maintenance, without allowing them to develop, for 

example, a fully integrated Form 18. When the Form 18 “went live” in 2007, staff told the OIG 

that it expected that the back end, i.e., the database that collects the information, would, in short 

order, be functioning. But three years later, BCL staff is still manually entering information 

from forms that applicants submit over the internet. While the applicants’ process may have 

been streamlined, the agency’s has not. 

The CIO told the OIG that he recently suspended all development work on the contract and told 

the developers to focus on maintenance. This decision was made just prior to his decision to 

scrap the existing contract and database design. 

Summary

While the OIG did not perform an audit of the contract or assess contractor performance, the 

documents we reviewed and the officials we spoke with indicate, clearly, that the agency 

received less than it expected in this acquisition – for a number of reasons. As a consequence, 

the agency wasted scarce resources. The FMC will be able to keep the data already collected but 

the applications themselves will be scrapped. 

Recently the CIO concluded that the agency’s needs for database design and build can be better 

met through a commercial off the shelf (COTS) system customized to meet FMC requirements. 

The system will also be security compliant. While we recognize this was a tough decision to 

make, it appears to us to be the right decision. The agency was putting itself in a position to 

continue throwing good money after bad choices. We believe the money the agency will spend 

on the COTS system will end up being less expensive than attempting to address the many issues 

with the current piecemeal system. 

As of the end of the fiscal year 2009, the agency paid the contractor $512,624, and will continue 

to pay the contractor for maintenance through most of fiscal year 2010. 

The agency is now slated to spend over $200,000 for maintenance of its applications. 

Maintenance should be performed as needed. Many agencies contract out for maintenance and 

maintenance teams respond when needed. The fact that the FMC is supporting two contractors 

onsite for maintenance means (1) agency applications need constant attention – which is 

problematic, or (2) we are not using the developers optimally. 

Moving forward, it is important to take steps to ensure that the agency does not find itself in 

similar situations as it relies more on technological solutions to enhance its efficiency and 

effectiveness. To that end, the OIG makes the following recommendations. 

 

9
10

Recommendations

The OIG turned to best practices in government and the private sector to identify methodologies 

that have successfully been used to process IT procurement actions: 

1. Routine meetings, especially at the front end of a project, should occur between OIT and 

the end-users as frequently as needed concerning expectations. These expectations should 

then be documented in the PWS and contractors should work towards ensuring that the 

end-users receive an end product that was negotiated for and expected with regards to the 

contract.

2. The Performance Work Statement should be based on user requirements. The PWS 

should be clear, concise, measurable and attainable so that contractors can be evaluated 

against concrete terms.

3. At the outset, identify one individual who will have decision-making authority across 

organizations and who will be accountable for the interests of everyone involved in the 

project. 

4. All status updates submitted by contractors should be signed off by the COTR and 

reconciled against the expectations documented in the PWS. 
Comments to the Final Report

The OIG prepared two draft reports and the final report. Each report was provided to the 

contractor for review and comment. Prior to the issuance of the final report, the 

contractor requested that its comments on each version be attached to the final report in 

their entirety. Per discussion with the contractor, we have redacted the name of the 

contractor in all responses, as the report is not an evaluation of the contractor’s 

performance but of the FMC’s monitoring of the contract. 

The OIG also provided the Office of Information Technology the opportunity to 

comment on the draft and final reports. Although several discussions were held with the 

CIO and his staff, management chose not to provide written comments for inclusion in 

the final report. 
 “ is an 8a, Service Disabled Veteran Owned, Hubzone, and SDB Information Technology Solutions Provider” 

January 25, 2010 

To: Adam R. Trzeciak 

 Inspector General 

 Federal Maritime Commission 

 800 N. Capitol Street, Room 1054 

 Washington DC 20573 

 

Subject: Comments to FMC OIG Audit Report. 

Listed below is more information that may be helpful to your audit. Feel free to call me if you 

need more detail or clarification on any of the information in my comments. 

1. As of January 25, 2010, does not have any Request for Deviation, 

Waiver, or Cure Notices or Show Cause Letters, or termination notices on the FMC 

contract. 

2. on-site staff personnel are technical personnel with limited managerial 

responsibility. They are not part of management team with oversight of 

the FMC contract. These employees are not authorized to make any official statements 

that may negatively impact the contract. In accordance with my contract with FMC all 

official communication or requests for information must go through the Contracting 

Officer Technical Representative (Jim Wood) or Contracting Officer (William Alan 

Dotson). The developers on site do not have total knowledge of the FMC contract. In 

fact, only has authorization to answer any official requests for information 

about FMC contract. Please consider this when finalizing your audit 

report. 

3. On August 16, 2007, developed a Quality Assurance plan with the 

technical proposal to FMC. The plan is used today by to monitor the 

quality of work products and other factors on the contract. There are no outstanding 

issues, problems or complaints. Since, 2007, I have only receive two verbal complaints 

from Jim Wood and both were resolved within 24 hours. I repeat, as of today, 

 does not have any Request for Deviation, Waiver, or Cure Notices or Show 

Cause Letters, or termination notices. 

4. The following is not a true statement from the audit report, “However, it did not complete 

development of the supporting databases that would allow data collected from these 

sources to be integrated and searchable for other agency applications.” 

The following statements explain why the above statement is not true. Any of these 

applications can use data from any of the database in the agency. All the back end 

database structures are developed and they are available for any of the systems who need 

them. Furthermore, here are a few more points: 

a) – didn’t only develop a “front end” application but also developed all the back 

end databases and table relations and as of now maintains 15 databases with 

around 300 tables. 
b) – CADERS and OIG are standalone applications that help end users to file and follow 

up complaints. None of the other agencies’ systems need data from those systems, and if 

they need, it is available. 

c) – RPI application was a database maintained in Dbase in one flat file. Now the data is 

cleaned, the tables were normalized and migrated to SQL server 2005. Users of RPI can 

search from all RPI tables and all the table fields via custom made query builder. Users 

can build their own query and get the results on the grid, and users also have the option to 

download the result with Access or Excel file for further data analysis. 

d) – the OTI list uses data from RPI and Form1 and that is how it is built to work now. 

Using SQL Business Intelligent Development and SSIS the OTI list is automated to use 

data from the two different tables (RPI and Form1). The database and table structure we 

maintain allow any system to customize and use data from any of the agencies databases. 

5. Since there was no documentation received from the we 

have developed several internal flowcharting diagrams that are used to help with problem 

solving. 

In May 2008, developed and delivered the following documentation to 

FMC. The documents were not returned for any reason for revision, therefore they were 

by default determined to be acceptable. 

a. FMC Technical Design Document (Form 78 and 83). 

b. Business Rules and Program Specifications for Form FMC-78 (data dictionary) 

c. FMC Form 18 User Guide 

d. Six Database Schemes 

6. does not provide daily operational control over the on-site developers. 

The FMC management team controls the developers’ daily workload. This work 

agreement allows the CIO great flexible to easily change the direction of the contract at 

anytime. management team provides contractual, administrative, and 

limited quality assurance oversight. 

7. FMC has a very complex Information Management System that consider of 13 databases 

and application. It is not a simple task to convert flat file to integrated file and 

standalone application to online application that share data. True interoperability requires 

a lot of intelligence of the men and women to make it happen. We are a lot closer then 

we were in 2007. 

Please take into consideration that the on-site developers work very hard every day to 

maintaining a production system and complete development assignments at the same 

time. 

To fully implement interoperability, FISMA complaint, and document the systems more 

staff is needed. Hence, submitted an unsolicited proposal to FMC on 

November 5, 2008 to increase the staff temporarily to help increase productivity. 

8. The Summary Reports are not designed to help the COTR “recognize 

potential problems.” The purpose of the Monthly Summary Report is to document the 

level of effort of the contract, to help COTR determine if he is getting what FMC is 

paying for in this contract. is prepared to make any adjustments to the 

report as need. However, the instructions must come from either the COTR or CO. 

 understands that FMC’s Quality 

Assurance Surveillance Plan is used to monitor the contract. Since 2007, I have 

conducted quarterly reviews of the progress of the contract with Mr. Jim Wood. And, I 

repeat for a third time; as of today, does not have any Request for 

Deviation, Waiver, or Cure Notices or Show Cause Letters, or termination notices. 
9. If any application was “rushed into production” it was authorized by FMC not 

. The FMC program management team determines when an application is 

placed into productions. This contract does not requirement to 

specifically produce any products that are FISMA compliant. However, the two 

developers will follow the instructions of the FMC project management team while 

developing applications and databases. If, FMC wishes to amendment the contract to 

allow to officially provide the FISMA direction, we are ready to assign 

the appropriate security specialist with that skill set. However, has 

developed an online application that provides a single password to access all applications. 

10. Here are few more facts about what has done since 2007: 

This report was prepared by . If there are any questions please call me directly at 

. 

CEO, 

Email: -com, web site: www.c .com 
 

 

An Information Technology Solutions Provider

February, 4, 2010 

Adam R. Trzeciak 

Inspector General 

Federal Maritime Commission 

800 N. Capitol Street, Room 1054 

Washington DC 20573 

Subject: Comments to Mr. Trzeciak Audit Report. 

 has a contractual obligation to delivery all of the documents reflected in 

our bid. However, we are limited by the number of work hours provided by FMC to 

complete these deliverables. FMC determines the daily priorities of the developers. 

 developers follow FMC’s procedures and processes in the performance 

of their daily duties. FMC does not use/follow the standard Software/System 

Development Life Cycle (SDLC) process. 

FMC does not have the standard Development, Testing and Production system 

environments. Because these three platforms are not available the developers have to 

ensure all development code is error free as much as possible. Because they are subject 

matter expert this gives them the ability to provide a high degree of accuracy. The two 

 developers are expert with years of experience and are highly educated 

and knowledgeable in their field of expertise. 

At Project initiation, the developers meet with the customer, who has the requirement and 

the FMC Program Management Team to identify key items (screen captures, database 

structures, and etc) needed to develop the plan of execution. The developers are given the 

plan of execution via email from FMC Program Management Team. The document may 

contain all of the information needed to initiate a project. Then the developers will create 

system flowchart if needed that will be used to help them understand the problems. If 

needed, the developers will also interview the customer to collect more information. 

Furthermore, has developed User Guides for Form 18 and RPI. And, 

Form 18 is available today, online for the customers. received 

document routine maintenance procedures via email from FMC Program Management 

Team. We then execute the routine maintenance in accordance with those instructions. 

All the tables inside the 15 databases are normalized and they are relational databases. 

Six of the databases have database schemas and we are currently working on the 

documenting remaining nine databases. 
FMC does not have a Configuration Management Board and have not requested any 

configuration management documents. 

 is prepared to complete any documentation that is requested and in 

accordance with the contract. In addition, requested that FMC Program 

Management Team set aside hours to complete the some documents. In 2009, I met with 

FMC Management Team to set aside 10 hours a month to help with documentation. 

However, we were not able to obtain an implementation scheduled; so that those 10 hours 

would be used to work on specifics documents. 

The team is ready to complete any contractual deliverables but the FMC Program 

Management Team will have to make it a priority. The current team cannot produce and 

maintain code, develop documents, and more at the same time. 

If one of FMC’s goals is to follow the standard SDLC then more staff is needed to meet 

the demand of documenting the process. In January 2010, I met with the COTR about 

this subject and he informed me that they may be planning to strength the 

team so that we are able to implement more features/functions of the SDLC 

process. 

If you have any questions please let me know. 

Thanks, 

www .com

SBA 8(a), SDB, SDVOB, HubZone, and VIP

Office: Direct Line: Fax: 

Email: web site: 
 Final Comments March 1, 2010 

 Final Comments 

Dated: March 1, 2010 

Prepared by CEO 

 is a service disabled veteran owned Information Technology Company with 

excellent qualification in software development. We are currently implementing industry best 

practices in our development and maintenance efforts under that direction of the Government. 

Throughout the two years and three months we have been on this contract we have made several 

recommendations for improving the systems. Some of those recommendations have already 

been implemented. 

Now, my final comments about OIG Audit findings; 

Since this is a review of contract at FMC, hence the title of the review, “OIG 

Review of ”. I need your help, if you are willing please consider limiting the review to 

 contract performance period. I am not responsible for anything that occurred 

before October 1, 2007 and for the work that was completed by . should not be part of this 

review. Your statement, “Since 2005, the agency has spent just over $1 million (with and 

) to develop a fully integrated database” and “five years and $1 million later” are not true 

when reviewing contract. 

 has been on the FMC contract for two years and three months. 

 did not start until Oct 1, 2007. The process of integrating all of the applications and 

databases without an enterprise architecture design is very difficult, costly, and will take longer 

than 2 years and 3 month. Also, did not receive an initial time table or 

suspend date to deliver a fully integrated database from the Government. 

Also your comment that the agency paid $513,000 to build databases and application” is 

not totally accurate. FMC paid to do a lot more than build database and 

application. We provided technical advice, collected technical requirements, designed, 

developed, tested, documented, integrated, implemented database and application, and provided 

system software maintenance. We do a lot more than “build databases and application” for 

$513,000. 

 is not spread too thin to focus on development work. Our two developers are 

experts and are available to focus on any work assignments given to them by the FMC 

Management Team. The team for two years has developed databases and application, provided 

some documentation, and maintained all of databases and applications at the same time. The 

Government determines the allocation of man-hours. 

1
 Final Comments March 1, 2010 

This summary shows software development life cycle at FMC. The agency as of now doesn’t 

even have a separate development, testing and production environment. does 

everything on a single computer and goes live to production without a proper testing 

environment. Most maintenance, upgrade and changes happen on the live application and live 

data which involves a tremendous amount of risk. has been adjusting itself 

within the environment to provide the solution the agency needs upon request on timely manner. 

Life cycle Key task % of the total 

project life cycle 

Analysis and Design ‐ understanding user requirement 

‐ meetings, document review 

‐ prototyping proposed solution 

‐ designing database schema 

‐ Designing user interface 

20% 

Coding & 

Development 

‐ Code generation 

‐ Database development 

‐ Report generation 

‐ Query building 

‐ Data/file encryption 

‐ Stored procedures 

‐ SSIS packages 

‐ Web services 

‐ Script writing 

50% 

Testing 

Deploying 

Documentation 

‐ Unit and system level testing 

‐ Security testing 

‐ Accessibility testing 

‐ Configuration and deployment 

‐ User manual 

‐ Database schema documentation 

15% 

Integration and 

Maintenance 

‐ System maintenance, scope redefine 

‐ Upgrades 

‐ Additional functions 

‐ User support 

‐ Indentifying and recommending 

integration requirements 

‐ Database maintenance 

‐ Handling on demand requests 

15% 

On page 5, the following is not a fair statement, “We were given no assurances that the systems 

in development were designed to meet Federal information security requirements (e.g., 

2
 Final Comments March 1, 2010 

FISMA).” FMC has not completed an assessment of the production systems. Without an 

assessment report it is impossible to determine what has or has not been developed to meet 

FISMA compliance. FMC’s System Security Officer (SSO) or Information SSO (ISSO is 

responsible for implementing and assessing FISMA compliance. The comments I made earlier 

about development effort for FISMA compliance requiring a FISMA 

specialist was in response to FMC not having the resources to provide the required skill set. 

On page 6, “Ensure accuracy of data source”; your answer to this bullet comment does not 

correctly address the task. is not responsible for individual users inputting data 

into the “array of sources”. What does through our design and development of 

data entry screens is to help reduce data entry errors (ensure accuracy) by implementing input 

masking techniques to help guide the individual to help ensure accuracy of the inputted data, 

hence, helping to “ensure accuracy of data source.” 

On page 7, “Oversight of Contractors” 

All of the Status Reports submitted to the Government have been accepted. The COTR is part of 

the FMC Management Team that oversees the two developers’ day-to-day assignments, 

determines the priority of the two developers, and oversees the FMC Project Manager for all 

FMC systems. Therefore, the COTR is fully aware of what has been achieved in any given time 

period on the contract. However, more detail about each task may be needed for outsiders, but 

 Status Report would not be the only input to brief the outsiders. For example, 

as you the “Auditor” read this report can easily come to the conclusion that the Status Report 

needs more information because it is not a full detailed report. However, if you wish to receive 

details on any task the COTR will be able to provide the detailed information using the Status 

Report as one of his sources. The Status Report is a summary document. The COTR will have 

the answers to these questions on page 7 not a Contract’s Status Report. However, it is a 

deliverable of our capabilities of providing the answers to some of these questions on page 7. 

On page 9, “Another issue is that of outages”. “In one instance, at least one server (SRVCON) 

was inoperable for three working days. Please if you are willing, consider removing this 

statement because is not contracted to maintain the hardware. 

The following comments are in response to comments made on page 4. 

Every IT project has scope definition when they are initiated. When received the RPI 

project, the requirements were to convert the existing database application to the most current 

web technology and SQL server. Besides addressing this requirement has been working 

forward on the system to allow users to run dozens of static and dynamic reports, allow users to 

download a number of databases and tables via access and excel format and allow users to build 

their own search query and search all existing RPI database tables to satisfy the ever growing 

3
 Final Comments March 1, 2010 

user need. developed RPI front-end and back-end application including data cleanups 

and data migration support from the old database technology to the new SQL server 

environment, user accesses and permission management and many more functionalities are part 

of RPI. RPI maintain its own database and the application helps users to enter, edit, download, 

search and run reports from the database. 

When Form18 was initiated, the requirement to download the data from the online application 

into the database was achieved day one. Form18 maintained its own database and its own table 

structure. All online OTI applications (Form18) were directly collected from Form18 database 

and all attached supporting documents and application data are organized and stored in the 

normalized SQL server database which allows the agency to extract, run queries and search the 

records. No one retype online submitted Form18 application into Form18 database. But why is 

the application submitted to Form18 not showing up in RPI database? 

RPI & Form18 come to the project queue as separate stand alone applications. identified 

the relationship between not only the two applications but with Form1 and ServCon as well. 

 recommended having Enterprise level Architecture design throughout the agency and 

possibly having a Master Database rather than duplicating records from one application to the 

other. This will give the agency the opportunity to have a centralized shared architecture with 

clearly stated business rules. Even to this day, in our meeting with BCL and Momentum, BCL 

didn’t clearly define how to handle the data communication between Form18 and RPI. It is not 

yet clear how to assign organization numbers in RPI (since all organizations need a number in 

RPI) when there is change of organizational structure, when the organization is sold, or absorbed 

fully or partially by another company. Without defining the basic requirements for each scenario, 

it would be hard to satisfy all the needs. 

As a prototype developed Passport databases that managed user profile and user accounts 

to allow all online users to use one user account for all FMC online applications. As of now 

form18, Form1, and ServCon share the same data from passport databases to authenticate their 

users. Previously every application maintains their own account, which creates inconstancy by 

insisting users have three different account profiles for each application. 

4
 Final Comments March 1, 2010 

Bellow is the overall database diagramed I showed on our meeting with OIT in 2007 to 

recommend data synchronization.