By Brian Boyko
Editor, Network Performance Daily

I'm sure most of our readers can sympathize with the protagonist in this Daily WTF story, "Illicit Process Improvement." (Indeed, it reminded me of quite a few scenarios from my mandatory high school "computer studies" courses.) Most people who have worked in the bowels of corporate IT departments can sympathize with the situation: Lowly but technically savvy person discouraged from making minor improvements because of a major change, which is perpetually "on the way."

And it does seem that the big project is almost always either perpetually "on the way," until it's forgotten or the project's sponsors have to admit defeat, doesn't it? Indeed, Infoworld has written "On average, about 70 percent of all IT-related projects fail to meet their objectives." That's a staggeringly high number.

Certainly, IT failure rates are one of the reasons it can be so hard to explain how to get business decision makers to invest in IT. I mean, think about it. Would you invest in a business where 70% of the products failed?

This is one of the reasons that IT departments need to quantify the business gains from successful IT initiatives, in order to justify the investment the business makes in IT. And we've talked about that before, especially as it relates to quantifying the value of network performance improvements. But if it's good to quantify your successes, wouldn't it be even better to have more successes overall?

You could argue that IT is just too complicated; that there are too many pressures and personalities in the IT room, and that technology upgrades are just complex and prone to failure. I doubt it though. Sure, WAN Optimization and VoIP implementations are difficult and technical. But commercial satellite launches are technologically complex, and I'll bet you failure rate is less than 70%. Indeed, the Indian Space Research Organization is talking about a 5% launch failure rate in 10 years.

Okay, so it's a false comparison. But if the IT guys are bright people - why does everything seem to fall apart?

I think that it's because of three things.

First: Often, projects are started without a clear understanding of the company's needs, and without a clear sense of the greater goals of the project.

I don't want to get started in on a recursive loop of existential navel gazing; lord knows I've done that too many times in my lifetime. But I think that many projects are started without a clear answer to the question: "Why?" When the project is successfully completed, what will it have accomplished? Is that goal one which will ultimately benefit the business in some capacity, by reducing cost or increasing revenue? Often times, we find ourselves taking on projects without having the purpose in mind - the project itself becomes its own purpose.

Now, this instinct often serves technical people well - we approach technology as an art form, with no particular purpose needed. This is why we were putting together Linux boxes out of old computers in our freshman years of college (or high school) and learning all we could - even though it might have been more productive to stick with our PCs at that time. Technology for technology's sake.
So as we get bogged down in the technicality of things, we ignore the broader questions of why.

And while it probably means more of the dreaded "meetings" which keep us away from our servers, databases, and wires and force us to spend time in boring, dull human contact before any project begins, it's probably a good idea to establish what the ultimate purpose of the project is. If the project can no longer meet those goals, if the project is not the best way of meeting those goals, if the goals become irrelevant - then it's time to change the project to meet the new goals, not the new goals to meet the project.

Second, when the project is underway and a deadline passes, the deadline is often pushed back with no ill consequences.

Projects often limp on for years that way. Furthermore, if you know that a deadline is going to be extended, you're more likely to put those projects on the back-burner, instead of giving them more direct attention. Okay, sometimes the task is harder than anticipated, or more problems creep up than are expected - these things happen. But if you can't meet an incremental deadline for a phase of the project, then you have to ask whether you'll be able to meet the final deadline; and if not, how that impacts the key goals - will the project even meet those goals now?

In short, a missed deadline is a reason to re-evaluate the project - not a reason to re-evaluate the deadline.

Third, there's a tendency for IT planning to develop overarching, long, huge, revolutionary solutions when small fixes are the most efficient solution.

Just speaking from personal experiences, I could have just bought a TiVo instead of going through the steps required to build my own MythTV box.
In the story mentioned at the top of this article, there was a solution that marginally improved the process that was discarded, because of fear that it would interfere with a larger project that never quite materialized. The larger the project, the greater the number of things that can go wrong; and thus, incremental steps of organic improvements are often the best - if not the most sexy - of solutions.

The other extreme, of course, is to keep patching a legacy system far past its workable prime. (A good rule of thumb for when to do the whole thing over again is when you find you can't fix one thing without breaking one other.) But by and large, people often overlook simpler solutions in the pursuit of their own grand plans.

Ultimately, reducing the failure rate in IT projects comes down to the paradoxes of being able to meticulously plan a clear path and being able to recognize opportunities and improvise when they arise.

Of course, these are just my opinions, and I could be wrong. Let us know what your theories on the high failure rate of IT projects are in our comments section below. Of course, we are particularly interested in those that pertain to networking and performance management.

Also, just a quick reminder, our New Years Resolution contest ends tomorrow, January 3rd, 2008, which is your last chance to submit your Network Performance Management Resolutions for 2008 for the chance to win a Nintendo Wii, TomTom GPS system, iPod Shuffle or iPod Nano.