Month: January 2019

This is the sentence spoken in more small business offices than almost any other. Her name, be it Marge, or as in my experience, “Lucy,” “Anne,” “Ellen,” and “Diane,” means the one person in the office who knows where “that information” is kept.

If you’re not hands on with data management, do not work in a Fortune 500 company, and have been in business for more than twenty years, you probably rely–to some extent–on Marge.

As an industry modeling contractor for McKinsey, I went on-site at many companies to collect data. Usually, a higher-up at the client would tell a senior VP to meet with me. I’d start out enthusiastically, asking what they did and how they did it. Ten or fifteen minutes in, the increasingly uneasy VP would call in “Marge” to answer my questions. Marge was his assistant. She did all the work. She kept all the records. If she was born before 1970, her records were all in ledgers and binders. If the company was big enough, they had a mainframe with legacy custom software that only she knew how to use. For all intents and purposes, the data was inaccessible.

When I was a manager at Yale University Press, it was Annie who had all the answers. If anyone needed any information, Annie knew it. Her memory was astounding, being able to recall titles, authors and editors going back decades. Knowing they wouldn’t be able to rely on her for the rest of time, YUP decided it needed computerized records. They hired a “Developer,” to build a custom mainframe database in 1995. By 1998, when I arrived, the “system” had cost the press more than $300,000, not including ongoing consultation fees, but it simply didn’t work. When the Editorial Director needed some publishing and sales numbers, I asked him where I should pull the data from, he said, “Ask Annie.” But instead of trying to pull up out-of-date information in query form from the maddeningly slow and defective database, Annie gave me a box of stacked MS Word printouts for each book with sales figures neatly hand-penciled on manila folders. I asked her if there wasn’t a better source of this info, and she said “Absolutely not.”

I know my father had relied on a “Marge.” Lucy was in her mid 60s when I started at my family’s business in 2000. She kept records in card catalogs, filing cabinets, chronological notepads, alphabetized or chronologized. She used a computer for word processing. For each new contract, she would copy the boilerplate text, hit “enter” a few times until she came to a new page in Microsoft Word, then paste. The “contracts” file was more than 300 pages long when I first looked at it. Every time I asked a question, the answer was “Ask Lucy.”

Of course, the threat of relying on “Marge” is that if she gets hit by a bus, who’s going to pick up the pieces. Vital information, important processes, key contacts all disappear into thin air. In 2004, Lucy suffered a triple aneurysm and her ability to write and speak was greatly diminished. We couldn’t tell if she was also cognitively impaired, so the business just limped along. During this period of time, I spent many long nights at the office extracting data from her files so that were the worst to happen, we would still know what was going on, and what had happened in the past. Lucy died a year after her aneurysm. If she hadn’t shown me everything about her system, our business activity would have been effectively erased.

Structuring your data in a coherent way is of vital importance to your business. Not just for analysis, but for record keeping, purchase orders, shipping records, sales, and so much more. Even if you’re not ready to employ Robotic Process Automation or AI in your business, how you keep your information may affect ways you can improve your business in the future.

This was the cri de coeur of my boss at Yale University Press.

I had been made Acquisitions Manager at Yale University Press, at least partly, on the basis of my experience as a data management contractor with McKinsey & Co. At McKinsey, I’d worked with large multinational corporations whose databases included hundreds of thousands of strings. I used Paradox, one of the most robust relational database management programs available in the mid-1990s, to break out useful data for analysis.

When I arrived at Yale in 1998, they had recently contracted with a “Developer” to build a mainframe resident database to keep track of the whole of their publishing process. SAP’s Industry Solutions for media was more than two decades away, and the custom solution had already cost YUP more than $300,000. The “Developer” was a big, combative, teary guy who’d somehow managed to learn programming. Sadly, he wasn’t very good at it. On top of that, a glitch in the wiring caused the interface to be maddeningly slow. Forget deploying a query (which the developer would have to write) to generate a report, entering a single datapoint could often take as much as three minutes.

I’d been instructed to work with the developer, figuring out how to get the expensive system to work and hopefully generate some useful information. When I asked the developer how many data rows (books that had been, or were being published) were in the database, he said “almost a thousand.” A thousand rows, no matter how many fields there might be in a row, shouldn’t have merited a mainframe solution. I would have managed that in an Excel spreadsheet. But someone very high up at YUP, someone who knew nothing about computers or data, had met with a vendor who’d promised–I don’t know what.

In a number of very uncomfortable encounters, I discovered that the “developer” didn’t know how to extract data from the mainframe, even in a CSV format. My level of stupefaction at the vendor’s incompetence was so great I could barely express my disgust to my boss. “What the hell is going on!” he demanded, again and again.

I appealed to the office “Marge,” Anne Richardson, to help me out. She gave me boxes and boxes of typewritten (MS Word) summaries of each book that she’d prepared so the data could be put into the mainframe. She’d also kept up-to-date production and sales information penciled on each title’s manila folder. When I asked about marketing budgets, she referred me to another woman in the marketing department. The design department, it turned out, also kept a set of files on money they spent on contractors. Then it was down to the basement to visit accounting. They gave me their information in Excel spreadsheets, which was very useful.

I spent a week concatenating all this data in a local Microsoft Access database. I knew how I wanted the data structured so it didn’t take long for me to simply re-key it all.

Over the weekend, I did some rudimentary number crunching that I thought would be of value. I met with the Director, the Editorial Director, and the Editor in Chief on Monday. Because I’d heard a general figure before I began my work, I asked them how many books they’d published the previous year. Their answer was off by a factor of ten. As I began to lay out all the data, pointing out fields that sold more than others, editors whose lists were remarkably thin, the relative costs of marketing or designing a given type of book, the Director’s eyes lit up. “That database was worth every penny.” Fortunately, the Editorial Director took the blow by explaining that I’d had to completely circumvent the mainframe to put these reports together.

But because of the sunk cost fallacy, the Director refused to believe his mainframe was worthless. By the time I left Yale two years later, the “developer” was still in the basement, sweating and swearing, promising things that would never come to pass.

If you or your boss has invested in hardware, software, or data management processes that just aren’t working out, don’t perpetuate the mistake–despite what the vendor is promising. Go back to the drawing board to figure out what you wanted to do in the first place, and what’s available now that can help you achieve your goals. That’s where ATC can help.