Working With

Sufficient Data

In the late 1980s, I worked with a man who could add a column of five- and six-position numbers in his head. Not short columns—Mel could sum page-long and multi-page lists. His accuracy was astounding. You could run an adding machine tape on the same numbers, and his totals were never off. If they were off, it was a ten-key mistake, not him. I always thought that Mel was some sort of savant, but he was just a normal kind of guy; a guy who learned business without the aid of an adding machine. He had learned the skill of making decisions with limited data.

Mel’s trick was to add the first three number positions on the left and forget the rest. Mel called this the “rule of rounding,” under which the less significant numbers always worked out. His point was that in most cases, the numbers to the right of the first comma are usually insignificant to any decision. Yes, you must include them in accounting and banking, but for making decisions, they are unimportant. Mel’s rule allowed him to be as accurate as he needed to be. Mel was the CFO of his company, a company Mel and his brother Harry started from scratch and sold for over $400 million 30years later. The two brothers proved to be very good decision makers.

Mel was not opposed to using computers—he pushed the company to build an outstanding computer system. Mel and Harry worked with the managers and the folks on the floor to create an incredible point-of-sale-driven system. That system tracked what a customer bought, when they bought it, and in combination with what other items. The managers could look at sales data by item and see how much the company sold by store, by salesman, and by day of the week. Good salespeople could look at a customer’s sales history, and by looking at the items the customer bought, predict what they might buy next. The system calculated the stores’ inventory needs, sometimes using the current sales of project starter items to determine what levels of stock to maintain for items to be used in later projects.

This system did this magic in 1988, twenty-five years ago. It would run circles around some of the systems used today.

Prologue

I worked with Mel after he and his brother sold their company. They continued in their leadership roles after the sale, but only in transition as new managers came in. The new owners planned to grow the company from 12 stores to more than 30 stores. The supply chain process was one key area of focus, as management worked to convert from each store ordering from suppliers to a central depot structure. I was there to support that mission with the construction and implementation of a new DC.

The new managers wanted to replace the company’s home office system with a new system. They believed the old system, based on the same mini-computer the store systems used, could not support a large chain company. The new managers saw the need to build a corporate-level system supporting a centralized purchasing team and distribution center. The current systems only bought inventory for its assigned store location.

Management brought in the MIS wizards from Arthur Andersen (remember, this was before Andersen Consulting, before Accenture) to build a new system. The Andersen team quickly decided that the current Wang computers did not have the horsepower to support the mission, and recommended building a new corporate- based system from scratch, one that ran on an IBM mainframe computer.

Mel was not impressed. Still, he did not stand in the way of progress.

Quickly, Andersen systems analysts, project managers, and programmers came and settled into the client’s offices. The MIS team before the invasion employed only six people. When I arrived two years later to help the Distribution Center project, the development crew comprised over 30 people from Andersen, 10 people on the home team, and a few long-term transplants from the parent company. A year overdue and significantly over budget, the corporate system project consumed manpower and cash flow. With so much attention paid to the systems, other important projects requiring MIS support fell behind, generating tons of opportunity cost.

My project was one of many affected. A substantial part of my job was the slotting of the new DC, figuring out where to stock over 30,000 items. I needed data on the items, the movement, and the dimensions of the products. The task required data. The original estimate was that it might take as long as four weeks to get the data. The Andersen team kept saying the project was moving ahead in the status meetings, but I learned through back channels that after two weeks they still had not started working.

All we wanted was a direct data extract of a year’s worth of history. The Andersen team argued that it would be too much data, too big for the PC-based systems I would be using, so they should give us averaged data. When I asked them in the second status meeting, the fine folks from Andersen told us that the data extract had slipped and was still four weeks away. Critical path meant nothing to these people.

The Data Gorilla in the Midst

Tuesday afternoon, I sat with my client, Howard, and his bosses—the two brothers, CFO Mel and CEO Harry. Mel saw the frustration on my face as Howard and I covered the project schedule. The delays brought us to a point of major setback—we would miss deadlines if we did not have data in two weeks.

Mel thought carefully for a few minutes as Howard and I talked about different options, trading slotting accuracy for schedule. The room remained quiet for a few minutes after we finished. Harry looked at Mel, and Mel looked at a column of numbers on the page in front of him.

Mel said that every week of delay chewed up about $30,000 of opportunity cost and at least $75,000 in real costs. Missing the schedule was not an option. Then Mel turned to a bigger issue. The Andersen team had missed a deadline on forecasting the initial stocking levels for the DC. He thought that the risk was over $4 million in excess inventory. I sensed that the scope of my project had just grown larger with that statement.

Mel was pissed off at Andersen. He thought they were too concerned about getting perfect numbers. He started to describe a different way to get at the data, pulling it from the store systems. The more we talked, the more excited Mel got, and he began talking about a way to “show up those overpriced pricks.”

We talked about how accurate the data needed to be to get an adequate result for both the slotting and the initial stocking levels. Our challenge was the size of the data sets. They would be huge unless we did some consolidation. After thinking on it for a few moments, Mel and I talked about paying attention to just the numbers to the left of the first comma, leaving out the small dollars and super-slow movers.

After the meeting, I met with Julia, the store systems DBA. We mapped out how she could pull the store level sales, inventories, and on-orders for the whole chain. My plan was to match that data with the product dimension data set I had, and the PO pricing from another file that we had snagged out of her system. Early Wednesday afternoon, Julia handed me a set of 14 floppy disks with my data. That data was in the foxBase data tables on my Compac DeskPro before I called it a night.

It took all Thursday morning to write the code and run the report. I sat with Julia that afternoon, directing query data from her Wang databases to validate the results. Friday morning I handed Mel a report with three columns of numbers. The numbers represented, at category level, the total inventory the company needed to stay in stock, the inventory already in the stores, and the inventory that the company should order to stock the DC. At the bottom, I calculated the value of the inventory the company did not need to order.

Mel did not look at the bottom of the report. He ran his fingers down each column, and across rows, doing his mental magic. After about five minutes he let out a whistle and said that the total excess was over $5 million, higher than he’d thought it would be. I admitted that I was surprised too, and quietly checked with the buyers, who told me they had decided the DC would not open on time. To keep covered, they had increased the stocking quantities in the store systems and built up the inventory starting the week before.

The Sucker Punch

Mel had been a boxer in his youth. His slightly misshapen face alluded to his past, though most people did not know that he’d spent time in the ring as a pugilist. That time in the ring had shaped Mel’s strategic and tactical cunning in business. In an office fight, my money was on Mel.

The next big MIS project status meeting happened the Tuesday after we did our analysis. Mel and Harry usually did not attend these meetings. I knew that they planned to attend this one, but few others knew.

My quiet questions to the buyers had created a few ripples in the office grapevine. That Tuesday morning, Bob, the VP of Merchandising, came into my office and shut the door. He said the buyers had been talking about my report, the Andersen crew had heard about it, and asked how I could have figured out the inventory without any data. Nobody, except for Mel, Harry and Howard, knew that Julia and I had pulled the data from the store systems.

“Watch out,” Bob said. “Word is that the Andersen folks are gunning for you.”

I had expected that. They would be mad because they would not get to bill for hundreds of hours of programming. I wasn’t worried about it, since it was Mel and Harry who had given me the clearance to do the work. Heck, Mel and I had devised the formulas.

That afternoon, as predicted, the Andersen project manager appeared in the meeting, along with one of the Andersen partners. They’d brought the big guns. They started in even before all the participants had appeared, telling the president that I had pulled resources off critical work to do an unauthorized report. The Andersen folks did not know how I had done it, or the formulas we’d used; they were just guessing, and figuring they had the upper hand politically.

I sat and listened to the conversation, saying nothing. More people came in and the conversation continued between the Andersen partners, the project manager, and the company president. People watched me to see how I was going to react. It appeared to the group that I was not paying attention to the conversation. As I listened, I realized these guys did not know my name, and they were waiting for me to take the bait and start arguing with them. I decided to continue to ignore them.

That game went on until it was time for the meeting to start, when Mel and Harry walked in and sat down. The Andersen team did not know what to say, and before they could say any more, I started talking.

“Gentlemen,” I began. “I will now present the inventory plan that Mel and I developed.”

Epilogue

True to expectations, the Andersen crew challenged our methods, but they could not find fault in the logic. At last, the arguments focused on the validity of the data, and not the methods. We had them with that argument, because they had no way to refute the data we’d used. The meeting ended, and we regained our schedules.

Simple proves out. We did not have to have data to the nth degree, because there was no value in that degree of accuracy. Time was more valuable than accuracy.

I share this story whenever a client stalls on making a decision for want of more data. A decision is a significant emotional moment. Data helps, but will not make the decision. A decision comes when the strength of confidence and a fear of not making a decision in time overcome the fear of making a mistake. While logic does come into play, it is a weak player on the field.

More data does not help. The art is making sure you have sufficient data to be confident of the outcome, and then making the decision swiftly.

Search All Topics


Articles in This Series

 Call Us! 877-674-7495       info@dksco1.com