next up previous
Next: About this document Up: No Title Previous: No Title

Three Cautionary Tales

Before I begin, I want to stress that these notes provide a very clean view of management science. Problems are already defined, appropriate solution techniques are fairly obvious, and measures of success are generally limited to aspects of solving the model.

The real world is not so nice. While knowledge of the science of operations research is necessary, it is the art of management science that separates a good analyst from an average one.

Consider the following, probably apocryphal story. There once was a very tall building with far too few elevators. Tenants complained and complained and complained. Finally, the management brought in a consulting firm to analyze the problem and suggest solutions. In comes this group, many trained in management science. They did their motion studies, carefully calculating how many people wanted to go from each floor to each other floor. They divided the day into seven periods, from the early morning rush (most going down, for this was a residential building) to the emptyness at 3 A.M. Simulations were run, and suggestions were made. One possibility was to leave all apartments above the third floor empty; another was to dedicate the odd floors to night workers; a third (coming from an analytic queueing model) was to add 2 and one half elevators; another was to experiment with non-elevator systems (not unlike firepoles); and so on. On the day of the final presentation, as the group was waiting for an elevator to take them to the meeting room, one analyst realized the problem: it was just plain boring to wait for elevators. The final suggestion of the group: put mirrors in the elevator foyers. The tenants ended up so occupied watching themselves and others that they didn't notice how long the elevator took to arrive.

This leads to our first rule of management science.

Be creative.

No other rule is of comparable importance.

In spite of this story, I do feel that knowing techniques is important. It is only through being comfortable with a subject that it is possible to correctly apply, and correctly not apply, a technique. Furthermore, the more techniques you are comfortable with, the more likely you are to find one that is appropriate. Here, appropriateness is meant in the broadest sense, including model accuracy, time and resource limitations, data difficulties, and so on.

Let me tell you another story. A couple of years ago, there was a plea for help on one of the computer bboards. Some poor guy was set the following problem: A firm distributes stock quotes to its customers. Stock quotes go out in packets, giving a set of twenty or so quotes. Customers are only interested in a subset of the quotes. They receive one or more packets, read the information they want, and sent the packets on to their respective next customers. Stock prices are updated every ten seconds, and every customer should receive updated stock information every thirty seconds. How should the stocks be combined so as to minimize the number of packets?

There is more information available, but that is a start. The first response I saw formulated this problem as an integer program (with several hundred constraints and perhaps a thousand variables) and suggested branch and bound. It takes very little thought to see that this ``solution'' is worthless. No computer can solve integer programs of this size within the 30 second time limitation. Which leads me to:

Use appropriate tools.

The final story that I wanted to mention is from my own consulting activity. The military was interested in a planning system for its cargo ships and planes in times of military crisis (already sounds dated, doesn't it?). In essence, they had a million tons of stuff to be shipped, spread all around the U.S., and a few thousand planes and ships to ship it. Well. in the best tradition of management science, we formulated a model and provided a solution method (which you will learn about). One (seemingly trivial) assumption we made was that the planning period was much longer than the trip time for any plane or ship. The work we did was much admired by the Majors and Colonels we were working with, a a 15 million dollar contract was awarded to implement this solution (won by a Washington firm, with us subcontracting the ``hard'' part). After roughly 14 million dollars were spent, the three-star general in charge started running his own scenarios. Within one month the project was cancelled, numerous officers decided early retirement was a good choice, and entire floors of a certain Washington consulting firm were let go. Why? All of the General's scenarios involved a three day defense of Central America, and ships required four days to get there. All of our answers were nonsense, for our assumptions were wrong. They wanted short term, not long term, planning.

Solve the problem that exists. Not the one you feel comfortable solving.

(On a slightly more cynical note: Make certain your answers never look stupid.)

Finally, a colleague of mine, who is just buying a house, was shopping around for mortgages. A common mortgage type is a fixed rate mortgage, where the interest rate is fixed for the life of the mortgage, but the home buyer has the option of prepaying without penalty at any time. In such a mortgage, the financial institution often allows the buyer to pay ``points'', with 1 point equal to 1% of the borrowed amount. The more points paid, the lower the interest rate. A local bank, undoubtedly using the finest of modeling methodology, determined there was a market (generally made up of financially distressed people) who would be very happy with a high interest rate and negative points: a cash bonus of up to 4% of the borrowed amount (with a corresponding high interest rate). A moments reflection should lead to a discovery on how to exploit this offering (so my friend plans to own his house in four years having never made a payment). The final conclusion I would offer is therefore:

Modeling is an adjunct to intelligent decision making: it is not a replacement.


next up previous
Next: About this document Up: No Title Previous: No Title

Michael A. Trick
Wed Sep 11 11:04:20 EDT 1996