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."
Based on that review, Swartz persuaded the university to give him the back end of the system, the operational side. But before he could put in his controls and protections, the server did go down and stayed down for a day. "They had to station policemen in all the buildings," Swartz says. "But we have 80 buildings, and there weren't enough police, so we had to station other employees to guard the buildings."
And that wasn't the end of it. Problems persisted because the user departments had kept the application development side of the system. "They upgraded the software without testing it, and that caused all kinds of outages and problems," Swartz says. "Now they are moving the application side to us as well."
In the wake of that debacle, senior university management decreed that a policy on rogue IT be developed. Among other things, it will stipulate that any application that spans more than one department must be owned by central IT, Swartz says.
The Phase Matters
John Ounjian, CIO at Blue Cross and Blue Shield of Minnesota, looks not so much at the organizational scope of an IT project as whether it's in the assessment, design or development stage. Users may conduct the assessment phase of a project, even a large and complex one, on their own. But in the later phases of a project, even a tiny one such as the installation of a single PC, IT must be involved.
"I have a higher tolerance for rogue projects in the assessment phase," Ounjian says. "IT shouldn't be so paranoid. The business area really has the accountability in terms of what needs to be done, and IT has the accountability for how it's implemented."
Geisinger Health System in Danville, Pa., has largely mitigated the risks from bootleg projects by placing IT staffers in the user departments where these projects might occur. "We have people who support laboratory systems in the same physical location as the laboratory management people. Same for radiology, same for the business office," says CIO Frank Richards.
That's a good model for a company with a lot of specialized equipment with hooks into IT, Richards says. "The business units have learned over the years that it's better to have us involved upfront, because sooner or later, they are going to want to connect whatever it is, such as a piece of radiology equipment, to the network, and they can't do that without us," he says.
Richards says a department recently wanted to buy a physician-reporting system but hadn't worked closely with central IT. "We said, 'No, no, no, we really have to go through a process here, do a needs assessment, look at the ROI and look at how it fits into your workflow.'"
Indeed, workflow turned out to be a problem. The system would have greatly reduced the time it took an examining physician to create diagnostic reports, "but they didn't have the staff to turn the rooms fast enough to get the doctor to see the next patient," Richards explains. "It was very eye-opening for them to realize that even though we don't know clinically what they do, we understand workflow and can help them translate that into what the system will and won't do."
Times Are Changing
Greg Schueman, chief technology officer at Mercury Insurance Group in Los Angeles, says the definition of rogue technology is changing, and IT departments should change with it.
"Having IT be the absolute gatekeeper and owner over everything isn't going to work in the future, because other executives are going to develop a lot of expertise in these areas," he says. "When I look at the IT of the future, it really becomes a lot more of a competency center for program management, contract management, relationship management."
For example, Schueman says, the IT shop should apply its special skills in IT contract negotiations. He says he recently delayed a project, "while the user was champing at the bit," in order to better negotiate with a vendor. "By waiting, we were able to save several hundred thousand dollars," he says.
So what should CIOs do when they discover rogue IT projects in their companies? Says Emcor's Puglisi, "Take a look at yourself and try to understand why it would happen. Perhaps they had a bad experience with your staff, or with you, or maybe they don't know about you."
|COMPUTERWORLD EXCLUSIVE SURVEY|