Reference no: EM131049428

CASE

Everyone at The Queen's Medical Center in Honolulu wants some shiny new piece of technology. Doctors and nurses who have seen a new pharmacy management system demonstrated at a recent conference think the hospital should have it. An administrator wants his department to have PDAs for wireless access to e-mail. Someone else wants a hospital wide dietary management system but doesn't have the budget to fund it. All of these people want CIO and vice president of IT Ken Kudla to get it all for them. Yet before he even thinks about eking new systems out of his $13 million annual operating budget, Kudla has to contend with the 30 projects he has going on right now. He's in the middle of upgrading the hospital's network and deploying an anti-spam management system. He's due to replace the seven different systems that make up his hospital information system. Meanwhile, he's trying to finish a document imaging project begun back in 2002, for which funding has been scarce. "CIOs are being bombarded," he says. "There's a pent-up demand for things." Kudla isn't alone. According to "The State of the CIO 2006," an annual survey by CIO Magazine, demand for IT is back with a vengeance. It's almost like the late 1990s, except that what's missing now is the money, staff, and late-night takeout to deal with today's demand. In turn, the requests for IT projects are piling up. CIOs say that managing this application backlog is the number-one barrier to their job effectiveness today, regardless of industry or company size.

How CIOs manage this burgeoning demand has a direct impact on whether or not business leaders view IT as responsive to their needs. "Any CIO who sets an expectation that something will get done-and it doesn't-will be committing career suicide," says Bob Holstein, CIO at National Public Radio. The challenge for CIOs, then, is to ensure that projects already in the queue are aligned with ever changing business priorities, to manage business-side expectations, and to control new sources of application demand from today's more sophisticated users. "One way you can interpret this problem is that users have a lot more appreciation of what's possible," says Holstein, "Or that the technology world has moved very quickly, and those business units want more, and they want it faster." Whatever the source of the application backlog, CIOs should follow this cardinal rule. Don't complain; nobody- especially your CEO-likes a whiner. "I tell my staff, ‘You can't be a victim,' " says Susan Powers, CIO of World span. "I don't accept the victim mentality." To some extent, backlogs have always been around because users have always cried for the latest applications. Ten years ago, during the Internet build out, everyone got what they wanted. Then Y2K put the brakes on many less-critical projects. "Perhaps that started some of the backlog," Kudla says. Then came the dot.com bust, 9/11, and bad times for many companies. Still, application demand remained. There may have been less development during the years when companies were focused on survival and keeping costs down, but users "still had their wish lists," says Stephen Rood, CIO of Strategic Technology.

an IT consulting firm that advises small and midsize companies. Now, those needs are out in the open again, fueling CIOs' concerns about project backlogs. How one defines and deals with any backlog boils down to two factors: the source of the demand and the project's stage of development. Holstein identifies two different types of backlogs: a backlog of desire (applications that users are yearning for) and a backlog of commitment (projects that are approved but not started). CIOs need to pay attention to both. If internal customers can't get an IT project on a CIO's radar screen, "they perceive there's a backlog because the IT shop can't do what they want,. Holstein says. When projects have been promised but not delivered, he says, "expectations have been set and not fulfilled." It may be that an IT organization hasn't planned properly, or that managers aren't tracking projects well, or that developers are taking time to assess the ins and outs of a project. Whatever the reason, users have not gotten what they were promised. One way to look at the backlog is to consider the whole spectrum of projects that IT is currently working on but has not finished, in addition to the ones ready to go. Powers has a list of 100 projects at World span that have funding and that IT has started. Outside the top 100 are projects that are on deck. "When you finish [project] three, you bring in [project] 101," she explains. If she doesn't have the right staff with the right skills available for the next project on the list, she may skip to another. "We tend to have a backlog of about one year's worth of work. But because we prioritize every two weeks, some items never make it to the active list," Powers says. No matter how good CIOs are at keeping a grip on their backlog, ever-shifting business priorities always threaten to shake up the IT agenda. One of the toughest tasks for CIOs is to align the jumble of projects vying for resources with the company's strategic needs. In a fast-paced business climate, new projects-especially those that come from the top floor-scream for attention.

"They can also come about quite innocently," Holstein says, due to external factors that cause the business climate to shift. "What was a top priority becomes priority number 10." A major contributor to the application backlog has been compliance-related projects, such as investments for Sarbanes-Oxley and HIPAA regulations. IT has to complete those projects by set dates, and in many cases, these infrastructure projects require substantial IT resources. Invariably, notes Holstein, implementing compliance projects pushes others farther down the to-do list. At World span, Powers says, compliance-related projects trumped even a project that aimed to improve how the company prioritizes its IT projects. The backlog generated by a new corporate agenda is worse for the CIO, who has to scramble to execute a decision she wasn't consulted about. Rood has seen it happen: A CEO and COO decide that they want a CRM system. When the CEO tells the CIO about it, the CIO is clueless as to why the project is necessary. The new project sends the IT department scrambling to jump-start the CRM project and pushes everything else to the side. "That will upset what the priorities are in terms of technology needs for the entire organization," observes Rood. At The Queen's Medical Center, Kudla wages a constant battle to ensure that all of his constituents know that every IT project has to be in sync with the center's strategic initiatives. As a member of the senior management team, he considers it his most important task to make sure his peers are aware of and agree to the center's priorities. Everyone, from senior executives on down, should know that a pharmacy management system is important for the hospital; they should also understand that rolling out the wireless PDAs for e-mail is "low on my food chain." Rood, who's been in the IT field for 26 years, says he learned this lesson early in his career.

"When you're new, everyone wants to shake your hand, welcome you on board, take you out to lunch, and at the end of the day you've got 50 things from everyone to do," he recalls. "It all adds up to a backlog, and then you're going to be crying to the CEO: ‘I can't do this.' " At that point, he says, CIOs either have to take the hit and not deliver what they promised (which could get them fired), "enter a crash mode, where they push their staff to the point of exhaustion to complete a project," or spend extra on contract labor to meet a deadline. "In any case, it becomes a no-win situation," he says. Powers gets around the problem of not wanting to say no by sending the message that IT is a resource to be managed like any other; her organization can do anything given enough time and money. Then the onus is on users to justify and manage their requests through World span's project justification process. Kudla of The Queen's Medical Center expects that once he upgrades the hospital's seven major systems, new demand will surface. "Once the system is stabilized and users realize the potential of the new system, I anticipate a demand for new functionality," he says. Kudla anticipates requests for, among other things, automating the capture of data from patient monitors and expansion of wireless access on the hospital campus. In other words, the application backlog isn't a problem one solves, it's a condition one lives with as technology matures and expands into new areas of the business, enabling growth and greater efficiency. "Of course, working harder and more funding help," concludes World span's Powers.

CASE STUDY QUESTIONS

1. The case notes that a changing environment or business priorities can render an ongoing project obsolete even before it has been completed. What alternatives do CIOs who find themselves in this situation have with respect to dealing with the troubled project? Would you go ahead and finish it, or scrap it altogether? How would you justify either position?

2. Do you agree with the statement: "Application backlog is not a problem one solves; it's a condition one lives with"? Why or why not? To the extent that it is true, how can IT executives manage things differently to make this situation more approachable? Provide some specific suggestions.

3. Susan Powers at World span says she addresses the backlog problem by positioning her IT organization as a resource that should be used and managed in the most effective manner, like any other resource a company may have. What do you think of this approach? Is IT really like any other resource?

4. In which way is IT different from other areas of a company like marketing or finance?