Skip the navigation

How to prevent IT department overload

By Minda Zetlin
May 20, 2013 06:00 AM ET

"I typically am involved in conversations about projects that have to be delayed -- but our business leadership is also involved," says Todd S. Coombes, executive vice president and CIO at ITT Educational Services, a postsecondary education company based in Carmel, Ind., with 140 campuses around the country. "Our group of high-level executives works together well, and we're all in the discussion before a decision is made. Typically, I don't have to deliver the message at that level. I may have to at a lower level, and I don't mind because I have the backing of my boss."

When you do have to say no to a project, your goal should be for the person who hears that no to feel good about the rejection. This is especially true if you're seeking to reduce or eliminate shadow IT operations, which are typically set up by business executives who decide to take matters into their own hands when they can't get IT to provide a desired technology quickly enough. "If they hear no without having bought into how that no was arrived at, they'll get it from someone else," Handler warns.

The key is transparency. "If you have a CIO deciding what gets done and what doesn't, the people who get their projects done will be happy," he continues. "The people who don't get their jobs done, if they think the CIO was fair and really thought it through, and if they understand the reasons for the decision, they'll still be happy 80% of the time."

You might be able to enhance that dynamic by getting your company's executives to literally sign on to the process, he adds. "If you get people to agree to both the objectives of the process and the process itself, they will tend to accept it because of a phenomenon called 'commitment consistency,'" he says. That effect doubles when people agree to something without feeling forced and have done something active to signal that agreement.

Measuring IT Capacity

How do you know how much you can take on in the first place? How many projects are too many?

The only way to find out for sure is to track IT capacity -- the number of working hours available in your department. "You have a mixture of both projects that create some kind of improvement and 'keep the lights on' activities," Coombes says. "That's the demand. We have to make sure we have enough capacity to handle those lights-on jobs, and then figure out how to provide capacity for the new projects."

Coombes uses what he calls the "capacity model" to plan IT employees' workloads. "We actually plan for the period before a release what we expect for individual people working on a project, based on their availability," he says. "We plan for a full eight-hour day, but we're not going to book eight hours of development time for a developer. We may need to set aside two hours for administrative tasks and answering questions that come up. So there might be six hours available for software development."

In that case, he says, the developer may be booked to work two hours on one project, two hours on a second and two hours on a third. And that's it. His capacity for the day is used up. "That's the only way to do it," Coombes says. "Otherwise, we tend to overbook people."

"There's often this perception that people who are working eight hours a day have another eight hours available," Handler notes dryly.



Our Commenting Policies