The airlines took my advice!

Last week, talking about overbooking, I suggested “Change the rules so the airline can charge passengers for their seats whether or not they show up.”

The airlines took this exact step … years ago, long before last week’s column. They must be psychic.

Strangely, I did know this, from personal experience, when I wrote the words. But this fact seemed so utterly preposterous that I figured my memory must be faulty — a not entirely unreasonable proposition.

Imagine we were talking about sporting events rather than travel and the Cubs double-sold seats on the theory that not all fans show up. It would be a scandal. (If the Minnesota Twins did the same thing, nobody would notice, but never mind that.)

Which leads to another possibility: Let scalpers get into the airline ticket game. I’m not sure it would be any worse than the current system.

Time to get down to business …

I figured there might be more ways to apply recent air travel debacles to IT practices, which is how, in my desperate and perennial search for IT-related topics pulled from current events, I ran across a genuinely interesting and very relevant analysis, titled “How the Airlines Became Abusive Cartels,” (Robert Kuttner, The New York Times, 4/17/2017).

Read the article, ignore the inflammatory headline, and you’ll come to this intriguing statement: When weather or mechanical problems or crew delays cause cancellations, the airlines have great difficulty accommodating passengers because there is not enough slack in the system. Leaving a few empty seats would increase the system’s efficiency overall.

Which sounds like a very important idea to incorporate into your IT governance practices.

The challenge starts with prediction being a statistical exercise, especially when predictions are about the future. And IT governance done right, like airline ticket-holder management done wrong, relies on accurate predictions. In the case of IT governance, the predictions are about project milestone and completion dates.

This is because a well-managed EPMO (enterprise program management office) tries to schedule each project launch as soon as the individuals needed to staff the project team will be available … when they roll off a preceding project, either because they’ve completed a milestone and so aren’t needed any more, or because the project has completed and doesn’t need anyone any more.

But actual project schedules and completion dates, like airline take-off and landing times, are stochastic, not deterministic. They’re based on uncertain predictions, not clockwork certainties.

Which means that unless the EPMO builds slack into its project master schedule … the master timeline that shows, for the next three to seven years, which projects will start and finish and when they’ll do so … any project that’s at all late will throw the plan into chaos, just as a blizzard throws the entire U.S. air travel system into chaos.

But what does “build slack into the schedule” really mean?

The most obvious form of slack is to simply leave a couple of weeks between one project finishing and the next one launching. This will harm your employee utilization metric … if the metric is defined so as to make 100% utilization the optimum. So fix that while you’re at it. Make 80% or 90% utilization the target. Otherwise you’re doing your best to always be out of capacity — a condition that guarantees you can’t respond effectively to emergencies.

There are other useful forms of slack, too, and smart CIOs will do their best to make sure they’re all present and accounted for. Examples:

• Versatility: Employees who can take on multiple roles provide flexibility to accommodate projects that need a particular set of skills which, due to a project going long, aren’t available in the planned form of the originally planned team member.
• Retirees and established contractors: Retirees already know your company, culture, applications portfolio, tools, and so on. They can come in ready to work and delighted to pay for their next vacation. The same may be said of contractors you work with a lot. Keep both handy in your Contacts folder.
• Avoidance of exotica: Build as much of your technical architecture as possible out of popular platforms and popular COTS and SaaS packages and you’ll have access to a bigger pool of talent than if you build it out of even the best little-known components. This makes outside contractors more useful as a source of slack.

Which means you’ll be less likely to need to bring in specialists who might, if they and you are unlucky, be booted off the flight from where they live to where you are.