Dealing With Rogue IT

Computerworld - CIO Joseph Puglisi says he had no idea the IT project was going on. And, he says, the Emcor Group Inc. business unit installing the ERP package had no idea it had selected a product that Puglisi had earlier reviewed and panned. "Ultimately, the project was a disaster," he says.

"It was all done under the radar," Puglisi explains. "They spent more than a year fumbling along trying to make it behave in a way that would suit their business. Finally, they did ask for corporate guidance, but they had to get on bended knee and plead for funding to displace that failed implementation effort."

It might have been otherwise at the Norwalk, Conn.-based construction and facilities management company. "Had they come to us, we would have said, 'Here are the choices that we think are contenders,' " Puglisi says. "We'd have helped them choose one, helped write the scope of work, identified consultants, identified hardware and generally played a significant advisory role."

Systems projects done without the knowledge or oversight of the IT organization, so-called rogue projects, may spring up because users see IT as a source of red tape or excessive cost. Or because they're looking for temporary or quick-and-dirty systems that they see as low-risk. Or they don't see the IT implications of what appear to be non-IT projects. Whatever the reason, rogue projects often have unintended consequences. Things can get hurt—budgets, schedules, business unit operations, careers and sometimes the corporate systems that IT does maintain.

Most IT executives admit that rogue projects go on in their companies, but there's considerable disagreement as to whether the practice should be snuffed out or facilitated. In any case, CIOs employ a wide range of strategies for dealing with these bootleg projects.

Not Enough Cops

David Swartz, CIO at George Washington University in Washington, says rogue projects aren't all bad. The danger comes, he says, when a small, isolated system grows into an enterprise application without the careful stewardship of IT.

It all started innocently enough at the school, Swartz says. An administrative department asked AT&T Corp. to develop a debit card system that students could use to buy meals and other things. IT wasn't involved. Soon someone realized that the card system could be expanded to control access to parking, and then access to buildings. "More and more user departments piled on, and it became an enterprise application," Swartz says.

At least he saw it coming. "I reviewed their procedures and controls. They had no backup, no redundancy. If the server failed, guess what—not only can you not get into the parking lot, you can't get into the building, and you can't buy food. The university shuts down."