Verbatim

By Anne Field  |  Posted 09-01-2001 Print Email

Verbatim

Delays. Cost overruns. Fickle priorities. IT projects are too often plagued by such problems. That's the consensus of both management experts and the more than 1,000 CIOs who responded to our recent survey on the trials and tribulations of project management. "Rarely does a project in an organization come in on time and budget," says Jayson Hahn, CIO of Merrimac Industries Inc., a maker of microwave components in West Caldwell, N.J.

Case in point: A year-long materials requirements planning installation recently went live at his company, about six months behind schedule. Hahn attributes the delay to inadequate planning: No one with sophisticated project management expertise was put in charge of the effort. As a result, "nobody knew which module needed to be set up first," he says. "One day, they'd start on the manufacturing component, then they'd realize they first had to do accounting, so they'd backtrack."

Hahn, who became CIO last year, hopes to put an end to such snafus with a more disciplined approach. But the experience underscores perhaps the central issue underlying project disappointments everywhere. Says Mark Keil, an associate professor in the computer information systems department at Georgia State University in Atlanta: "If you scratch beneath the surface, most of the problems lie with management."

Flying Blind

Lack of commitment from key business units is foremost among the problems. "When there's little functional involvement, that's a sure recipe for disaster," says Andre Mendes, CIO of Pluvita Corp., a biotechnology company based in Bethesda, Md., and formerly the CIO for the Public Broadcasting Service in Alexandria, Va. When representatives from the business areas affected by a project don't fully participate in shaping it from the beginning, IT developers wind up flying blind, forced to produce a design for the project without the information they need. The result: a series of costly stops and starts as potential users belatedly provide the necessary specifications.

For John Wade, CIO of St. Luke's–Shawnee Mission Health System, an eight-hospital system in Kansas City, Mo., the big culprit is "when the user doesn't direct the process. It's almost natural that a project doesn't get done on time in those cases." He points to one project, an upgrade to a billing and receivables system, launched a year ago. "We laid out the schedule for the departments, asked if they could make the dates, and they told us they could," he says. Trouble was, the managers involved hadn't really taken the time to think through the schedule they'd been handed. The project was completed two months late.

Pressure from the top can also affect the planning process. That's what happened to David Hanighen when he was vice president for software development at a mortgage loan originator and Internet bank. (He's now the vice president of information services of the Orange County Teachers Federal Credit Union in Santa Ana, Calif.). Feeling under the gun when the firm's senior management decided to install a new treasury system, the treasury group rushed through designing the specifications for the system's three components. "It was about 40 percent under what they really needed," he says. So partway through the project, they had to go back to the drawing board—and ask for more money as well. When Hanighen left the company, the project was already seven months behind schedule.

No matter what the level of business involvement, however, size matters. The bigger the project, the more complex it becomes—and the more opportunity there is for delay. "Once you get over the 12-month time frame, the chances of being on time start to diminish," says Wade. A study done in 1999 of 500 companies by Deloitte Consulting bears that unfortunate truth out. It found that 90 percent of 90-day projects were completed on schedule, while only 50 percent of one- to two-year efforts made their deadlines.

Priority Creep

Complexity isn't the only reason longer projects get delayed. There's also the frustrating matter of priority creep. The longer the time frame, the more likely it is that other needs will crop up, forcing IT to divert resources to another project. It may be that a new government regulation requires an immediate reconfiguring of another system. Or it's time for a system upgrade. Whatever the reason, "[In long projects,] needs change. Requirements change," says Wade. "And you find you're never able to deliver the original project." Or as Bill Foulds, director of IS for Providence Healthcare Network, an acute-care hospital, psychiatric facility and long-term care hospital in Waco, Texas, puts it, "If the CEO decides something is more important, that jumps to the top-priority list."

Consider a master-patient index project Providence started four years ago, one year before Foulds came to the company. A major undertaking, it was intended as a centralized way to identify patients across the Providence network, regardless of which facility they used. But thanks to a series of interruptions—other projects that required taking some of the 13-person IT staff away from the effort—it has yet to be implemented. Recently, however, Foulds has renewed hope for completion. A new clinical information system, started two months ago, requires that the master patient index be in operation by the end of the calendar year. "Now people are buying back into the effort," he says.

That ebb and flow of management buy-in is a major contributor to priority creep. A year and a half ago, for example, Foulds began a reinstallation of a patient accounting and patient management system. But not long after, a daunting new federal regulation was passed, mandating that hospitals be reimbursed for outpatient care based on diagnostic-related groups, much like inpatient services. Meeting the government requirements meant putting in a new IT system, and it was a deadline that couldn't be missed. "Even though we had already bought the software, we had to put the other project on hold," say Foulds. Trouble was, roughly six months later, when the department was able to breathe again, many of the original managers involved in the project, including the psychiatric director of medical records and the director of nursing for long-term care, had moved to other areas of the company or left altogether. Over a three-month period, "we had to resell the new people on the project and convince them to commit resources," says Foulds. The system was eventually completed, but it took six to nine months longer than Foulds had hoped.

The moral of the story: When you're talking priorities, it's all about politics—behind-the-scenes maneuvering for resources, for making sure your needs are number one on the list, even if that means pushing aside someone else's.

The way the maneuvering is played out differs from company to company and department to department, depending on how budgets are set and how big the issue is. In some companies, if the matter is small enough, it may mean little more than sweet-talking the right developer, says David Pinkus, who was the founder and CIO of a now-defunct Scottsdale, Ariz.-based software company called Rulebase Inc., and is now an external CIO for Construction Monitoring Systems LLC in Phoenix, which sells software for construction loan disbursement monitoring. "Salespeople know how to sell. So if they want something done, they'll find the right developer and try to sell that person on the features they want," he says. "Then the developer will sneak it in."

At Providence Healthcare, on the other hand, all projects are paid for through the IT budget, which is set every year by a management steering committee composed of the CFO, COO, CIO and directors of such departments as the lab and pharmacy. All changes to that plan must be approved by the COO. "If someone wants to replace, say, a system for submitting bills and he convinces the COO, then it may get adopted," says Foulds. Such changes in a project's priorities may happen out in the open; others occur without Foulds' knowledge. About 15 months ago, for example, "senior management decided we needed to replace our accounting and reporting package, because they felt it would save a great deal of money in the long run," he says. "They didn't discuss the effect on IT at all."

One solution to the relentless retooling of priorities, suggest a number of management experts, is to revamp the way projects are funded. At some companies, for example, every project needs to be paid for by the business unit involved. At others, there's a 50-50 ownership between IT and the functional unit. "That way the business has to come up with its own justification for a project. They're the ones who have to think about its value," says Haim Mendelson, co-director of Stanford University's Center for the Study of Electronic Business and Commerce.

Another approach is to think small. Mendelson calls it "the six-month rule"—breaking projects into pieces, each with clear objectives, and each requiring no more than six months to complete. David Lago, director of development for ReturnBuy Inc., a reseller of excess inventory in Ashburn, Va., recommends going even further—breaking IT efforts into four- to eight-week chunks. "You take small steps toward a goal," he says. "Then, if priorities shift, you can still be pretty agile and it's easy to make adjustments." Recently embarking on developing a new interface for eBay Inc., ReturnBuy chose a phased-in approach. The first step, which involved implementing such basics as listing items for sale, took six weeks. The second phase, which included more advanced features such as highlighting particular items for sale and setting a minimum price, took just four weeks. Later phases, which will include such elements as listing prices simultaneously on the company Web site, have been designed to take a similar amount of time.

At Fenwick & West LLP, a Palo Alto, Calif., law firm, CTO Matt Kesner has actually declined to take on projects that will go on for more than six months. Says Kesner: "If something lasts longer than a year, I really think there is somebody who doesn't want the process to be completed."

Anne Field is a Pelham, N.Y.-based writer who covers management and business trends. Her work has appeared in a variety of business magazines and Web publications, including Business Week, Fast Company, Fsb.com and iSource. Comments on this story can be sent to editors@cioinsight.com.



 

Submit a Comment

Loading Comments...
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date