Inside IT Project Failure: Deadly Project LustBy Ericka Chickowski | Posted 2008-05-06 Email Print
Ever fall head over heels on a technology, a functionality or a big fat budget? We know you have, and we want to help you find the right balance between what the business needs and validating professional egos.
When an organization falls in love at all costs with a technology project, things have the potential to get pretty messy—and very expensive. It happens often enough.
For whatever reason, an IT honcho or a line-of-business manager continues a dud of a project with the persistence of a bulldog holding onto a piece of meat. They just won’t unclamp their jaws, even when all signs point to symptoms of potential disaster—whether the technology isn’t going to work as designed, it won’t fit with the business after all, or it can’t be completed on time or on budget.
“It’s very common to see both IT and the line-of-business folks become enamored with a project and continue, blinded by the risks, when a third-party objective participant would say that there is failure coming down the line out there,” says Michael Krigsman, CEO of Asuret, a project-management consultancy in Brookline, Mass. “It happens all of the time.”
Granted, a colossal project failure is usually caused by more factors than simple technology lust. Often poor planning, poor communication between IT and business clients, project creep, and an overall lack of project management controls designed to jettison bad projects all contribute to the worst internal project implosions.
Take a recent failed multibillion dollar U.S. Census Bureau project. Not long after the 2000 Census, the government agency decided it would start an initiative to equip field agents for the 2010 census with handheld devices to conduct the census electronically. The powers that be at the bureau envisioned putting 600,000 of the handhelds into play throughout the country.
In 2005, the Government Accountability Office (GAO) issued a report that warned the Census Bureau of a number of problems it saw with the planned project, the Field Data Collection Automation (FDCA) program. The GAO advised the Census Bureau to:
“Define specific, measurable performance requirements for the [handheld computers] and other census-taking activities that address such important measures as productivity, cost savings, reliability, durability, and test their ability to meet those requirements in 2006.”
The Census Bureau continued blithely on with its beloved FDCA program without taking the GAO’s advice.Just this March, the GAO released a follow-up report in which it questioned the viability of the FDCA and that warned the program could cost an extra $2 billion. One of the main issues with the program was the fact that the bureau was asking for the technology to do far more than what it had initially contracted its IT team to do.
A month later, the Census Bureau confirmed the GAO’s fears by putting out a press release that stated it would have to scrap most of its plans for the handhelds and that it would likely need an additional $3 billion to add to its existing 2010 census budget of $11 billion to help it retool census operations to account for the changes before conducting the next census in just a few years.
Instead of using 600,000 handhelds for the entire census process, the bureau will use 150,000 of them at most, with no assurance that they will work as the bureau hopes. It will refrain from using them during the most time-consuming part of the process, following up with nonresponsive citizens. For that, it will revert back to the same paper system it used last time.
“Shifting our nonresponse follow-up back to Census, which has great experience using the tried-and-true paper system, will remove uncertainties and allow both Census and Harris to deliver the best Census possible and focus on what they can do best,” U.S. Secretary of Commerce Carlos M. Gutierrez said in a statement.