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.

If it didn’t happen this way, it should have: On the great golfer Ben Hogan’s 70th birthday, I’m told, an interviewer asked if he had plans to retire. “Retire?” Hogan is supposed to have responded. “People retire to fish and play golf. I fish and play golf now!”

Management consultants have an unfortunate penchant for sports metaphors. So, it occurred to me the other day as I searched for my ball that IS management and golf have a lot in common. To those of you who play the game I need go no further. For the rest, I’ll explain some of the parallels:

1. When your golf swing goes off, you try solutions more or less at random to fix it. When a computer program that used to work crashes, programmers often do the same.

2. Sometimes, the tools we use in computing just don’t work the way they’re supposed to. The same can be said of golf clubs.

3. In golf, even when you can reach the green in one shot it usually takes two putts to get the ball in the hole. With computers, even when you have a relatively easy problem to solve you usually need two iterations after delivering the product before you satisfy the user.

4. With computers, no matter what new snazzy tool you buy someone announces a better one right after you spend your money. That’s true of golf clubs too.

5. In golf there’s par, but most of us are pretty happy getting a bogey. With computers there’s the project plan, but we often feel pretty good if we only need one extension to finish the project. (By the way, for those of you on Year 2000 projects – you won’t get an extension. Sorry.)

6. In IS we often work in politically charged environments. Keeping your head down can be important. In golf you want to keep your head down, too.

7. Many greenskeepers resent those pesky golfers who mess up their beautiful golf courses. Many network managers resent those pesky end-users who clog up their pretty networks with unwanted packets.

8. On a related note, too many users on the network slows down response time. Too many golfers on the course slows down play.

9. Golfers remember the sport as being fun, but when we’re playing, at least in Minnesota, we spend half our time swatting bugs. Likewise in IS, getting rid of bugs gets in the way of the fun.

10. Most people outside of IS don’t understand why we find our profession so fascinating, and have no idea why it’s so hard. Non-golfers have no clue why golfers hit a small white ball around a field with sticks, let alone why the ball usually curves out of the fairway.

11. In golf you can hit a great-looking shot that lands nowhere near the hole. You can also hit a nasty-looking shot off the heel of your club that scoots across the grass, bounces off a squirrel, and finishes two feet from the cup. With computers, you can write elegant code that somehow fails to satisfy the users or succeed in the marketplace … and on the other side of the equation, there’s Windows.

12. Most people can become competent programmers. With time, training and hard work we can create solid programs that work well. In the next cube, though, there’s someone who speaks C++ as if it were his native language, writing code as beautiful as poetry that always works perfectly on the first compile. In golf, most of us can get the ball in the air and “out there” after a bunch of lessons and several years of practice, but we all know someone who shot par when he was twelve years old.

And, both pursuits have the same favorite phrase: “Oh %$#^!”