All Posts in Organizational Effectiveness

|In: Organizational Effectiveness|Last Updated:

The collapse of world communism means we no longer get to hear political candidates refer to one another as “commie pinkos”, “communist dupes”, or the ever-popular “Marxist”. Now, we get to hear about the character issue, the term “liberal” is bandied about as an epithet, anyone we don’t like becomes a Nazi, and everyone involved seems to be searching for issues worthy of an attack on their opponents.

I miss the old days.

One of the principle differences between Marxism and Capitalism is their theory of value. Karl Marx proposed the Labor Theory of Value, while Capitalism promotes the Market Theory of Value.

The Labor Theory of Value, typical of Marxist economics, has a curiously ethical flavor to it. Value, says Marx, comes from the effort needed to transform raw materials into finished product – that is, it’s the workers who create value.

Capitalism, pragmatic as always, says that the market, through the dynamics of supply and demand, establishes value. The market, of course, is nothing more or less than the aggregate behavior of all actual and possible customers. Customers define value in a capitalist economic system.

Customers define value, which irritates movie critics (who usually sneer at anything lacking subtitles or including an explosion and car chase), computerphobes (who complain about feature bloat, claiming nobody uses program options I use every other day), and software engineers who deride those who care more about features than internal architecture.

The idea that customers … real paying customers, not “internal customers” … define value is one of the three great rules of management. (The other two? Form Follows Function and Align Everyone to a Common Purpose.)

I’m not a big fan of the internal customer concept. It strikes me as a metaphor that’s been extended past its useful purpose.

When you’re redesigning a process, you need to look at who sends work in and who receives the work you send out. Why? You define the specifications for the work that comes in to you, and the recipient of the work you create defines the specifications you use to define your product. In that sense, whoever receives the work you create is your customer, whether it’s an employee in your company, a department in your company, or an external customer.

So far, so good. “Internal Customer” is a useful shorthand for whoever creates the specifications. Unfortunately, nobody can ever seems to limit the application of a metaphor, so in short order, people started to believe that internal customers are always right, just like external customers. Some people in accounts-payable departments even believe vendors are their customers, since vendors receive the work they create.

Internal customers lack the defining characteristic of real customers. They don’t pay you. That means they don’t define value, nor does a transaction with an internal customer give you the wherewithal (money) to provide the service they ask for. And that, in turn, means they’re not always right.

The internal customer metaphor also violates the third great rule of management: align everyone to a common purpose. It takes companies to the opposite extreme, inducing severe myopia. When employees believe in internal customers, they look no further than the needs of the next person in line. Only a few employees worry about the needs of real paying customers.

Here’s what I recommend as an alternative: everyone in the organization should understand their role in providing value to real paying customers – the big picture. If you’re in Accounts Payable, you’re trying to minimize overhead while maximizing cash flow, thereby helping sell products and services at an affordable price. Human Resources? Help managers develop a motivated, skilled, high-morale workforce.

Information Systems? How does Information Systems provide value to real, paying customers? Traditionally, we do so by helping everyone else in the company be more effective in their roles. That, in turns, helps the company increase the value it can deliver.

The world, however, has changed. Now we have a more direct role to play. Have you started to play that role?

Comments

|In: Organizational Effectiveness|Last Updated:

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.

Comments