I’ve solved the airline overbooking problem. Yes, this does apply to IT in the enterprise. Be patient.

Unless you were completely off the grid last week, you know about the contest between United Airlines and Dr. David Dao. Dr. Dao had purchased a ticket, boarded an overbooked United flight, was randomly selected to give up his seat because United had overbooked the flight, once it counted its own flight crew that also had to get Louisville. Dr. Dao refused to give up his seat.

The result: United enlisted the help of three airport police. One concussion, two missing front teeth, and a forehead gash later, they dragged the 69-year-old Dr. Dao from the airplane.

(Sidebar: If you’re certain United had the right to remove Dr. Dao from the flight and the entire argument is about technique, or, if you’re certain it didn’t, please read PolitiFact’s Analysis. Short version: Citing Embry Riddle Aeronautical University aviation law professor Stephen Dedmon, PolitiFact concluded: “The specifics of Dao’s case can currently be debated but not resolved without knowing all the specifics or legal interpretations. It would take a court ruling to decide UA’s provisions were appropriate and properly applied.”)

The airlines inform us that they have to overbook, because some passengers who buy tickets don’t show up, resulting in empty seats on the flight. They overbook to compensate in order to maintain profitability. Occasionally, due to the laws of statistics, this results in a few more passengers than seats.

I have a better solution. It does require an advanced degree in statistics but is otherwise quite workable. In layman’s terms, it works like this: Don’t overbook!

Here’s how it would work: A passenger books a ticket for a flight. That means the airline has the passenger’s credit card information. Change the rules so the airline can charge passengers for their seats whether or not they show up. Empty seat or full, the airlines don’t lose money, and in fact they gain a bit, because the plane weighs less and uses less fuel.

We can sweeten the airlines’ pot even further: Five minutes before flight time they can sell any remaining empty seats to travelers flying standby.

This isn’t even hard. But what’s it have to do with enterprise IT?

Enterprise IT has its own passenger no-show problem. It works like this: Through the magic (okay, bureaucratic nightmare) of the IT governance process, a business manager … or, if you’re Agile, product owner … gets a project request approved.

No matter what methodology you use, if the business folks don’t show up for interviews, walkthroughs, workshops, and such … if you have empty seats, that is … your project can’t move forward.

To solve this, some IT shops emulate the major air carriers. No, they don’t send in the local police to remove business stakeholders from wherever they are and drag them to where the project’s business analyst is waiting for them, amusing as that might be.

What IT shops do is to overbook, although what they call it is multitasking: Developers and business analysts are assigned to enough different concurrent projects that there’s always something productive to work on for at least twelve of them.

This is a terrible idea (see “The end of multitasking as you know it,” from my old InfoWorld “Advice Line” blog). One of the most important factors in achieving reliable project success rates is the flip side of this coin — to only launch fully staffed projects, with “fully staffed” defined as “never waits on the availability of a project team member.”

Instead, IT should rely on a solution roughly analogous to what I suggested for empty seats. Only instead of selling the unused interview time to a different project’s business stakeholder, the EPMO (enterprise program management office), IT Steering Committee, or whoever or whatever else is responsible for IT project governance establishes a three-strikes-and-you’re-out rule: If business stakeholders fail to show up for interviews, demos, daily stand-ups, or what-have-you in ways that slow a project down, the project is immediately and unceremoniously cancelled.

This might sound draconian. It might be draconian. But I don’t think it’s unreasonable.

Start with the understanding that there’s no such thing as an IT project. Projects are always about business change, so if business stakeholders don’t show up when they’re scheduled to show up, the intended business change can’t be very important to them.

The analogy isn’t that you’re booting them off the flight. You’re cancelling the flight.

Or something. The analogy isn’t what matters. It’s getting even with those lousy no-shows.

No, that isn’t it. You’re merely adjusting to the company’s dynamically changing business priorities. Yeah, that’s the ticket.

Or at least, it’s the boarding pass.