I’m always looking for diversions to occupy what I laughingly call my “spare time”. That’s why I found myself reading about a local tour bus called the “RiverCity Trolley” (no, it isn’t a piece of software – our typographic cliches have infested the rest of society.) Customers give the trolley high marks for fun, interest and value.

So here’s your management challenge for the day: You have seven tour-bus drivers hauling locals and tourists around the city’s attractions (yes, the Twin Cities have tourist attractions beyond the Mall of America, even though none spring to mind just now). How do you design the drivers’ spiel so as to delight your customers?

“Now let’s see,” I can hear some of you thinking. “To ensure quality you need repeatable, predictable results.”

“How can we automate this?” I sense others of you wondering, though my awesome telepathic powers. “We could pre-record the tour script with a professional announcer, but we’d need to link into a Geographic Positioning System (GPS) so the system will read the right part of the script when the bus actually arrives at each point of interest.”

I wonder how many of you came up with the same solution David Wiggins, who runs the program for the Minnesota Historical Society, ended up creating. Quoting from the story in the Star Tribune, he gave the seven drivers, “… a stack of interesting materials about Minneapolis and let each one develop a personal tour. Some like the early history, some stress the contemporary. One knows architecture, another knows the music scene. Some try to be funny, some try to teach.”

The first law of management, you’ll recall, is “Customers define value,” and quality is one aspect of value. Ideas like creating predictable, repeatable results can be important in ensuring quality in a wide variety of circumstances.

Not, however, every circumstance. Unfortunately, like someone who has learned only the waltz, some managers apply this often-valuable principle even when the band is playing a different tune.

Total Quality Management (TQM) theory grew out of manufacturing process engineering and management. When you’re manufacturing, you generally want predictable, repeatable results, and by redefining management goals for manufacturing in these terms, TQM has led to dramatic improvements in product quality worldwide.

Like that old saw about having a hammer and seeing every problem as a nail (sorry), some managers have learned TQM and believe all management problems can be reduced to building repeatable, predictable processes which they then manage as a factory.

Some issues in IS management really do fit the factory model. Do you manage networks, data centers, or PC installations? You are, in a sense, managing a factory, and if you haven’t learned and applied TQM to your operation, you’re doing your company a disservice.

Does TQM apply to application design and development? I’m less certain. It has enough repetitive processes to have similarities to manufacturing – how many times do we have to design a database, program a bunch of data entry forms and reports, performance tune the whole schmear, and convert the old data before we’re good at it?

On the other hand, every new system is unique in its details, and mapping each process in system development to a factory process doesn’t make the two equivalent.

There’s an old joke about a guy seeking the meaning of life. Finally he crawls up a mountain in Tibet to consult the Great Guru. “What is the meaning of life?” he gasps.
“A wet bird never flies at night,” is the reply.

“I wandered the earth all these years in my search, climbed this mountain to sit at your feet, to hear you tell me a wet bird never flies at night?” cries the man in exasperation.

“You mean,” asks the guru, puzzled, “a wet bird does fly at night?”

Repeating the phrase “predictable repeatable results” as a mantra may make you a guru, but it doesn’t necessarily mean you’re solving the right problem.