All Posts in Project Management

|In: Organizational Effectiveness|Last Updated:

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.

Comments

|In: Industry Commentary|Last Updated:

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.

Comments