When Projects Go Bad

There is a wonderful old Gary Larson cartoon titled “When potato salad goes bad.” It shows a bowl of potato salad in a refrigerator holding up various other foods at gunpoint.

Projects don’t go bad in quite the same way. But they smell as moldy as month-old potato salad when they do go bad. It’s a smell that a good project manager can recognize even in the finished and launched project.

For example, I bought a bagel this morning at a grocery store that recently revamped its customer-facing point-of-sale/card-swipe terminals – those devices where you enter your “customer card” number, swipe a credit or debit card, and occasionally sign for the purchase. You can spot the first generation of these easily enough because (a) they’re really, really slow and (b) they usually have scratched-up screens where some misguided customer signed with a ballpoint pen.

Some Problems the Project Was (I Hope) Trying to Address

The chain to which this store belongs has had four customer problems since they installed the first generation of these machines. By customer problems I mean those that are visible to and annoy the customer, that mitigate against the good customer service this chain is trying to provide.

  1. The machines take a long time before they are ready for your input.
  2. They’re slow, as if they were 20-year-old computers.
  3. They’re scratched up by ballpoint pens, sometimes almost unreadable.
  4. The cashier is instructed to thank every customer by name when possible (i.e., when they enter a customer card number so the system can identify them), but the effect is spoiled when the cashier says, “Thank you… (long pause while he tries to find my name among all the stuff printed on the long cash register tape at the same time as he’s folding it and handing it to me) …Mr. Levy.”

So for various reasons – e.g., slow, damaged devices – the chain has been replacing its customer-input devices with spiffy new ones. The new ones have brighter screens, pretty icons, and – at least so far – no ballpoint-pen damage. They also revised the software that runs them.

And therein smells the project.1

The new systems address only problems #2 and #3 in my list above.

What do those problems have in common that #1 and #4 do not? They’re purely mechanical problems, easily solved by “brute force,” as programmers say – faster processors and next-generation LCD touchscreens.

The Problem Areas the Project Missed

But they didn’t even think about the other problems – or if they did, the solutions didn’t make the cut. And so customers retain a low level of annoyance about the very things the supermarket chain is trying to stand out for.

  1. Ease of shopping? While a significant wait until the customer can start using the system may not amount to much if you’re buying a week’s worth of groceries, it’s an impediment when you’re buying one or two items. If you can’t start entering your information until both items have been rung up – and it’s usually about a two-item lag – then not only is the customer slightly frustrated, the customers in line behind that customer are affected. That’s not good customer service. It will occasionally cost the chain a bit of money, too, when they have to call an extra cashier to the register because the lines are backing up, as often happens unnecessarily in the morning when most shoppers are buying only one to three items.
  2. Personalization? That squint at the register tape and the accompanying long pause defeats the attempt to personalize the transaction. There isn’t even a pretense that the cashier knows you as a long-time customer when he’s clearly puzzling out your name from the tiny type on the register tape.

Both of these problems could have been fixed extremely easily, had the project manager seen them as a priority.

  1. Accept customer-card input as soon as the previous transaction is complete. The system currently waits until the cashier has started the transaction, followed by an inexplicable – and with today’s computer capabilities inexcusable – lag before the device accepts your input. Even if they can’t solve the lag problem (you’ve got to be kidding me, but I’ll give them the benefit of the doubt here), there’s no reason the machine can’t accept my customer-card input before the cashier rings my first item. I can make a convoluted theoretical pseudo-security case around someone else putting their customer number in while the cashier is away and then walking off themselves, but what’s the big deal? If there’s no cashier action for a minute or so, the information is discarded, just as it is if it’s superseded by another input. Oh, wait, if I forget to put mine in and someone else put theirs in previously between cashier appearances and then walked away, my potato salad purchase goes on the other customer’s likes-and-dislikes record and thus the system will offer her a coupon for potato salad next time she shops? Not likely to say the least, and who cares anyway? J don’t let me enter credit/debit card info without a transaction in progress; that’s data that matters.
  2. Display the customer’s name on a screen where the cashier can see it early in the transaction. Once the system has identified me from the customer number, the name is available. The chain probably doesn’t want to put it on the big display where others in the store can see it; that could have legitimate privacy concerns for some people (think Charlie Sheen or Thomas Pynchon). But with everything that this chain has spent on these new displays and systems, they could have put a small, inexpensive screen down low where only the cashier can read it, such as near the bar-code scanner. If they want to pretend they know their customers, this is a small price to pay for eliminating the silly fumbling with the register tape, to say nothing of the blank looks when the cashier finds a hard-to-pronounce name. If the little screen comes up “Mr. Mxyzptlk,”2 the cashier can simply say, “Thanks for shopping with us today, sir.”

Speculating on What Went Wrong

I am confident there was a detailed set of requirements presented to the developers. I am confident the business sponsor signed off on them. I suspect, based on experience, that the sponsor never truly read them.

The problem isn’t with the business sponsor. The problem is that the requirements in too many projects are considered the project “bible.”

Digression: The sage Hillel was asked by a smart-aleck student 2300 years ago, “Oh, great teacher, teach me the Bible3 while standing on one foot.” Hillel said, “What you find hurtful, don’t do to another. All the rest is commentary. Now go and study.”

The requirements document is commentary. The heart and soul of a project is some combination of Vision/Done statement/conditions of satisfaction/critical success factors. They’re called different things in different approaches to project management, but they refer to a common thread: What are the two or three things that will spell success to the sponsor or business customer4 when the project is complete? What does the sponsor see when envisioning a world where the project is successful?

That’s what the sponsor cares about. She’ll read that document — all five or six lines of it! — very carefully.

And that’s what everyone on the project should care about most.

Somewhere, in among all the other stuff that accumulated about this project, there should have been a focus on the shopper experience. Maybe it would have gone something like this: “Our shoppers will feel we care about them, that our first priority is their needs.” It’s not very specific; the specifics come later. But if the project manager and developers had been forced to compare every “requirement” against that statement, had been forced to consider the system under development from the shopper’s standpoint, it’s highly unlikely they’d have come up with a system that fails to address the two points I raised above.

It’s not a fail, per se, but it’s not a succeed either. The new devices are much easier to read, and they’re faster, so I’d give them a B- grade.

But not an A or even high B, because I still get angry as a shopper when I just want to buy my morning bagel and another item or two and the transaction takes noticeably longer than it by all rights should, time that comes out of my own meager allotment of minutes.

Why This Sort of Speculation Matters

Why should you, or I, care about this system? It’s unlikely anyone reading this article was involved with building it (though maybe it will eventually get passed to such a person); in any case, supermarket systems developers aren’t the target audience here.

Rather, it’s an exercise.

It’s about thinking like a project manager.

Look at the world around you. It’s full of systems that were project-managed: computer systems, transportation systems, buildings, lawsuits, mergers, compensation systems, and so on. When you have a few idle moments, such as riding the train back from work or standing on line at the supermarket, look at some of those systems with a project manager’s eye. Look especially at those that have recently changed, where you have a picture of before and after. What was the sponsor’s intent? What should have been the goal of the project? Where did it succeed? Where did it fall short?

Most importantly, why do you think it fell short where it did, or succeeded where it did? What could you as a project manager have done at a high level to make it better? Forget the details that you cannot see anyway; how would you have clarified the goals to get everyone on the same page, or what did the PM do that did clarify those goals?

It doesn’t matter if you’re right or not. It’s simply an exercise, for building up those project management muscles.


1I have no inside insight into this project. I’m looking at its manifestation and trying to deduce how and why they missed some key items.

2Pronounced “MIX-yzz-puh-TIL-lk” — but you’d have to have read Superman comics in the late 50s or thereabouts to remember that. I have no idea why this particular bit of utterly useless trivia has hung around in my brain all these years.

3Specifically the Torah: Genesis, Exodus, Leviticus, Numbers, Deuteronomy.

4I’m trying to avoid using the project-management term “customer” because in the example customer = shopper.

1 comment to When Projects Go Bad