Members share methods for getting projects approved
published on February 24, 2003
There was a time in the not-so-distant past when we were all rich and stupid. IT projects would get approval based on "educated hunches," with ROI computed to justify a build vs. buy decision. But after the bubble burst and the CEOs at Enron and WorldCom got nabbed for using new math, we've all grown poorer and smarter— at least in terms of approving IT projects.
Now executive committees scrutinize projects like never before. They're willing to even shoot down pet projects if they lack the right stuff— namely, ROI and payback dates.
To battle the tougher scrutiny, CIOs need to utilize a variety of tools to get project approval, according to TechRepublic members. While some methods invoke smoke and mirrors, others use hard-core analysis, and some ensure project approval by making sure IT projects are tightly aligned to organizational priorities. Here are some of the project approval methods recently touted by TechRepublic members.
One member, Suleyman Sevinc, who wrote to us from Istanbul, Turkey, uses a bit of psychological manipulation to get project signoff. The strategist at Fonksiyonel Internet Systems uses a method that relies on a bit of salesmanship and persuasion. First he implants fear, uncertainty, and doubt regarding the status quo. Then he develops a prototype to help people envision where they're going. Finally, he shows the scale of the project based on similar projects, histories, and expenditures at the client's competitors.
"I usually get what I want, though often in a longer time frame and in smaller steps than I would want," Sevinc related.
ROI, payback dates, and other analytics
While a bit of old-fashioned persuasion might work sometimes, many CIOs now have to show harder data to get projects approved. "Today's business needs dictate that proof of a project's value be justified by more extensive decision support systems," said CIO Ken Tupman, owner of Tupman Consulting, a small IT firm in Ashburn, VA.
Tupman said that while ROI and a stipulated payback period are the most common decision support analytics, there are other venues. One is the Analytic Hierarchy Process, which provides numerical weights to different factors that might be important to a project. To use a car analogy, the Analytic Hierarchy Process attempts to analyze nonquantitative measures of preference— a red or blue paint job, or tinted glass or clear, for instance. "You usually use it when you have two alternatives that are close in cost and you want to have a tie breaker," explained Tupman.
The net present value analysis is a frequently used analysis tool that shows whether a project has a positive net value after revenues and expenses in current dollars. The analysis typically tackles a five-year period, and a company is typically satisfied if the project shows a positive value at 24 months. "Although [the executives are] looking for quicker payback now than I've seen in the past," noted Tupman.
The tricky part of these statistical analyses is getting the numbers right. So CIOs, and CFOs for that matter, should make sure that the staff can verify that the analyses and the underlying numbers are correct.
This is difficult to do, however, if an enterprise's decision makers build bias into the figures, which happened once while Tupman was on a client job. Burned by past IT projects, the executive in charge of IT decisions low-balled one analytic measure beyond the worst-case scenario, which could have killed the project. The executive computed a 5 percent completion rate— a measure used to describe the percentage of calls successfully completing tasks in a telephone voice response system— while Tupman's team estimated it at 20 to 30 percent.
In the end, Tupman's numbers won the case, but not before he had to literally go over the head of the skeptical executive to get project approval— something no one likes to do, he noted.
Aligning projects to goals
For enterprises such as Saskatchewan Health— the government department responsible for the health of the people living in the Canadian province— IT projects get approval if they're aligned with the organization's broader priorities.
With a $10 million annual budget under his steward, Phil Moleski, Saskatchewan Health's director of IT Development and Applications, spends up to four months a year building out an IT project plan— the document he uses to get projects approved for the year.
To build his project cases, this TechRepublic member runs through a litany of questions with IT contacts and department heads:
- Is the project something that the business needs?
- Can technology meet the needs of the organizational challenge?
- Should the IT solution be bought or built?
- What's the solution going to cost?
- Does it do what the organization needs it to do?
- What's the impact going to be on the organization that has to support it?
Clearly, effective communication is a must in these high-level exchanges. "The key is that we talk a lot," said Moleski. "Everything I hear I have to pass on to make sure that I'm not an information bottleneck."
At the end of the lengthy planning phase, Moleski has a formalized plan in hand to take to the Executive Management Committee, comprised of the agency's deputy minister (the equivalent of a COO) and the assistant deputy ministers. If all the projects fit with the organization's direction for the year, then everything gets approved.
"If I do this right and work closely with the rest of the departments, I have a preapproved work plan with all of the departments for the rest of the year," said Moleski.