Seven Tips for Living with Technology

By Richard Hamilton, special to The Content Wrangler (reprinted with permission)

“If the only tool you have is a hammer, you tend to see every problem as a nail.”—Abraham Maslow (1908 - 1970)

When most people purchase a new car, the experience goes something like this. They start out with high expectations; they want a convertible SUV that will carry a family of six, look and drive like a Ferrari, cost less than a Yugo, and get 50 miles to the gallon. The initial search and test drives deliver the first splash of reality, but overall the experience is exhilarating. They try out nice clean cars with lots of bells and whistles, and gain a new best friend, their sales person.

Sticker shock sets in next, but with the help of their new best friend, they work through the pain and bring home a brand new vehicle. And that vehicle remains perfect in their eyes until they take the family on vacation and discover they can’t fit everyone in the car unless they strap the dog to the roof, and that “30 miles per gallon on the highway” only applies going downhill with a tailwind. I could drag you through the stages of grief, but let’s skip to the chase; if they’ve got a lot of money, they go back and find a car that fits their needs, and if not, they learn to live with what they’ve got.

A lot of organizations go through the same sequence when they acquire technology. They start out with unreasonably high expectations and without a clear idea of what they really need. And, they end up with technology that they either throw away at great cost in dollars, or learn to live with, at great cost in productivity.

After living through more than a few technology acquisitions, variously as perpetrator, victim, and bystander, I’ve come across a few tips that can make the process a little easier.

Understand your requirements: This one should be printed in bold, red letters. You can avoid most serious problems if you simply take the time to understand and document your requirements based on your business needs.

A requirement based on business needs is one that a customer will care about. If you say, “All content must be available to our customers on the Internet in HTML and PDF,” most customers will understand and care. In the same way, if you say “The technical communications group must reduce expenses by 10%,” customers will care, as long as it reduces their costs, too.

However, statements like “All content shall be authored in XML,” fail this test; they don’t say anything that a customer is likely to care about. Unless a requirement directly addresses a business need, or you can clearly connect it with one, remove it. In this particular case, you may find that a business need for HTML and PDF on the Internet, combined with a business need to reduce cost, leads you to authoring in XML, but it might just as easily lead you to authoring in Microsoft Word or Open Office. The only way to know for sure is to start with business requirements and work from them towards the technology, rather than the other way around.
Not every problem can or should be solved with technology: If you spend enough time with technology vendors, or if you work for one, it’s easy to assume that technology will solve any problem. It would be nice if that were true, but in fact, many problems are best solved without technology. Often, you can get better results by changing your processes, improving the structure of your content, or training your team to be more effective. And, even when the application of technology is appropriate, you will benefit from having looked at and improved these other factors.

Because of the cost of acquisition, and the ongoing costs of training and maintenance, the bar should be set high for the introduction of new technology. Make sure the benefits are weighed against the costs before you dive in.
Technology must follow, not lead: Anyone reading this article is at least familiar with XML, content re-use, CMS’s, DITA, DocBook, and other trends. And, if you spend enough time immersed in the hype, or even if you just go to a conference or two, you’re likely to feel the urge to go out right now and buy an XML CMS to leverage your re-usable content and single-source your way to documentation heaven.

If you follow that urge, you’re letting the technology lead. That doesn’t mean that an XML CMS isn’t cool technology, or that it isn’t right for your needs. But, if your biggest problem is something other than content re-use, or if you’re not sure what your biggest problem is, then it is premature to be considering an XML CMS, or any other technology.
Keep it simple: To paraphrase Einstein, “Technology should be as simple as possible, but no simpler.” The best technologies are like the best managers, they provide an environment that supports your needs with minimal distractions.

You’ve probably heard this saying among writers: “The strongest human urge is not love or hate, it is the ~~compulsion~~/need to ~~edit~~/redact someone else’s words. “Software engineers have their own affliction, ‘Feature Creep,’ which is the constant accumulation of features in a software product over time. The result is that nearly any mature product will have more features than you’ll ever use.

The same thing can happen as you define requirements for a new system. A common, but faulty, process is to draw up a “wish-list” of features. Not only does that put technology in front of business needs, it nearly guarantees that you’ll end up writing requirements for more features than you’ll ever use. A better process is to go back to your business needs, prioritize them, and build your requirements with explicit priorities. You can then manage both the cost and complexity of the system.

This can be difficult, because feature creep practically guarantees that once you start looking at specific products, you’ll find a lot of “nice to have” features that come bundled with the product. Resist the urge to bring those features into your solution. Even though they may seem “free,” they aren’t because they:
- divert attention from features that you are more likely to use
- make solutions more complex and expensive
- make training more complex and expensive
- distort the selection process with factors that should be irrelevant
Take advantage of the broader community: Any technology you’re likely to be using will have a community of users outside your company. Look for news groups, wikis, message ...