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.