15 Expensive Mistakes Managers make in Developing Business Documentation.
Mistake #1. Delegating the job to someone who HATES to write.
Someone who hates to write will do a poor job.
Mistake #2. Delegating the job to someone that WON'T write.
Many people won't document their work. They believe this to be "job security." They think they're secure if no one else can do their job.
Or, regarding product documentation, they say they're "just too busy" to write. They delay the writing until the last minute then do ANYTHING to avoid the writing.
Mistake #3. Delegating the job to someone who CAN'T write.
Everyone knows that most engineers and programmers can't write human-readable materials. Sometimes they WILL write. But, they sometimes resist those who try to change it to a human readable format.
Mistake #4. Delegating the job to a "power-user-tool-buff."
As you know, the market for high-powered Desktop Publishing Systems is chaotic. Software developers race to develop new features for the next release. The market is increasingly driven by sophisticated affordable hardware with vast memory and bigger/faster disks.
Power Users want the latest. Regular Users want less change. Managers want faster adjustments, fewer delays, and lower costs.
Vendors position new DTP tools as "productivity tools." But, many become labor-intensive time-wasters and labor-cost accelerators! Today, you can buy some "productivity tool" for under $1,000. But, it might increase your labor costs $25k - $50k per year, due to built-in inefficiencies.
BEWARE! Industry analysts score the machine speed, NOT USER SPEED in real-world applications!
Caveat Emptor. Sometimes feature lists do NOT add up to a cost-effective productivity tool. Instead, you could wind up with an expensive time waster, where the TOOL COST is trivial when compared to the REAL COST of using it!
Mistake #5. Delegating the job to a "committee."
I have often seen management give advertising projects to a committee of employees.
When you compare advertising with other business documentation, advertising has few pages. Thus, a "committee" can spend the afternoon(s) "voting" on every word.
For example, in 1988, I was referred to a company that had, in desperation, mailed about 200,000 committee-derived brochures to untested lists of librarians... You see, they had a warehouse of unsold, and dated directories.
Response to their mailing was so small it could hardly be measured (about .0004%). Worse, buyers bought on credit and were delaying payments for 90-120 days. Expensive mistake!
I asked if they had done market research.
To make a long story short, I performed some basic market research by phone.
The Marketing VP and I reviewed the results. At his suggestion, We divided the market into 5 segments.
I then wrote a separate direct mail package for each segment.
The result? They cleared the warehouse, selling $7.4 million worth of directories in four months - cash-in-advance. (And I wish I had done the job on commission!)
When you write ads, every word counts. And you shouldn't have a committee vote on the materials. Instead, you must test the copy and let the customers vote with orders.
Most committee-writers have narrow departmental experience with little or no experience in writing effective ad copy.
Mistake #6. Delegating the job to a secretary, "go-fer," or anyone else who's interrupt-driven.
"Oh, this is an easy job... I'll just have my secretary write the ads, press releases, and product bulletins." Constant interruptions guarantee a hasty compromise of poor quality.
Mistake #7. Delegating the job to majors in English, history,journalism, sociology, drama, political science, etc.
Typically, these people are not properly trained to create effective process-oriented business solutions.
If you need technical documentation or business process documentation, look for writers trained in exact sciences (math, physics, music, programming, etc.)
Mistake #8. Assuming the writer must be an expert in your field.
When I first visited one potential client, their 800# was ringing off the hook. Whenever customers had questions, they would simply call the 800# because they couldn't face trying to decipher their documentation.
To solve the problem, management wanted a radiologist to write the User Manual for their new flagship product. They figured only a radiologist could understand what doctors' and radiologists' needed.
I risked losing the account by mentioning that they employed many radiologists and still had second-rate documentation. For whatever reason, they gave me a chance.
I knew nothing about radiology. But, I had a SYSTEM for working with subject matter experts. Here's what they wrote to me after I developed their User Manual.
Mistake #9. Not writing stuff down in the first place.
"We don't need to write stuff down. Everyone here knows what they need to know." I call this approach "management by tribal knowledge."
Tribal knowledge stifles a company's growth. (I discuss the problems of tribal knowledge in Profitable Venture Tactics issues 5, 8, 13, 14, 15, 17)
Mistake #10. Starting too late.
"We will start after we're done. We really can't write anything down until AFTER we're done with the project. How could we possibly know what to write in advance?" I have found that starting too late is a very common problem.
Mistake #11. Not planning the writing project.
A while back, I had a client who was a major contributor to Hong Kong's huge Aberdeen Tunnel Project. For 2-3 years, they developed complex control software.
Their contract specified that they would provide detailed documentation. But, the programmers delayed the writing, refusing to write documentation until the software was done...
...But, then the programmers acquired new jobs with a competing company, leaving the client with undocumented software.
But wait! It gets worse, see Mistake #12 (next) below.
Mistake #12. Trying to fool the customer with inadequate documentation.
(Continued from 11 above.)
The client tried to get their customer to accept an alphabetical listing of machine language programs and subroutines as "detailed user documentation."
The customer in essence said,
Did the client begin writing the documentation? NO!
Instead, they flew lawyers back and forth to Hong Kong to try to force the customer to accept the machine code listing as user documentation! They argued for 18 months without resolution. (Imagine the expense, the aggravation and lost credibility.)
In desperation, they called my company. It cost them another $50,000 to develop acceptable user documentation. (Cheap compared to flying lawyers around the world!)
Mistake #13. Not knowing how to interview subject matter experts.
Your standard operating procedure should include:
Why? You will save MUCH time and aggravation!
Mistake #14. Not knowing how to estimate the size of the job.
You must use a SYSTEM for estimating - and a SYSTEM for monitoring progress.
Mistake #14a. UNDER estimating.
Some people underestimate by trivializing the job of documentation. They typically start late without necessary resources. This approach always stalls product delivery, business development, and cash flow.
Significant problems occur when you delay the documentation process until the end of the product development cycle. You'll ALWAYS find product errors during the documentation phase - no matter when it occurs.
Mistake #14b. OVER estimating.
Some people overestimate to be on the safe side. A recent client hired a contract writer to work on a specific project... Nine months later, the only documents the writer had created were planning documents and CYA memos full of excuses and delays.
He blamed his lack of progress on the programmers.
In frustration, management gave me the job. I trained the recalcitrant writer to use my SYSTEM. I supervised progress but did no writing.
The job was done in three weeks!
Mistake #15. THE MOST EXPENSIVE MISTAKE IN DEVELOPING DOCUMENTATION
The MOST expensive mistake is NOT having a SYSTEM to help you develop your documentation.
Your SYSTEM must give you precise details for managing your publication cycle from planning & research through writing, reviews and publication.
Many companies have a system for producing beautiful looking documentation. But often, the technical content leaves much to be desired.
Your SYSTEM should include DOCUMENTED PROCESSES for the following:
Do you suffer any of these frustrations?
We find several frustrations plague managers these days:
We've created an exceptional SYSTEM for developing documentation. It yields exceptional results at extra low prices. And, it gives the results Management wants: relief from pressure and worry.
We call it the Documentation Express SYSTEM. It relieves all these frustrations in one fell swoop. How? It's the SYSTEM that works. It doesn't depend on me. It doesn't depend on some Home Office genius. It doesn't even depend on our people.
It depends on our SYSTEM that works every single time. It has worked for Intel, Bank of America, Applied Materials, IBM/Rolm ... plus dozens of other companies like yours from Toronto to Hong Kong!
We've refined the system over 300 projects in Silicon Valley. More than a documentation solution, it's a practical business solution.
What does it cost? It depends on your situation. But, it will cost something. Here's the real question. If we could solve your documentation problem ... if we could ease your frustrations ... are you ready to act?
Yes? Call or send me an email.
Mike Hayden, Principal/Consultant, Your partner in streamlining business.
PS. To receive the latest Profitable Venture Tactics eZine (free) click the button now.
We take the pressure off.
| Home | Who we work with | How we work | Client Services |
| Client Results | About Us | Contact us |