10 things that scare the bejeezus out of IT pros

If long hours and failed projects terrify you, these sentences will chill you to your core.

As Halloween approaches, some may be creeped out by vampires and zombies and other minor evils. But IT workers know that just a few words can carry more horror than most ordinary souls can imagine -- with nightmarish results ranging from wasted IT resources to botched rollouts to failed projects. Presented for your approval: 10 short sentences that will truly make your blood run cold this Halloween.

REUTERS/Jaime R. Carrero

"They came in with the lowest bid!"

You'd think that after years of "lowest bidder" being used almost universally as an insult, procurement would've figured out a better way to pick vendors, but many penny-pinching CFOs can't look beyond the low sticker price to see the disastrous and expensive future looming ahead. Government agencies seem prone to this sort of thinking: Texas ran into a particular disaster when IBM severely undercut its competition in initial bidding for a massive data center outsourcing project in the late '00s.

U.S. Census Bureau, Public Information Office

"Can we add one more feature?"

If you can't stop your users from adding in new functionality requests at a defined point in the project, you're never going to be able to actually create a coherent product. So-called scope creep can result in massive cost overruns and delays, as developers have to not only add new features but change previous code and design to accommodate them. One particularly egregious example: The U.S. Census, attempting to design a bespoke handheld computer for door-to-door census takers, sent 400 new and revised requirements to the primary contractor late in the design process. The project was eventually scrapped and the 2010 Census was taken on paper the way it had always been.

"But this one has all this cool stuff!"

There's a reason vendors prefer sales meetings with high-level execs to dealing with people in the trenches: high-level execs don't have to deal with the stuff they buy on a day-to-day basis. CRM integrator Laurence Buchanan says that it's common for hopeful execs to be dazzled by a product's feature list and convinced that all their troubles will be fixed by the many bells and whistles, when they should be asking themselves about specific problems they need solved and looking for the products that address them.

"We don't have the time or money to test it."

Most developers know the benefits of a high-quality testing regime for software, but to many execs testing is just a cost and time sink. They hired great developers, they've played around with the application, it all looks fine, what more do you need? That's the attitude the Los Angeles Unified School District and Deloitte took with the new SAP-driven payroll system for teachers the latter built in 2007. The teachers' union wanted extensive testing, the district and Deloitte said it'd be too expensive -- and the results were predictably disastrous.


"It works great in the test environment, so it'll work great in the real world."

One brand of testing failure comes from assuming that the test environment itself is a perfect representation of the real world. This can cause particular problems when it comes to scale: a few dozen testers just aren't going to put the same kind of pressure on your application or website as the real-world users who'll outnumber them by a factor of a 1,000 or more. When the Beijing Olympic Committee tried to open ticket sales to China's 1.3 billion citizens, the ticketing web site crashed repeatedly, forcing Chinese Olympic-goers to sign up for a lottery for tickets.

"But we've always done it this way!"

Any big IT project involves change, and while sometimes change can be bad, it can also meet mindless resistance that adds time and difficulty to your efforts. "We've always done it this way" can often be code for "we don't know why we do it this way, but we're comfortable with it." It can also form an invisible barrier against pushing a project to its logical conclusion once its initial benefits have been realized.

"We're assigning more programmers to the project."

One of the foundation texts of managing programming projects is The Mythical Man-Month. The basic thesis, derived from author Fred Brooks's experiences at IBM in the 1960s, is that you can't just throw more bodies at a problem and expect it to go faster: 10 programmers won't finish a project faster than five programmers would, and in fact the overhead of managing more people may slow the project down. While it's obviously possible to starve a team of resources, beware the scenario where more and more people are assigned to a late project in panic.

"Documentation is just going to slow us down."

You almost certainly would rather spend your time actually writing code than documenting what the code does, but charging ahead without bothering to leave a breadcrumb trail of documentation behind you is a recipe for disaster. From the requirement documents that ensure that everyone knows what's actually going to be built to the code documentation that ensures that people know how to use what you've built long after you've gone, documentation helps your project from becoming a baffling, amorphous mess.

"IT is in charge here."

Most IT workers dream of doing their job without interference from the suits upstairs. But the reality is that if you hear someone say this, you're working on a project that doesn't necessarily have support from the company's big decision-makers, which should make you nervous. This might be OK for lower-level, day-to-day IT work, but if you're in the midst of, say, an ERP project and nobody with a "C" in their title has your back, you could find yourself putting in a lot of time and effort for something that'll have the plug pulled on it.

Pictured here, Al Haig proclaims he's in charge in the wake of Reagan's attempted assassination.

"Why are we doing this again?"

Nobody -- certainly not techies -- is immune to the pull of new toys for the sake of new toys. CRM integrator Laurence Buchanan says it's important not to put the cart before the horse -- in other words, not to pick a new tool before you've decided on a specific purpose for it. You could end up with a lot of work undone if someone on your company's board gets wind of a major purchase or project and asks what the ultimate point of it all is -- so you'd better have a good and specific answer for them.