Gone to the dogs: Cautionary tales of IT pet projects
"Pet projects": If you're a typical tech toiler, those two words no doubt made your hair stand up on end. How often have you been assigned to labor on a project that you suspect reflects your immediate supervisor's interests or office-politics goals, but does little or nothing for the health and profits of your organization as a whole? We asked some readers to share their own horror stories in this department -- to serve as gruesome entertainment and provide cautionary examples. Note that the names and details in some of these stories have been tweaked a bit to protect the innocent -- and the guilty.
Buzzword compliance, please
A little knowledge can be a dangerous thing -- especially a little knowledge about the latest trends in IT, or just "computers" in general, because then those trends start becoming priorities for front-line workers. A civilian employee on a U.S. military base, who wants to remain anonymous, is in just such a spot. "My boss wants to do Twitter, Facebook, Flickr, YouTube -- 'all that social media stuff' -- and a blog, video, RSS, Sharepoint, 'or some other CMS' -- basically, any of the buzzwords in new communication you can think of. His resources? Me, and a budget of a few thousand dollars."
While you may be sniffing at that list -- "Pssht, everyone wants a buzzword-compliant Web 2.0 site these days" -- you probably aren't facing the same set of troubles that our anonymous correspondent is. Military networks are a quite a different animal than whatever's been cobbled together at your local startup. "What I'm up against is a completely locked-down computer network that prevents access to those sites, and a bureaucratic IT department that doesn't know how to implement VPN or WebDAV for remote access to a Web server, for example," my correspondent writes. You'd think that his manager would see the mismatch, but, as he puts it, "It's been my experience that supervisors in technical fields are promoted to get them out of the way of those who can actually implement, maintain and fix things."
Good intentions gone wrong
Sometimes even initiatives that that start off with valid business purposes can go awry, especially when the requirements haven't been worked out in enough detail and good money is thrown after bad.
An IT architect at a major midwestern university was directed by his boss to help set up a virtual dashboard that would indicate the status of the school network. When users had a problem, they'd be able to see for themselves what isn't working, or why the Internet is slow. "This will make them feel empowered and lend a sense of inclusiveness and transparency to what we do!" his boss explained. Sounds good, right?
The devil, of course, was in the details. "Reducing the entire state of a complex network down to one red-yellow-green traffic light image isn't easy," the architect explained. "Is the light red if any component is down? Or is it red only if there's a major problem, and if so how do I codify 'major problem' out of the thousands of bits of network monitoring data available to me?"
The architect approached his boss with his concerns. "Oh, don't overthink it," she said. "We just want something very simple and informative." He managed to put together a prototype; was it received well, despite his efforts to meet the requirements outlined?
It was not. "It immediately generated complaints and support issues," he says. "The network status light was often orange or yellow due to some isolated problem somewhere on the network; higher-ups complained that this gave the impression that the network was really unreliable or working badly, which was not borne out by the actual use experience. And we'd get trouble calls -- 'I can't get to my favorite site, but your network dashboard is all green. It shouldn't be green when I'm having problems.'"
The problem, as he sees it, was that "simple and friendly" remained the project watchwords despite the ill effects on project utility. And here's the real pet-project nightmare: "The director still strongly believes in the 'dashboard' concept, so the project never got canceled. However, everyone working on it has been disheartened and disgusted to the point that no one works on it anymore, and project deadlines silently come and go with no product and no discussion."
Why do bad projects happen to good people?
What's the common denominator that causes these terribly conceived projects to suck up resources? Jim Smith is CEO of Enterprise Management Group, and he spends a lot of time working with companies on reducing costs and reining in out-of-control projects. He says that such projects arise when officer-level executives aren't given constant and concrete updates on how projects are proceeding and how allocated money is being spent. As he always asks top organization leadership, "Why is it a good idea to not know what's going on?" Yet many leaders are content to leave details to subordinates, and in such an environment, middle managers can siphon off resources for their own projects or whims.
In such an environment, is it any surprise when IT workers look to their own interests or comfort? Jerrad Carlisle explains how he took advantage of one fool's errand he was sent on during his days as a tech in the Navy: "I had a boss who didn't have any idea what she was doing, so she found the most random jobs for us to do, just so she could look like she was leading. At one point, she asked me to set up an old computer she found somewhere to receive messages. But it used a dial-up connection to send and receive them, and required some sort of cords that nobody could identify. After searching for these for three days, I finally learned that the equipment necessary to operate this machine had been considered outdated for more than ten years, so finding these cords was pretty close to impossible. Needless to say, I milked it for another two weeks before I told her it couldn't be done."
Smith begins his assessment of any project by interviewing several of the lowest-level people on that project -- and in general, he says, "They're just angry. They know they're getting screwed." He then solicits suggestions from these employees as to which company projects should be killed -- and when they are, morale often improves dramatically. But management often won't listen to input on such matters from their own employees unless an expensive consultant suggests it.
Going to the dogs
Sometimes techies are assigned projects that go really far astray from their core skillset. A correspondent I'll call Angus works with a computer store where the owner's four dogs also hang out. "They're real morale boosters for all of us," Angus notes, "but I was a little miffed when I learned, upon being hired, that two of my chief responsibilities were going to be to occasionally let the dogs out to go to the bathroom, and to make sure that the critters' water bowls are always full. That's pretty reasonable, though, compared to what I heard they asked of my predecessor. The doghouse that sits in the front of our office was a piece they commissioned from him, and I dread the day they ask me to play the carpenter."
So the next time your boss wanders into your cubicle with a pet programming or IT infrastructure project in mind, count your blessings -- the "pet" part could have been quite literal.