Managing the flow of an infinite supply of worthwhile projects through a finite IT operation takes finesse. Here's how to avoid the backlog and the chaos.

Not long ago, IT consultant Mark A. Gilmore was called in to help an IT department that was struggling with project overload. "They'd gotten this kind of attitude -- the executive vice president calls it 'Burger King Syndrome,'" he recalls. "Their approach was, 'You can have it your way.'"

The business executives believed IT could supply whatever they wanted, whenever they wanted it. Salespeople had gotten into the habit of asking the development team to create applications within a week to fulfill promises they'd made to customers. As a result, IT employees were spending about 80% of their time reacting to crises or struggling to meet impossible deadlines rather than calmly planning their workloads, says Gilmore, president of Wired Integrations in San Jose.

In the meantime, basic technology improvements weren't getting done. For example, Gilmore was surprised to discover that, though the company had a large data center with several hundred servers, there was almost no virtualization.

"You can't operate that way because it creates chaos," he says. "The quality of the work gets degraded. People's happiness level gets degraded, and it becomes a miserable environment."

Unfortunately, this very situation has become the norm in many IT departments. "It turns out to be a chronic problem," says Gartner analyst Robert Handler, who notes that his firm's research suggests that at least one-third of funded technology projects are currently in a backlog, waiting for IT to start on them. That's not a good sign, he says -- especially since there's strong evidence that overloaded IT professionals are measurably less productive than ones with reasonable workloads.

An improving economy is probably to blame for the added strain. In Computerworld's Forecast 2013 survey, 43% of respondents said they expected their IT budgets to rise this year, up from 36% last year. Sixty-four percent anticipated making a major IT investment. At the same time, 59% reported that containing costs was a priority. In the real world, that translates into a growing number of projects flowing through IT departments whose staffing levels have remained flat.

"Over the years, there had been pretty steady improvement, with backlogs going down and developer productivity going up," Handler says. "The most plausible explanation is that the credit collapse of 2008 led to companies stopping everything they possibly could." In 2010, he notes, IT productivity again began to slip, leading him to suspect techies were once again getting overloaded. Sure enough: "We started looking at other data sources and saw backlogs building up," Handler says. Piling more and more work onto IT is like pouring too much water into a funnel, he says: It works for a while, but then "all of a sudden there's too much and it makes a big mess."

Project Management

Should You Reserve Some IT Capacity?

It's always a bad idea to plan more projects than your IT department has the capacity to carry out. But should you plan substantially fewer, keeping some IT work hours in reserve for contingencies?

That's what Gartner analyst Robert Handler advises. "In theory, if everyone came to the table during budget time with information on all the systems they need, it might be possible" to plan to work at full capacity, he says. "But a week or two after budgets are done, there are already a lot of requests for new stuff. We're in a complex world and there are changes constantly coming from markets and legislature. They destroy the predictability of projects."

Few IT operations are effective at dealing with the unpredictable nature of their work, says Handler. So he looked at other fields for inspiration. He found it in new product development. "Their response is to maintain reserve capacity for uncertainty," he says. He believes IT departments should do the same.

"Some business leader will say, 'We need this project to do business,' and if the CIO says, 'No, we can't, we're at capacity,' the answer will be, 'Then we'll get it elsewhere because we need it!' I suggest you reserve capacity for that situation." IT's goal should be to run at 80% of capacity, reserving the extra 20% for "things that come out of nowhere," he says.

Todd S. Coombes, executive vice president and CIO at ITT Educational Services, disagrees. "I've worked in environments where you set up contingencies, and I prefer to work based on historic data," he says. "If my data from past projects tells me I need to reserve a certain amount of time for unplanned activities, we'll work toward that, rather than assume we need to build in an extra 20% thinking things might go wrong." When people know they have that leeway, they tend to use it, he explains, adding, "I like to have things a little tighter."

Coombes says he uses detailed planning of every IT employee's time, and then has them track their activities as projects progress. "We can see historically what they actually spent their time on," he says. "It's kind of a feedback loop of planning and setting our capacity target, collecting actual information and then studying the data." That process allows for increasingly accurate planning.

This way, Coombes can plan for the unexpected on those projects that warrant it. "I don't know exactly what unexpected thing will happen, but historically I know it's going to be something," he says. "So we will build that into our capacity model. But it's based on what we know to expect."