It Ain't Over Till It's Over

I have this sign the people in the LMB marketing department made for me a long, long time ago. It hangs today in my home office.The story behind it is contained in the column below. I wrote this in October of 1998 and it originally appeared as a guest column for an on-line community no longer around.. Here is a reprint of that column exactly as it appeared back then. The story may be old, but the moral holds true even today.

Hanging in my home office today

Prior to my current position I was a partner in a small consulting company. Corporate folklore at my previous company included a discussion between a programmer and his manager. The story goes something like this: Norman the manager asked Sam the programmer for a status report. Sam proudly announced he was done. Norman had been around long enough to know that programmers always think they’re done long before they've actually finished the job. So Norman inquired further. Sam again insisted he was, in fact, done. He had written the program. He had typed it into the computer, compiled it, linked it, loaded it and ran it to completion. Sam added that since the output was wrong, he couldn't turn it over yet; nonetheless, he had finished the program.

The moral of the story is pretty clear. There is a tendency in IT to underestimate or sometimes completely overlook the final step in a project - delivery to the end user.

As a manager, I frequently remind my staff of the importance of having users confirm that any assignment is complete. My rule, printed in large letters and posted on my office wall, reads “It’s up when the user says it's up.”

This philosophy was reinforced during an incident with Ralph, our assistant treasurer. This is the guy who sends time-critical information via modem to the bank each day. When the transmission failed one day, near panic set in. An IT technician was dispatched immediately and quickly determined the problem. Hardware parts were obtained and installed. The PC’s communications abilities were thoroughly tested, and the equipment was deemed healthy again in record time.

I knew this because the technician, grinning from ear to ear over his electronic triumph, proudly reported the news to me. “Everything is back to normal, operating better than ever,” he stated. Apparently, the modem card connector was snapped off when the computer was moved to retrieve a piece of paper that had fallen behind it. The broken card was easily replaced with a new one, restoring the computer to operating condition. “In fact,” he went on to explain “the new one was a brand new 56kb x2 model capable of much higher speed than the old 9600 baud model.” “Well, what did Ralph think?” I asked. “Oh, he was at lunch,” came the answer. “I see, then how did the new modem fare when you tested the banking application?”

At this point, the technician wished he hadn't been quite so quick to report to me directly. He had to admit he knew nothing about the banking application. But he had tried several online services and a few bulletin boards. “Boy, is that baby fast,” he said.

Before I could send him back downstairs to see Ralph, Ralph called me. He wanted to know when his PC was going to be fixed. You can guess what happened when the technician, still beaming from his favorable test results, met with Ralph - still waiting to send instructions to the bank. It wasn't a happy ending. The bank required a particular modem with very specific settings, a few details that the technician overlooked.

When we eventually obtained, installed, and tested the right equipment, I suggested the technician take heed of the sign on my wall. Come and tell me you are done after Ralph tells you everything is okay.

This problem occurs in software development as well. IT professionals are very creative people. They invent incredible solutions to very complex problems every day. They fix databases, repair old applications and provide new capabilities. But just before I cross any item off my list, I always ask how the users received the solution.

You don’t really know whether the data have been adjusted, the screen changed, the new function added or the process modified correctly unless the people who use it day to day confirm this.

Remember the rule. It’s up when the user says it up.

Captain Joe

Follow me on Twitter @JPuglisiLLC