IT Is Not the Only Guilty PartyBy Ericka Chickowski | Posted 2008-05-06 Email Print
Ever fall head over heels on a technology, a functionality or a big fat budget? We know you have, and we want to help you find the right balance between what the business needs and validating professional egos.
IT Is Not the Only Guilty Party
To IT’s credit, though, the geeks aren’t always the ones responsible for IT project lust.
“Sometimes it’s management─even at the board of directors level—that gets started on these crazy Internet initiatives and abandons their core business,” Spolsky says. “The implication is that this is the fault of the low-level developers and that the intelligent management is letting them get away with it, but sometimes it is quite the opposite case.”
Krigsman agrees. Long ago he stumbled on the phrase “fact-free planning,” which he says perfectly describes when senior management insists on an unfeasible IT project plan. This happens when business leaders dream up a project’s scope, timeframe and budget, and tell IT to have at it.
“The project leadership goes back to senior management with the news it won’t work as planned, and senior management basically says, ‘Nope, you will do it,’” Krigsman says. “So they go forward building a project, creating a project plan that's based on a fiction.”
Putting Controls in Place
To guarantee that the love IT leadership or senior business managers feel for a project is pure, McConnell recommends that organizations put a chartering process in place to ensure that they don’t get hitched to a long-term dud. He believes most organizations don’t have an effective formal project-approval process in place and that they have no structure to go back and revisit project decisions during a project’s formative stages.
“So they end up basically making the big commitments before they should, and then they don’t revisit the commitment until long after they should have done that,” McConnell says.
He believes the best businesses these days allocate a small amount of funding for new projects to enter the exploratory phase.
“The purpose of that phase is basically to address all of the uncertainties and unknowns to figure out whether the project is even a good idea or not,” McConnell says. “I think that the dynamics there are pretty predictable; that is to say that a detailed analysis of the technical side usually finds that the project is going to cost two or three times as much as people initially thought it would. I think that’s almost a given. Then, you need to have a brass-tacks discussion about if this is still good idea or not.”
Why Don’t The Bad Projects Just Die?
But what if no detailed analysis has been completed? What if a project that was once beloved is well on its way to being a shell of what project leadership hoped it would be?
Many times it is difficult to face up to the failure, and the organization ends up in a situation where it continues to drag out the project and waste more money due to a lack of courage.
“You’ll commonly see the kind of situation where the emperor has no clothes,” Asuret’s Krigsman says. “Senior management has defined a set of objectives and nobody wants to be the first to raise their hand and speak the truth.”
The difficulty is that the longer people wait to face the failure, the more difficult pulling the plug will be.
“There’s certainly is a point where I’m not sure there is even a good way to do it,” McConnell says. “If you find out bad news early, there are usually a lot of different ways to handle it, and it can be handled with a minimum of disruption and embarrassment.”
This is why it is critical to do regular assessments of all IT projects on the docket to ensure they fit business needs and are on their way to success.
“You ought to do at least an annual assessment,” MDE Enterprises’ Sisco says. “That annual assessment will tell you whether you are working on the right projects for your clients because the dynamics of the business may change. So your project focus or your project initiatives need to be somewhat dynamic or fluid and be able to adapt to that business change.”
Sisco says that when he does assessments, he must find a business owner who can substantiate that there is real business value for doing a project.
“If I can’t find that, I’m going to cancel it, even if it’s 60 percent done,” he says.
To gracefully kill a project, a manager must first meet with all the management stakeholders to get a consensus that it is a dud, Sisco says. From there, it is critical to meet with the project’s IT foot soldiers to ensure that they understand that the death of a project they have spent a great deal of time on is not necessarily an indictment of their performance, he explains.
“When I kill a project, I have to sit down with those programmers and whoever else is working on it and help them understand why we’re making the change. I tell them it has nothing to do with them, and I reinforce the value that they bring to the business and the fact that we can’t afford to spend any more of their time on something that is not providing real value to the business,” Sisco says.