They Acquired a Competitor for the Software User Base and Immediately Laid Off the Tech Writers Without an Exit Interview. Oops.
"What's cheap is expensive."
A couple of years ago we were contacted by the VP of Marketing from a software company for help with a "documentation problem."
The VP said that her company develops and supports health insurance claims management software applications. They recently bought out one of their competitors, primarily for their customer base. Our prospect said they originally had no intention of supporting the product with future releases, but they didn't want the existing customers to suspect it. There are several applications that do the same thing, and they could easily lose these customers.
The VP told us that the very first thing they did to cut costs after they bought the competitor was to lay off the competitor's entire technical writing department, without even asking any of them what they were working on. No knowledge transfer. No exit interviews. No nothing. The VP had opposed the layoff, but short-term gain had prevailed.
She said they now know that the competitor's technical writers had been in the middle of documenting the latest software release, which the customer base was waiting for. Apparently, the quality documentation was the feature that differentiated the just-acquired software from the competition! The documentation was the main reason that the users had chosen the competitor's product in the first place.
Worse, she said that although they had several large potential customers for the newly purchased software, these prospects were demanding to see the current documentation before they would commit to buying the product. It was at that point that she had decided to contact us for help.
Our prospect said that her company now realizes that they are going to have to continue supporting the application they just bought - at least for awhile - in order to retain the customers that came with it. The customers are used to getting regular updates to online help and other user documentation, and if they don't get it they'll go elsewhere. Her company now needs to finish the help updates as quickly as possible in order to retain the new customers, and close the sales that depend on the quality of the documentation.
Because nobody had interviewed the writers before they left, they did not know where the work was located on the network, what the status of it might be, or anything else about it. They had no idea how big the scope might be. The requirements were also complicated by the fact that the company planned to integrate the newly purchased software with their own. So not only did they need to finish documenting what they had, they also needed to start planning the integration development, which would require technical documentation and eventually updated online help.
The VP told me that nobody in the business or financial departments had thought of any of this before the purchase of the competitor's company. Now they're really in a bind, thanks to the short-term thinking. They made a pile of money up-front on paper by firing the tech writing department right after the new acquisition. Now they're about to lose the entire enterprise and millions of dollars as a direct result of this simple, common mistake.
We submitted a proposal with a very reasonsble quote for helping them out of their self-inflicted crisis. From the information provided by the VP, we estimated we could do the essential updates within a month.
The prospect finally called back a couple of months later, and said that our proposal cost too much money – we're talking less than $10,000 dollars for mission-critical, tight deadline work that might have required writing it all from scratch!
Instead of hiring us, she said, management had decided to give the online help development update work to a temporary secretary they'd located in their Toronto office, because "she had some free time".
Note: Just because someone can type does not qualify them as a "technical writer". Do you have any idea of the technical skills that are required to document software of this complexity in a context-sensitive online help system that is integrated with the application?
Our prospect's application is a web-based client-server front end with a relational database underneath, supporting U.S. health insurance claims. It's huge. It would have been a challenge for us, and we have experience documenting health insurance claims software! The Canadian secretary knew nothing about the U.S. health insurance system, and had submitted no questions or clarifications. The VP told me that the developers had also been wondering how the secretary was going to give them the updates for the online help without ever having looked at the application: they said they had no record of her actually logging into the system.
The last I heard of this shipwreck-in-progress was from the VP of Marketing over lunch several months later. She apologized profusely for putting us through the proposal exercise. She said that it had been "strictly a finance department decision" to go with the secretary instead of with us, based purely on the savings of a few dollars. The results? She said that on the day the online help file deliverables were due, she called the secretary, who told that she had "just accidentally lost all of her work in a computer fiasco". The secretary claimed she had lost everything.
How could this even be possible? The answer: they broke every project management rule in the book. The VP of Marketing had not been communicating with the secretary during the documentation project. (Where was the software project manager during this fiasco?) She was either content with the reassurances she was given by the secretary that the online help updates were fine, or else she wanted to exact revenge on the other managers for making such a stupid decision by letting the project go down in flames.
In any event, the secretary had apparently worked without any supervision. She had not provided any progress reports, draft outlines or draft contents for review, online help test plans, online help draft files, or anything else that would have given a manager some idea of what she was doing with her time. And nobody else on the project had asked for her work while it was in progress. They paid her thousands of dollars for doing absolutely nothing.
If they'd hired us they could have already been done. Instead, they went for the solution that was cheap up-front, and ended up paying several times that amount of money for the technical writing work, plus the additional costs of being behind schedule with the release. Not to mention the loss of those important sales.
And that's the last we ever heard about it.
Postscript: Fast forward a couple of years, to September 2010. I just read that this company has just been listed as one of the fastest growing companies in the world. They always did excel in looking good on paper. I'd just hate to be one of their customers.
A client once told me: "Mary, nobody's in business to run a company. The only reason anyone's in business is to sell their company." That was in 2007. That attitude may be changing. Still, even if that's true for you, and your primary business focus is pure financial gain and not the quality of your product or long-term sustainable growth, because that's going to be someone else's problem after you sucker them into buying it from you, wouldn't you rather keep all of the money instead of burning some of it away? Even if you're flipping businesses, small details – such as talking to the employees before you buy a company, or before you let them all go – can make a huge difference to the bottom line of your deal.
– Mary Ecsedy, 8/26/2010, Pittsburgh, PA
