From Innovations, a website published by Ziff-Davis Enterprise from mid-2006 to mid-2009. Reprinted by permission.

IT should embrace SaaS enthusiastically, as it can save a whole lot of headaches building prototypes that users reject.

Anyone who’s been in IT for more than a few years knows the dirty little secret of the profession: many IT projects (in fact, most of them, in my experience) fail. That’s been the story as long as I can remember. Why, after so many years, are we still so frustrated by failure?

There are three main reasons I’ve observed:

• In too many companies, IT is an island that is organizationally and even physically removed from the business it serves.
• Too many users suffer from throw-it-over-the-wall syndrome, which leads to projects that fail to match the needs that exist at delivery.
• Turnover and organizational change undermine too many projects, making them irrelevant by the time they’re delivered.

Let’s look at how you can approach each problem.

IT is an island – IT people themselves are often too willing to accept a balkanized structure that isolates them from the business. There is a bad idea for so many reasons, but the insular, often introverted nature of technical professionals lets them rationalize this situation. They don’t communicate well with the business side, so they settle for separation.

You can’t change people’s personalities, and you can’t force people to work in situations that make them uncomfortable. But you can make sure that IT project leaders have the capacity to work productively with business end-users. That means not talking down or clamming up, but rather showing tolerance, acceptance, and humor. Your project managers are ambassadors. You need to select people with strong diplomatic skills.

With the right ambassadors in place, you can afford to set the rest of your IT organization apart to some degree. The project leaders should serve as both diplomat and translator, buffering the relationship with the business side while speaking both languages fluently.

Customer accountability – The throw-it-over-the-wall problem begins with the user sponsor, and is perpetuated by gullible IT organizations. Often, the perpetrator is a senior business-side executive, a “big idea” type who conceives of a grand vision and then hands off half-baked requirements to an IT group that often doesn’t fully understand what it’s supposed to deliver. Six months later, IT comes back with a prototype, by which time either the requirements have changed, the user has moved on, or he or she has forgotten about the whole thing.

Let’s face it: no one likes creating spec documents or sitting through progress report meetings. They’re tedious and boring. But they are absolutely essential if a project is to remain on track. The CIO needs to be the bad guy here. He or she must insist upon project management discipline and review meetings at least once a quarter to make sure the project is still relevant. The CIO needs the backing of a top company executive in taking this approach. Otherwise, IT will be buffeted by constant changes in the business environment. Which leads to the final problem.

Organizational change – How many managers can you name in your organization who have been in the same job for more than two years? In many companies today, half the leadership has taken on a new assignment in that time. So why do we still start IT projects that have deliverables scheduled a year or more down the road?

The business environment is too changeable these days to permit that kind of scheduling. Projects must be componentized, with deliverables scheduled every few months. If you can’t decompose a project like that these days, it probably isn’t a very good idea in the first place.

Technology may be riding to the rescue. The rise of the so-called “software as a service” (SaaS) business – epitomized by Salesforce.com –– is enabling users to try applications before they commit to them. SaaS delivers applications over the Internet, and users can often achieve results in a matter of days. In some cases, users may find that a SaaS solution is all they need. But even if they don’t, SaaS is a heckuva way to prototype different approaches and solutions. A lot of IT organizations are approaching SaaS warily, worried that they will lose control. Instead, they should be embracing the model enthusiastically. It can save them a whole lot of headaches building prototypes that users reject.