I had some experience with programming IVR (interactive voice-response technology), so I was put in charge of writing the code that connected customers with associates working in specific departments. Callers would get a voicemail menu, and they'd press a button on their phones to choose the department they needed to reach. The IVR would look up the phone number, call the sales associate's cell phone on the retail floor, and connect the two lines when the associate picked up.

As usual, everything took longer to develop than expected. But since the head office insisted that we roll out on schedule, we picked up time the only place we could: We reduced testing. My team was a bit ahead of the game, so I managed to verify that the system would actually connect one outside line to one internal cell phone under ideal circumstances. I wanted to test for less-than-ideal circumstances. But before I could do that, we had gone live.

It didn't take long before we began encountering problems. Some callers would be put on hold forever and then they'd be disconnected; other customers would be connected to the wrong department or even the wrong store. Luckily for me, the code I had worked on generated some of the least visible problems. At least at first.

Then I began hearing complaints from sales associates about a 10-second delay in making a connection after the associate answered the call. Ten seconds may not sound that bad, but for a telephony system it's a lifetime -- especially when you're standing on a retail floor trying to answer the phone and deal with live customers at the same time.

I brought this up this during one of the first emergency meetings called to address the problems that had arisen with the call center. But management didn't seem to think it was that important. My boss placed this issue so far to the bottom of my priorities list that I could never get to it. I always seemed to have bigger fish to fry.