Behind the Census Bureau`s Mobile SNAFU - What Went Wrong?

What Went Wrong?

In 2006, the Census Bureau contracted with wireless equipment maker Harris Corp. to get wireless handheld computers and their supporting infrastructure up and running in time for a mock census, held in May 2007. Unfortunately, the handhelds were not even close to being ready. There were a number of performance issues, such as slow and inconsistent data reporting, according to the GAO report, and the Census Bureau didn’t specify how it planned to measure the device’s performance. These problems persist to this day.

The lessons of the botched project revolve around poor communication between vendor and client, as well as underestimating the difficulty of rolling out a sometimes-balky technology at scale. The cost overrun and delays can be boiled down to three factors: poor contract estimate, poor program management and poor executive-level governance.

In April, Census Bureau Director Steve Murdock testified before Congress on this matter. He acknowledged that the bureau did not effectively convey the complexity of census operations to the contractor, and said problems arose in part because of ineffective communications—including information about IT requirements—between the bureau and Harris Corp.

“Once these detailed requirements were completely delineated, we had serious concerns about rising costs and our ability to complete a successful 2010 census if we continued developing the program as planned,” Murdock told the House Information Policy, Census and National Archives Subcommittee of the Committee on Oversight and Government Reform.

Those detailed requirements were indeed a problem. The initial contract contained roughly 600 requirements, and the bureau later added 418 more, says David Powner, GAO director of IT management issues. What happened with the Census Bureau is a case study of why federal government IT implementations often go wrong, according to Powner, who came to government service after spending years overseeing large-scale IT implementations in the private sector. (The government spends $70 billion annually on nearly 900 IT projects.)

Step one in an escalating chain of errors that went uncorrected: The contractor presented a poorly calculated estimate. Federal entities don’t require the same rigorous up-front cost estimates as their nongovernmental counterparts do.

To complicate things, that poor cost estimate was compounded by requirements creep: the tendency for clients to add more features to their wish list long after they’ve signed off on the original requirements. “Those of us who define requirements for systems know it isn’t easy, but you need a validated set of requirements up front, and government doesn’t often do that up-front work,” Powner says.

Adding to the woes was the lack of oversight of the contractor. It seems that the Census Bureau didn’t lean hard enough on Harris to provide continued implementation updates, but Murdock’s testimony doesn’t directly address such activities.