Coast Guard Maritime Domain Awareness Project

 When commercial aircraft were used as lethal weapons during the terrorist attack on the Twin Towers of the World Trade Center, September 11, 2001, it served to highlight the vulnerability of the US and other Western countries to unconventional attack from the air, land or sea.

 Particularly vulnerable were the ports and waterways.  The United States Coast Guard (USCG) has estimated that 14 boats smuggling guns, drugs, or immigrants, or boasts engaged in other crimes reach the shorelines of the US every week.  When a Cuban patrol boat, armed with machine guns, and its passengers seeking asylum, landed at a Key West resort, a former commandant of the USCG was not surprised. He said it was impossible to secure the entire coastline from unauthorized boats. 

Indeed, protecting over 12,383 miles of coastline is a challenge of major proportions. While the need for increased security measures has been evident for a long time, it was the terrorist act of September 11, 2001 that prompted Congress to pass The Maritime Transportation Security Act in 2002.  Its objective was to enhance maritime security. 

In compliance with this act, the U. S. Coast Guard (USCG) embarked on a major project, the Nationwide Automatic Information System (NAIS).  “This new system would enable the USCG to identify, track, and communicate with marine vessels using the Automatic Identification Systems (AIS), a maritime digital communication system capable of transmitting and receiving vessel data over very high frequencies.”  But in addition to tracking vessels, the data collected would then be combined with other government intelligence and surveillance data to form a “holistic” view of maritime data collected within or near maritime waters.

NAIS would serve as a fully integrated information system to create the equivalent of an air traffic control system for ports and waterways.

Mr. Dana Goward, Director of the MDA project, writing in USCG’s Proceedings, describes the value of an integrated system using the following scenario.

Intelligence has designated 15 vessels off the U.S. mid-Atlantic coast as being of “high interest.”  Several are known smugglers, one had a suspected member of a terrorist organization aboard, and six are from small companies and have recently made port calls in countries that sponsor terrorist organizations. The USCG sector commander with responsibility for this area monitors these vessels through her common operational picture. It is a picture that also inclined hundreds of vessels engaged in legitimate commerce and other activities. When it appears that one of the high-interest vessels near shore has departed its expected pattern of behavior, a duty officer is automatically alerted, just as the monitoring system also concludes that the vessel is now closing in on a cruise ship several miles away.  The Coast Guard directs the cruise ship to alter course, a Harbor Police vessel already in the area is asked to investigate and a USCG boat with a full boarding party is launched. Using a combination of intelligence information and broad situation awareness, a disastrous incident is avoided.

The scope of the NAIS project was ambitious. First it would involve the collaboration of at least 15 federal agencies, second it would involve complex technology relying on long-range optical cameras, radar systems, information technology, geographic information systems, vessel identification systems (shops carry electronic systems on board that transmit data including the vessels name, origin, cargo and passengers), and a portal for sharing information with port partners. It would be a system that could identify and trace both large and small vessels form tankers to pleasure craft … even jet skis.

But access to the data would not be enough.  It would be necessary to make sense from the data in such a way that it would help law enforcement agencies and the military to make quick and effective decisions.

The size and scope of the full project was so large that it needed to be tested in one port before it could be scaled to others throughout the United States.   This first test, called Project Hawkeye, would occur in Miami-Fort Lauderdale, a major container port servicing vessels travelling to and from Latin America as well as other ports-of-call. It was a port that  included the world’s largest cruise ship facilities with as many as 18 ships tied up at piers on a single day during the peak winter season.

System Fails First Test

The test of any complex system can be expected to suffer many problems, and this first test of the MDA program was no exception.  Of course, it is the extent of the problems that is important.  Relatively minor problems are expected, but when major problems are uncovered, the ability of the project to meet its objectives is rightfully raised.

How did Hawkeye perform?  

In a December 2006 article Eric Lipton writing in the New York Times declared that the test had fallen “far short of expectations.”  The article maintained that the cameras were ineffective in tracking small boats, the radar system proved unreliable when it incorrectly identified waves as boats, the Automated Identification System used for large boats failed to meet its objectives, and the software systems, needed to make sense out of these data, had yet to be installed. While some data, they continued, were available to the Coast Guard, they were unable use it. 

When disappointments of this magnitude occur project managers need to honestly answer a series of obvious questions. Can these problems be fixed?  What will it cost? And, how long will the project be delayed?

Sometimes history helps. If the organization has a history of overcoming problems of this magnitude and then delivering a successful project, then confidence is high that these disappointment can be overcome. As a result additional budget, and delayed time lines may be justified. But when history proves otherwise, additional funding or wider scope or delayed time frames may not be justified.

Let’s consider the USCG record.

Another project called Rescue 21, considered a precursor to the Hawkeye project, also failed to deliver as promised.  Somewhat similar to a 911 emergency system, rescue 21 would be used to track ships in distress. Completion of the project was scheduled for 2006 with a budget of $250 million. The project ran into problems and new estimates raised the cost to $872 million with a completion date of 2011. Some contended that system would not be fully deployed in 35 ports until 2014. When a congressional audit was undertaken, it was concluded that that the system did not meet expectations and that even the Coast Guard initially would not be able to use it to monitor their own boats.

Returning to the Hawkeye project, there are at least three project management lessons that can be learned from this failure: complexity, organizational sharing, and legacy.

Integration projects are complex and this project was especially complex because it brought together several independent technologies from radar to Automatic Identification Systems installed all large vessels. It is complex because the data collected must not only be current but also in a format that can be used. Then the decision support software must be capable of presenting the data in dashboard format and in addition capable of  making sense from the data so that it can be used to make effective decisions.

It was also a complex project because it brought together at least 15 federal agencies, each accustomed to control over its own jurisdiction, and its own way of collecting and using data. This is the same type of complexity that occurred in the past when large organizations adopted enterprise information systems and functional areas like procurement and manufacturing found it necessary adapt to a centralized database environment. In those days the biggest challenge was overcoming the silo culture of independent units within the firm.  Hawkeye was also an integration project in which its constituents also functioned within independent silos.

When information must be collected and shared as part of a project, the risks increase significantly. And when sharing must take place between organizations the risks are even higher. This is especially true in mature bureaucratic organizations where data and information are considered sources of privilege and power; they protect organizational roles. In Lipton’s article he writes that the agencies in control of the nations waterways “act more like rivals than partners.”

While there are certainly other lessons to be gained from this failure, and while the project has since gone on to enjoy better outcomes, the lesson here is that when the scope of the project involves sharing data and information across organizational boundaries, project managers must directly address the resistance that may be encountered. Perhaps the best way to address this is to allocate time at the beginning of a project to discuss this issue with project participants, and to maintain awareness when symptoms of this problem begin to emerge. Postponing the action needed to resolve communication problems, if left to the end of a project, when the outcome of the project falls far short of expectations, may prove to be very costly.