UPS executives and software developers learn usability and execution lessons

Long, long time ago I thought of working for UPS.  Why?  Because my degree choice of Industrial Engineering made me think of where I would work.  Luckily I realized that going to work for high technology companies and applying industrial engineering was a more interesting path which led me to HP, Apple, and Microsoft.  One of my first passions was logistics and I worked on logistics systems and software from 1983 to 1987 at HP and Apple.  I still like reading about FedEx, UPS and other logistics challenges.

The WSJ has a post on UPS's Orion software a 10 year effort to squeeze even more optimization out of routes.  What I found most interesting beyond the $100s of millions of dollars saved a year is listed in the following.

The WSJ says the Orion needed to learn to accommodate people.

Rough Patches
The deployment of Orion isn’t always so smooth, though. That is where Mr. Levis comes in. As project manager, he is responsible for getting people and machines to work together. During the earlier stages of writing the Orion algorithm, it was Orion that had to learn to accommodate people.

This one made me laugh because it makes you think the software has its own mind of what it decides to do.  No.  It was the executives and software developers who choose to ignore the human usability issues.

In the next paragraph, the other lesson of executing the plan is described.

“The project was nearly killed in 2007, because it kept spitting out answers that we couldn’t implement,” Mr. Levis recalls. The earliest versions of Orion focused on getting the best mathematical results, with insufficient regard for the interests of the driver or the customer, who value some level of routine. For example, regular business customers who receive packages on a daily basis don’t want UPS to show up at 10 a.m. one day, and 5 p.m. the next. And a customer who is expecting a shipment of frozen food needs delivery as soon as possible, even if efficiency demands that someone gets priority.

To get the project back on track, UPS chief scientist Ranga Nuggehalli turned to Bob Santilli, a senior project manager, asking him to describe a perfect route. Several weeks later, Mr. Santilli came back with the results of his effort, which produced a model plan of stops for drivers on a route in Lancaster, Pa. The engineering team extracted proprietary rules from the Santilli route and built them into Orion.

How could UPS have avoided some of these mistakes?  The approach I use is to not treat the users as individuals in the system.  It can be too easy to discount things because you don't see the impact of points they make.  Think of the team of people working together.  How do they work together and how well your software support them working better as a team.  Even now I would say Orion could be improved if was a way for a team of drivers to work together make feedback and suggestions on improvements of usability.