Design anti-patterns: Which Pot of Money?

This is one of the most pernicious problems in organizations. Decision making is often twisted by a single question that stakeholders apply to possible solutions: which pot of money is this coming out of?

To illustrate: I worked on a program to implement desktop applications in the call center of a financial services organization. One business was handed a large pot of money with these words: "Spend this pot of money for your call center. You can run as many projects as you like, but after the pot is empty you must pay for new projects from your own budget. The IT department is at your disposal. Defects or routine maintenance that are required after the applications go in comes from their budget."

The business unit, naturally, wanted to get the maximum amount of functionality onto the desktop as they could before the pot of money was empty, so they opened new projects as fast as they could write the statements of work--at one point the projects kept 15 project managers busy. The B.U. whipped the IT project managers to get the applications released as quickly as possible, secure in the knowledge that money to fix defects wouldn't come out of their budget, but the IT department's. Many PMs were happy to comply, since their performance was evaluated in part based on the number of projects they completed. Post production, requests for new functionality were disguised as "defects" and "routine maintenance," and handed to an overworked non-project service area within IT to implement. It was chaotic.

Of course, there were other considerations the B.U. had for getting applications released quickly. There was a schedule by which it was supposed to earn a profit, for example, and it needed the functionality on the CSRs desktop in order to deliver service to customers. In fact, that was a regular reason given for needing projects done so quickly. But the Which Pot of Money consideration was always there, like an unacknowledged whale shark in a swimming pool.

Telling stories in Second Life

Organizational cultures and sub-cultures was a big topic in my Org Behavior class this semester. Although people within companies often speak of "the company culture" which is determined by its executives, researchers typically find a variety of cultures within a single organization. Each culture has its own assumptions, values, and language, and the differences are sometimes sources of conflict.

Our project this semester was to shoot a video in Second Life that told an organizational story. My team's machinima video attempted to illustrate the differences between engineering and marketing cultures. This "culture clash" has been a rich source of material for Scott Adams, so we freely borrowed from the Dilbert strips, while providing narration based on academic research and our own experiences.

The video lacks in its execution, but was a nice learning experience. Videos like these would be a fast, cheap way to develop prototypes for new services. The prototypes could be viewed by potential customers and their feedback collected prior to giving the demos to managers. That's something I'd like to try to do some day.

Amazon and customer experience

BusinessWeek voted Amazon #1 in customer service for 2008. In this article, Jeff Bezos explains "the distinctions Amazon makes between customer experience and customer service. The latter is only when customers deal with Amazon employees—and Bezos wants that to be the exception rather than the rule."

A few weeks ago I blogged about the book The Best Service is No Service. One of the authors is a former Amazon manager. The book explains in detail Amazon's approach to customer experience--and how it reduces the need for customer service. Great read.

This is a funny thing. The fundamentals of customer experience and customer service are known by all (or could be, if people bothered to read and learn). But few companies are able and willing to execute. The reasons are rarely technical. It often has to do with managers who can't adapt, organizations that are silo'ed, departments that measure and reward the wrong thing. It's organizational, not technical. At this point, everyone has the same technology, so there's no silver bullet that will let companies beat their competition. It really comes down to execution of stuff that we already know how to do. Amazon mostly gets it right. A lot of companies could learn from Amazon.

The audio environment

I've always been an audio guy, if you can't tell from my blog posts. Speech recognition systems and the music digressions, that's most of what I talk about. Fact is, I was an audio recording engineer at several radio stations before I started the speech/psychology thing.

In the 1970s we kept our libraries of sound effects on old scratchy vinyl LPs to use for recording commercials and promos and such. I hadn't thought about that for years until I found this absolutely wonderful website for free sound effects and environmental sounds. I happened to have a need for some background music for a project I'm working on, so this was a nice find.

Royalty Free Music and Sound Effects Download the music and sound effects you need for your multimedia project today at Partners In Rhyme.

"First, tell the caller to do this...."

There's nothing that demonstrates the differences in assumptions between VUI designers and IT or business people than the way they express their ideas for how prompts should be written.

• "First, tell the caller to do this. Then tell them to do that. Then, they'll pick this option and they'll be where they should be."

That's IT/business speak. "Telling" callers to do things over the phone is a losing proposition. Assuming that they'll follow your cryptic commands isn't reasonable. Usually, they aren't your subordinates, and even if they are they usually aren't compelled to follow your instructions. In fact, you're often dealing with customers who may have the funny idea that YOU should be responsive to THEM.

The assumption that you can tell callers what to do leads to a logical fallacy.

• If callers obey instruction n they'll obey instruction n + 1.

This leads IT/business types to propose endlessly long dialogs, another assumption being that the caller on the other end of the line has no alternative but to obey instructions. VUI designers know that's not how people operate. At each step in the dialog callers evaluate whether they're getting closer to their goal, and whether it makes more sense to press the magic zero key (or say "agent," or play possum, or press the pound key three times, etc). People aren't calling to make the company's life easier, they're calling to get something--and that thing may be something they've already paid for and you owe them.

You can present the business people with call statistics that show you lose a percentage of callers on every question asked in a dialog, but often the message doesn't sink in. It's a matter of assumptions, and getting people to change unvoiced assumptions is a difficult thing indeed.

The "press or say" construct will not die

The "press or say 1" construct for IVR menus was rolled out by AT&T about 15 years ago, when speech recognition was new. There was a "wow" factor at the time, but those days are long gone. Still, I work with companies that feel a need to use this in their own IVRs and I can't understand why. When I ask why this is needed usually the response is "someone else decided this, we're not sure who, we just do project work." So someone high up in the food chain made the decision and we, the lowly consulting company, can't talk to them and try to get the decision changed.

There's no IVR design guild but if there were one it would dedicate itself to iradicating this practice.

You call this Agile?

I started a small project recently with a company that touts its Agile development process. The assignment was straightforward enough: determine why callers aren't completing what should be a simple registration process using a speech IVR.

A couple of things you probably already know about Agile. If done correctly, it's faster than traditional waterfall methodologies for getting projects completed. It also de-emphasizes the creation of documentation during the project. Of course, after the project is over no one wants to hang around and create documentation from scratch.

So, a week after the start of the project, no one has been able to produce any documentation of the existing system - no grammars, no call flows, nothing. This makes it just a little hard to review. This is one of my least favorite aspects of Agile.