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 boards, user groups, and mailing lists for any tool you’re using or considering using. If you can’t find a group of people actively using a technology, consider that a red flag (see the next guideline).

Once you’re linked into a community of people using the same technology, you’ll have access to information and people who will save you a lot of time and frustration. Among the best examples of this are the communities that have built up around the DocBook and DITA XML standards. Both have mailing lists, web sites, wikis, and other resources that are regularly monitored and updated by experts.
Avoid orphans, old-timers, and newborns: Avoid products that no one is using, are past their sell-by date, or are brand new. You want a product that is mature and evolving, with a strong and growing user base. This isn’t hard to spot; just spend a little time on the web. The clues are an enthusiastic group of users that responds quickly on user groups, more discussion about how to take advantage of the product than discussion on how to avoid problems, active participation by the technology’s developers, and productive discussion about future releases.

While it’s pretty obvious why you should avoid the obsolete and orphans, it’s a lot harder to resist new technology. But, even if it looks like it will cure cancer, feed the poor, and eliminate bad breath, you don’t want to be an early adopter unless you’re experienced in adopting new technology, have the internal expertise and time to shake out problems, and have a real need for that specific technology. Otherwise, let someone else take the hits and wait for the technology to mature.
Garbage in, Garbage out: This one applies particularly to Content Management Systems, though it could apply to other technologies. If you don’t have well-structured content and good processes, no technology will save you. If your processes or content are a mess, you need to get your house in order before implementing a new technology.

I once worked with an organization that had, to be charitable, a “fluid” workflow. Their processes were ad hoc and chaotic. They became convinced that the solution to their problem was workflow management software, and they lobbied hard and successfully for that feature to be included in a CMS being acquired by their parent organization. However, they neglected to change any of their processes and stuck with the unrealistic expectation that workflow support would be a magic bullet. They are still mired in the old processes, and the software has had no measurable effect on their productivity.

In practice, technology is an amplifier. If your content is well-structured and your processes well-defined, applying appropriate technology will let you operate more effectively and efficiently. If your content is garbage or your processes are faulty, technology won’t help; more likely, it will be a costly distraction.

In the end, the keys to living with technology are to understand the business need you’re trying to satisfy, have a realistic view of what technology can and can’t do for you, and approach any new technology with caution. I can’t guarantee you won’t suffer some buyer’s remorse; even a Porsche loses a little luster over time. But, you’re less likely to have to strap the dog to the roof.

About the Author
Richard Hamilton is principal consultant with R.L. Hamilton & Associates, specializing in documentation management and the application of XML technology to documentation. He has managed documentation teams at AT&T, Novell, and Hewlett-Packard. His teams have developed technical documentation for Unix and Linux systems, web-based applications, and many other software and hardware projects. He also has led development teams, including a team at Hewlett-Packard that developed a DocBook XML-based environment that delivers print, web, and online help content. He has been a member of the DocBook Technical Committee since December, 2001, and is a contributing author to the DocBook 5.0 Transition Guide. He is currently writing a book about managing documentation; excerpts can be found at: http://rlhamilton.net/blog

Filed under: Technological Innovation