We call it the “process bypass process.” Hold that thought.

In a healthy organization, IT’s business partners have a lot of ingenuity, much of which is focused on what IT can do to make their work more efficient, productive, and effective.

Far too much ingenuity, in fact, for IT to be able to take care of it all. The result is the ever-present “IT backlog” — the list of projects IT won’t be able to get to for the foreseeable future. IT has struggled to find solutions to the backlog for as long as I’ve been in this business. The problem is as pernicious as ever.

There’s no single solution — you have to nibble away at it. Here are some techniques you can apply to deal with it and, if not solve it altogether, at least make it manageable.

  • Apply the rule of ten. Any organization, at any level, can deal with between three and five initiatives of any size in a given year. Any more than that and the organization’s energy is divided too thinly for anything to get done. That being the case, whenever anyone suggests a great idea (as in, “You know what this organization needs to do? It should …”) ask this question: “Great idea. And we have a lot of great ideas in front of us for what this organization needs to do. Does this make the top ten list? Because if it isn’t one of the ten most important, we’ll never get to it.”
  • Insist on a business sponsor. No, not just someone willing to testify that “we need it.” We’re talking about someone who has the authority to commit to the business benefits to be had from whatever the request is for and live up to delivering them once the project is finished. That also means defining all projects in terms of business change, not software delivery, and including implementation of the business change within the project plan. No benefit, no business change, no project.
  • Use a magic quadrant. Yeah, I know, but use one anyway. The x-axis is total benefit — amount of improvement combined with organizational scope. The y-axis is total investment — the combination of cost, effort and risk. These don’t have to be precise — consensus scales of 1 to 10 will do just fine. By throwing each request into the magic quadrant you can do some initial screening: Reject everything (of course!) that combines high investment with low benefit. Accept everything that combines low investment with high benefit. So far, so good.Low investment and benefit? Either make it a local problem, to be solved with Excel or MS Access, or find a way to fold it into another, larger effort.

    The high investment/high-benefit proposals are the toughest. These are the ones you carefully screen and analyze. Choose only as many as you can successfully implement, and make sure they get a lot of oversight. They’re the most likely to get out of hand, and the most likely to be disappointing once completed.

  • Don’t say yes or no. Say no or when. If you can’t provide a project launch date, you might have said yes, but you didn’t mean it because you don’t know if, let alone when, you’re going to work on it. Don’t pretend. You haven’t said yes until you’ve put the project on the master schedule, with the launch date predicated on the availability of all staff required for the project to proceed.So now you have an governance process. Be careful what you ask for. Another name for well-defined governance is bureaucracy — the loss of flexibility and agility that’s the result of slow, consensus, committee-driven decision-making.

Which is why, as part of your IT governance process, you need a process bypass process — a governance process that bypasses your governance process. It’s a way to fast-track opportunities that just won’t wait. The keys to success for a process bypass process are (1) it’s only used for time-sensitive opportunities, not to placate the loudest voices; (2) it’s used to give the project the next available time-slot in the master schedule, not to interrupt work in progress; and (3) process bypasses still require approval — most likely by the CEO, CFO and CIO. And that includes approval to use the process bypass process in the first place.

Which is to say, nobody gets to bypass the process bypass process.

I wonder how the guy who said, “There are no problems, only opportunities,” would explain New Orleans.

The combination of tragedy, mind-boggling incompetence, and failure to prepare for a long-predicted preventable catastrophe is a problem. For all of us. If it’s an opportunity, it’s to remind us of a few basic facts effective leaders, including IT leaders, can’t ignore.

Blaming the victim takes less effort and is more satisfying than understanding the situation.

A popular talking point is that “they” don’t deserve sympathy, since “they” built a city five feet below sea level. Let’s not stop there: Nobody gets any help after a disaster unless it couldn’t have happened where they live. A lot of the Netherlands used to be sea bottom. Forget them! Californians? They chose to live near an earthquake fault, as Floridians chose to live in a hurricane zone. As a Minnesotan I think it’s a fair policy, so long as we Midwesterners get help after tornadoes, blizzards and spring floods. We live here to avoid the earthquakes and hurricanes, after all.

Of course, only parts of New Orleans are below sea level, and it’s been sinking at a rate of three feet per century — do the math. When, exactly, was everyone was supposed to pack up and leave?

Lesson for IT: When someone’s PC stops working don’t crab at them and don’t assume they’re morons who went out of their way to annoy you. Help them solve their problem. Uh … opportunity.

Achieving a leadership position bestows neither expertise nor acumen on the ignorant.

Three of the top five executives in FEMA had no experience or training in managing emergencies. Expertise does matter.

Lesson for IT: Some CIOs have no technical background. If you’re one of them, seek out the best engineers in your organization — those with the most knowledge and best judgment. Spend a lot of time listening to them. Doing so isn’t a sign of weakness. Failing to do so is.

This is how you can make sure you get early warnings about problems while they’re still solvable. Don’t rely solely on your chain of command. Develop direct relationships with your experts, too.

Turning your back on a problem doesn’t put the problem behind you.

Politicians of both political parties ignored the clear, loud warnings of scientists and engineers that that the drowning of New Orleans was inevitable. This, for example, appeared in Scientific American in 2001:

A major hurricane could swamp New Orleans under 20 feet of water, killing thousands. Human activities along the Mississippi River have dramatically increased the risk, and now only massive reengineering of southeastern Louisiana can save the city.

If a big, slow-moving hurricane crossed the Gulf of Mexico on the right track, it would drive a sea surge that would drown New Orleans under 20 feet of water. “As the water recedes,” says Walter Maestri, a local emergency management director, “we expect to find a lot of dead bodies.”

Mike Parker, former head of the Army Corps of Engineers, showed Mitch Daniels, then Director of the OMB, two pieces of steel. One was new, the other had spent 30 years under water in a Mississippi lock and was completely corroded. Complaining about a 33% budget reduction in 2002, he said, “Mitch, it doesn’t matter if a terrorist blows the lock up or if it falls down because it disintegrates — either way it’s the same effect, and if we let it fall down, we have only ourselves to blame.” Shortly thereafter, Daniels made sure Parker was fired.

While maintenance funds were being cut, Representative Mary Landrieu (D-Louisiana) made sure Congress allocated $194 million to increase capacity for barge traffic while barge traffic had been steadily declining and the Army Corps of Engineers had advised against the project. Meanwhile, Representative Don Young (R-Alaska) obtained $230 million to build a bridge connecting a city of 8,000 to an island with 50 inhabitants.

Lesson for IT: Don’t allocate budget to placate political constituencies in your company until after you’ve taken care of business.

An ounce of prevention continues to be less expensive and more convenient than a pound of cure.

Beefing up the levee would have cost less than $30 million. The cost of failing to do so will be at least a thousand times more.

Lesson for IT: It’s pretty obvious, isn’t it?

Last, beat-the-dead-horse word on all of this: Managers deal with financial and political realities. Engineers deal with the reality imposed by the laws of physics.

In the end, engineering does matter.