Why Documentation Matters,

and Why Outsourcing Makes

Sense

November 2003

Written by Rob Webber

Edited by Jose Druker

Here is the good news. Your development team has been highly successful. In record time,
they have added feature upon feature to your already impressive product, arming you with a
bankable beauty destined to win acclaim from critics and customers alike. Design is smart.
Functionality is robust. And sales projections are, shall we say, sunny.

Market launch arrives and the news remains positive. Promotions and campaigns go well,
reaching target audiences with real resonance. Lines are growing long behind cashiers
scanning codes to your product. Inventory is dropping faster than the NASDAQ in 2000,
and salespeople can’t pause long enough to calculate their bulging commissions. Against every
ounce of caution you can muster, optimism will not subside.

Then comes the bad news. Despite smart design and robust functionality, customers are
struggling to use your product. They can’t assemble it. They can’t install it. They can’t figure it
out. Instead of seeing value, they feel frustration.

What went wrong? Though you wisely researched and developed, and though you delivered a
better product with more features to more customers, you didn’t invest in the one thing that
could tell customers what all the fuss was about: documentation. That one oversight opens the
door to your worst-case scenario, the one where a customer picks up your guide, leafs through
it, gets fed up, and packs it away. Right beside your product.

In a world where technology and innovation refuse to rest, the following rule increasingly
applies: The more complex your product, the more important it is to explain how your product
works — clearly, completely, and accurately.
If you fail to do this, fate will not be kind. Customers will leave, reluctant to return or worse.
Those who stay will grow irritated or even disillusioned. Many will fail to find and enjoy key
features, diminishing the benefit they derive and the value they perceive. An alarming
percentage will transfer their negative feelings about your documentation to your product, and
ultimately, your company. They will look and see a company that cuts corners, that doesn’t
sweat details, that doesn’t take quality seriously in all things. In short, they will see a company
that just doesn’t get it.

Correcting this problem starts with understanding. Companies must understand that
documentation is not a complement, a bonus, or a throw-in. It’s essential.

2
Jay Mead, in “Measuring the Value Added by Technical Documentation” (1998), puts it this way:
“Information development is moving away from its traditional role as merely a supporting add-
on.…Information is properly seen as a product itself, with its own costs and benefits.”

About this white paper

This white paper poses two main points. The first is that documentation matters because it can
impact sales and reduce operations costs. The second is that outsourcing documentation
makes sense for many companies because it supplies a broader skill-set and supports greater
operational flexibility. Before taking up these points, let’s pause to offer a working definition of
“documentation”.

What we mean by “documentation”

In your mind’s eye, what do you see when you hear the words “documentation”? A row of thick
manuals with cracked spines inside a cubicle cabinet? A shrinkwrapped user guide inside a
cardboard software box? If you see something physical, something that resembles a user guide
or a reference manual, something that takes the shape of an old-fashioned, paper-based
“book”, you’re not seeing the complete picture.

While the standard book is still for sale and plenty popular, new electronic documents
increasingly crowd the shelf. In fact, these electronic documents form the largest and fastest-
growing sector in the documentation universe. Take Help files, which almost no software
application can do without. They can be on- or off-line, part of an application or standalone,
context sensitive or user driven. Take PDF files, which enable users to easily convert common
files into portable, platform-independent, electronic documents. Take XML files, which can be
formatted through Extensible Style Sheet translations, integrated with Flash content, and
generated dynamically through a Content Management System. These electronic files can be
downloaded to a laptop, a PDA, an eBook, or even a cell phone, and produced from a single
source, without rewrites or reprocessing.

Given this new reality, how should we define documentation? If we remove the medium, as we
should, the answer becomes this: documentation is any written information that explains how to
use a product or service.

3
Part 1: Why documentation matters
Reading between the bottom lines
Let’s return to the opening scenario and to the annual meeting that would have preceded
market launch. The CEO, flanked by heads of marketing, sales, development, and finance,
strolls through slide show and flip chart, painting pictures that arc from renowned past to rosy
future. Later, during Q&A, someone reads off a hand-written question that pertains to
documentation. With a smile and a thank you, the CEO promises an email within days, and then
turns to an assistant with an eyebrow lift that can only mean “Take care of it. Please.”

This scenario is not so far-fetched. In too many organizations, documentation has indeed borne
a lowly profile. Too many times, executives have failed to recognize documentation’s potential
to benefit employees, customers, and ultimately, bottom lines.

The following sections unveil this potential, starting with documentation’s capacity to strengthen
sales by influencing buying decisions. Next, we show how internal documentation can increase
internal efficiency, which, in turn, can lower operations costs. Then, we explain how customer
documentation can decrease post-sale costs. Following that, we present ways to spend less
and get more from your documentation effort. And to conclude, we explore the relationship
between documentation, training, and call centers, showing how one — documentation —
supports the other two.

The sales drive you might not expect

Has anyone ever purchased a product strictly because it included excellent documentation?
Not too likely, and not according to any known studies. But try this question instead:
Has anyone ever refused or returned a product because it had poor documentation?
The answer here is somewhat different.

Researchers have offered compelling arguments to show that documentation can increase
sales and customer willingness to pay more for the product. For example, individuals and
companies regularly evaluate the cost and quality of documentation during the buying process.
This evaluation can and often does impact sales, positively and negatively (Mead, 1998).
Furthermore, many product reviews rate documentation separately from the related product
(Mead, 1998). Again, this suggests that documentation matters to buyers.

4
A study by Smart (1996) shows that perceptions of product quality are tied to perceptions of
document quality, and that documentation can become a differentiator. This is especially true for
companies that are new or sell new products, where customers may hesitate to purchase.
In these cases, documentation can add credibility by saying to the buyer, “I’m real”. That,
in turn, can trigger purchase.

If you’re still skeptical about documentation’s value, Mead (1998) reminds us about those
“Dummies” books hoarding shelf space at your local book store. These after-market books, with
their steep price tags and strong sales, attest to the value of documentation. If customers really
didn’t care, they wouldn’t buy these books.

In the future, documentation may increase sales indirectly, by helping companies better identify
and satisfy target markets. Here is how. When technical information transitions to the Web,
companies can capture hard data on which blocks are being read, and who is reading them,
impossibilities in the print world. Additionally, companies can use on-line systems to capture
direct feedback, such as defect reports and personal opinions on information completeness,
accuracy, and usability. In other words, documentation can itself become a source of new data,
which can be mined to polish development, marketing, and support programs.

Internal documentation leading to lower operations costs

Sometimes, it’s easy to forget that internal documentation is integral to every member of an
organization. But think about it. For almost everything we do at work each day, there is a
standard, a guideline, or a process to follow, or particular customer, product, or employee
information to access. If we must search too hard to find it, or work too hard to understand it, our
productivity suffers. On this point, the case studies speak clearly.

One researcher, JoAnn Hackos (1995), saw the high cost of low-quality documentation at
Federal Express up close. Her 3-year study revealed a loss of $3 million per month in
unproductive time due to poor internal documentation. Federal Express, acting on her report,
revamped their documentation and realized immediate savings. According to their own analysis,
Federal Express saved $400,000 per year from one item alone: improved employee search
time.

More evidence arrives from eHelp Corporation. In a recent paper (eHelp Corporation, 2003),
they cite a leading consulting firm that converted employee and customer data into Help files

5
and placed them on their intranet to reduce search and access time. Over a 3-year period, the
net savings added up to $22 million.

Finding more proof that doing documents well can increase internal efficiency is not difficult.
In Australia, the Victoria Government rewrote one legal document and saved $400,000 annually
in staff salaries (Schriver, 1993). At the Southern California Gas Company, a billing statement
was simplified, and the annual cost of processing customer enquiries dropped by $252,000
(Schriver, 1993). This type of pay-off is not unusual. It only makes sense that when you help
employees do their jobs more efficiently, you save money.

The path to lower post-sale costs

Post-sale costs come in many colors. Among them, count complaints and returns, support calls,
training costs, and litigation. Depending on the product and company, these costs can become
quite impressive. To provide one reference point, in 1997 Microsoft put the cost of a single
phone call to a Help desk at $20 (TechScribe, 2003). That’s a figure to make accountants who
do the math a bit faint.

Studies show that good documentation can lower post-sale costs, substantially. Cathy Spencer
and Diana Yates (1995) studied the impact of having “professional technical writers” create
documentation at General Electric. Their 5-month study showed that documentation produced
by professionals generated 59 support calls; documentation by non-professionals, 641. Their
simple conclusion: “Good user documentation means fewer client support calls and lower
support costs.” After taking action to improve its documentation, GE Information Services
estimated that it saved over $1 million annually in reduced support costs.

The findings of Cover, Cooke, and Hunt (1995) tell a similar tale. At Cadence Systems, they
found it was 10 times more expensive to correct documentation after it is released to customers,
when one factors in the cost of tracking errors, publishing release notes, fielding support calls,
updating source documents, and so on. Notably, their calculations did not account for lost
goodwill, which has its own set of costs and consequences.

At Intel, a documentation make-over also produced big savings (Scholz, 1996). There, one
product manual was rewritten, and within two years, the ratio of customer calls to units shipped
dropped from 1:18 to 1:26. The results did not go unnoticed, and Intel soon looked to rewrite
other manuals.

6
So make no mistake. Getting it right the first time, and before you send it out, makes a real,
a major, and a quantifiable difference.

Spending less and getting more from a documentation team

Producing documentation is expensive, no question. According to some estimates, the cost to
develop, process, store, distribute, and translate information can be as much as 20% of total
development cost. A Gartner Research study revealed significant costs to just copy, file, and
store paper-based documents — as much as $48 per document (X-Hive Corporation, 2003).
They also estimated that employees, on average, waste up to 8 hours per week on non-value-
added, document-related tasks.

Facts like these urge every company to control documentation costs. Three effective ways to do
so are: write fewer words, buy better tools, and follow better process.

Write fewer words.

Don’t be seduced into writing thousand-page tomes that make readers blaze through toner and
wear out warty rubber page turners. If your documents are wordy — with run-on sentences here
and redundant paragraphs there — you’re losing money. That’s because longer documents cost
more to store, print, ship, and translate. It also follows that companies should not measure the
productivity of their documentation team by total pages produced. When forced to abide by this
metric, the team may well deliver more content, but don’t bet on more usable content.

Buy better tools.

Erase from your memory the image of technical writer in front of keyboard, punching in reams of
vowels and consonants. While technical writers still do their fair share of typing, they also
perform plenty of processor-intensive operations, such as generating large books, building help
systems, and converting sets of files from one format to another. If forced to use old, slow, and
unreliable computers, not to mention small, low-resolution monitors, they will only waste time
and money.

Then there are the applications. Just as you wouldn’t ask someone to mow the lawns of
Wimbledon with a weed whacker, don’t ask a technical writer to author lengthy manuals with a
word processor built for the 2-page memo. Most deliverables demand a certain type of tool, and
one way or the other, you will pay for it.

7
Follow better process.

According to X-Hive Corporation (2003), as much as “90% of a typical technical documentation

set is created from existing material.” That should mean something to every company that
produces documentation. That should mean: concern yourself with source material, the stuff
that feeds the documentation machine.

By source material, we mean design, product, and engineering specifications, written by

members of your development team. These specifications must be accurate, complete,
produced efficiently, and delivered on-time. For this to be so, you must fully integrate all facets
of documentation development with product development.

Reality finds this integration to be rare. The more common condition is that in many companies
and for many reasons, product development tends to snub documentation. Inside the company,
the snub manifests itself in many ways: through deficient source information, through
inadequate funding or resources, through insufficient support from subject matter experts,
through poor integration with stakeholder groups, through a lack of management direction or
involvement.

Outside the company, the snub manifests itself in two problems, both serious. The first is the
near-certain production of low-grade technical documents. The second problem, though
perhaps less obvious, is knowledge loss. In an era marked by constant change and high
turnover, knowledge loss is common, and its consequences, severe. To state the obvious, it’s
not desirable to relearn your own products so you can recover know-how that now resides
solely in an ex-employee’s mind. Nor is it much good to search for files and applications buried
on an unknown hard drive by your last technical writer.

Dewitt Latimer of the University of Tennessee, in a study of turnover (2002), says this:
“When experienced employees leave, the institution typically suffers a significant loss of
institutional memory. This can be particularly crippling…where there is little documentation.…In
fact, the loss of institutional memory can be damaging in virtually any discipline. When
institutional memory is lost, the entire unit may suffer a loss of productivity as a result.” While
damages must be calculated case by case, one can safely assume that they would be well
worth mitigating.

An effective way to combat knowledge loss — that is, to safeguard your intellectual capital —
is to invest in process. It’s not enough to cover your ears and lecture at length about dollars and

8
deadlines. Poor process is a trap that poses a real threat to your business. Good process
supplies an antidote to the steady stream of adds and changes that might otherwise become
error and mix-up. Stated another way, good process provides for your company what a blanket
provides for Linus — a warm layer of security between you and a mad world.

Where documentation, training, and call centers meet

Here’s another question that may be on your mind: Can you lower or avoid documentation costs
by increasing investment in training programs or call centers? To cut to the chase, the answer
is, not really.
That’s because documentation provides the raw material — the product information —
that makes customer support possible. Without it, trainers have no lessons, courses have no
materials, and agents have no answers. You can decide when and how documentation is
distributed to trainers, agents, and customers, but you can’t take a shortcut. Documentation
must be job one, your first priority.
What’s more, consider the enormous costs to operate training programs and call centers.
Salaries for teachers and agents, expenses for training and materials, payments for
infrastructure, operations, and marketing. In one way or another, in time as well as money, you
will pass these costs onto customers, which will, in effect, raise the price and lessen the
attractiveness of your product.
This is not to say that companies should not invest in training programs or call centers. To the
contrary, these support options are often wise investments if not absolute necessities. That said,
training programs should be seen as a complement to documentation, not a substitute for it.
As for call centers, see them as the last line of defense in customer support, not the first. The
first line belongs to documentation.

9
Part 2: Why outsourcing makes sense
Credentials and credibility
The effort to write quality documents may start with commitment, but it goes nowhere without
knowledge and skill. Begin with mastery in multiple fields beyond writing, such as
needs analysis, information and instructional design, knowledge management and workflow,
usability and testing, and project management. After that, add expert knowledge of tools
(e.g., Adobe FrameMaker, RoboHelp, Microsoft Word) and mediums (e.g., print, CD, Help,
Web). Should room remain, toss in comprehension of the complex universe that is publishing
and translation.

This high degree of knowledge and skill explains why so many post-secondary schools now
offer programs in technical communications. At present, students can receive diplomas in
technical communications from Carnegie Mellon, Purdue, Clemson, Penn State, Concordia,
Waterloo, and the University of Toronto, to name a few.

Public and private organizations have also emerged to help technical writers advance their skill
and knowledge. The leading organization is the Society for Technical Communication (STC),
which currently has 25,000 members worldwide. The STC hosts conferences and competitions,
provides access to training, and offers professional certification. Other important organizations
include INTECOM, the Institute of Scientific and Technical Communicators, and the American
Society for Training and Development (ASTD).

The last decade has also seen a marked rise in the number of consulting firms specializing in
documentation services. While the independent contractor persists as an industry staple, more
and more companies are stepping forward with expertise in particular industries, toolsets, and
technologies. Many also offer related services, such as translations coordination and application
development.

What does this all mean? One, companies should stop asking their product developers,
designers, and engineers to do a job they cannot, in all fairness, be expected to do well.
Technical writing is a craft. Only those with proper training and experience can be expected to
excel at it. Two, before a company reflexively hires a full-time technical writer, they should
consider outsourcing documentation. The outsource option enables companies to focus on core
competencies and conserve limited resources. Said another way, outsourcing enables
companies to avoid the stiff penalties that invariably result from distraction.

10
So, if pair kerning, active voice, and perfect binding aren’t part of your company’s working
vocabulary, you may benefit from outsourcing documentation. The following sections make this
case.

How professionals pay dividends

Documentation professionals are strategic assets. They help companies develop technical
documents faster, better, and cheaper. Faster means companies make it to market on-time and
ahead of competitors. Better means companies produce the right information in the right format
to satisfy customers. And cheaper means companies, in the short-run, long-run, and everything
in between, save money.

If cheaper has you scratching your head, let us explain. As noted earlier, documentation is no
small challenge. Often, companies must author hundreds or thousands of pages of information,
a major undertaking without question. Amateurs who take this on may cost less up-front, but
they will take more time to understand your product, more time to write, more time to format,
and more time to manage. That means you will pay in lower productivity and late

delivery. When you add these items to the lesser quality you’re almost sure to receive, the case
for the amateur becomes decidedly weak.

Recall the findings of Spencer and Yates (1995) cited earlier. At General Electric, they found
that better documentation reduced support costs by $1 million annually. The key to producing
“better documentation” was this: hire “professional technical writers”. In the capable hands of
the professional, General Electric documents were more usable and required less support.

Moreover, consider that documentation professionals can pay dividends beyond their
deliverables. For one, because they understand your feature or product in detail and because
they understand usability, documentation professionals can analyze your product from a user’s
perspective, identifying functional gaps and areas for improvement. In many cases, far-sighted
companies involve them at the earliest stages of product development, as quality assurance
testers and usability analysts.

Two, documentation professionals can help companies develop processes to facilitate the
production of more timely, complete, and accurate information. The results of a quality
management initiative at AT&T demonstrated this point (Edwards, 1989). In this instance, AT&T
improved documentation processes and, as a direct result, reduced documentation costs by
53% and production time by 59%.

11
Why in-sourcing may not be best
Some companies believe that hiring a full-time technical writer proves their commitment to
documentation and provides the best assurance of quality. In some cases, these companies are
right. But in many cases, these companies should know that hiring a full-time technical writer is
not their best option.

Those who have worked as technical writers are familiar with the life. Ebbs and flows, as much
as anything else, define it. If you’re a full-time technical writer with one company, you can
expect to be idle for hours or days or even weeks at a time. It will be a secret you keep from
your employer, so as not to embarrass them or endanger yourself. Then, just as surely, you will
endure drawn-out days and nights that offer no rest from the gated deadline and its circular
flood of specs, drafts, and reviews, as you battle burnout to deliver the goods.

This ebb and flow helps to explain why companies can be better served by contractors. If the
work is there, the resource is there; if the work is not there, well, you get the point. As an
employer, this means that you don’t pay for idle resources. It also means that you have greater
freedom to adjust the roster, to account for financial conditions, to find a better fit.
Furthermore, because contractors exercise their writing muscles on many projects with many
employers, they develop richer skill and experience. In work that is craft, that is both art and
science, richer skill and experience translate into higher quality and output.

Taking one or the team

If you plan to hire only one technical writer, there is another key reason why contracting may
better serve your interests. That reason is as follows.

Where a company sees need for one technical writer, said company often expects said
resource to wear many hats: writer, editor, document designer, production interface, and so on.
Few individuals specialize or excel in all of these areas. In fact, few specialize or excel in more
than one. By hiring a company with multiple resources, you stand a better chance of acquiring
the necessary set of skills and resources.

Another reason to consider the “outsource-to-team” option is this: As mentioned before, at the
start of a development cycle, workflow tends to be light and at the end, heavy. If you only have
one resource, it’s doubtful you can do more than sit back and observe the suffering. You may
think to call in the cavalry in the frantic final hours of your project, but that’s more likely to hurt
than to help. With that option off the table, you’re left to depend on a single resource, and that

12
single resource can form a bottleneck that exposes your project to unplanned delay, better
known to would-be customers as failure.

However, if you contract technical writing to a team, the team can supply resources on an as-
needed basis. If work piles up, the team can expand, if work peters out, the team can contract.
For most companies, especially smaller ones, the team option is best, since it offers the
advantage of not forcing a company to trade off flexibility for capability.

Let’s stop to consider another point. Assume that you have but one technical writer on staff.
Who will edit his or her work? Who in development or marketing or planning has the time and
skill to review documents, not for technical content, but for language and format? In many
cases, the answer will be no-one. That leaves your lone technical writer to self-edit, a most
difficult assignment. Even the best writers have blind spots to their own mistakes, which is why it
makes sense to have a peer review their work.

Open minds and open books

When it comes time to select a documentation vendor, look for certain traits. First, look for
professionally trained writers and editors so the work gets done well. Second, look for project
management and process development capability, so the work gets done efficiently and on
time. Third, look for knowledge of your product, technology, and industry, so you don’t spend
more time helping them than they spend helping you. Fourth, look for a vendor with an open
mind, one who is tool- and technology-agnostic, so together you can identify requirements and
develop a strategy objectively.

Regrettably, some vendors are only prepared to promote one particular and perhaps proprietary
solution, no matter who you are. Others will simply act more like evangelists than consultants,
peddling their preferred answer to your documentation dilemma. Do not accept a closed mind. If
you cross paths with a vendor who pitches a one-size-fits-all solution, one with little regard for
your unique challenges, run away. Far and fast.

Finally, choose a company that talks in terms of results and returns. Quality and efficiency are of
course important, but business success is determined by profit. Insist that your documentation
vendor gives you a way to measure its contribution to your bottom line.

Thinking outside the documentation box

Many companies wed technical writers strictly to technical documentation. However, technical
documents are not the only deliverables that technical writers can or should produce. In many

13
companies, you will find technical writers reaching beyond traditional boundaries into the
business writing realm. There you’ll find technical writers working on sales proposals, slide
shows, datasheets, brochures, white papers, and many other deliverables.

This expanded scope is both sensible and appropriate. Technical writers can add value to these
deliverables because they understand products and technologies at a detailed level, unlike
many counterparts in marketing and management. At the very least, it is prudent for companies
to involve technical writers in the production of other written deliverables, if only as reviewers.
Their participation in these projects promises to yield important insight and improvement.

The final chapter

More than ever, technical documents matter. As people invite more products with more features
into their daily lives, companies have no choice but to do a better job of delivering well-written
and well-designed technical documents.

In his seminal book Post-Capitalist Society (1993), Peter Drucker makes a closely related point:
“The productivity of knowledge is going to be the determining factor in the competitive position
of a company.…The only thing that increasingly will matter…is management’s performance in
making knowledge productive.”

High-quality documentation makes knowledge productive. First, it sways buyers toward your
product, boosts their satisfaction, and keeps them faithful. Second, it lowers operations costs by
increasing internal efficiency, by making it quicker and easier to find answers and follow
instructions. Third, it lowers post-sale costs related to product returns, support calls, training
costs, and even litigation.

To produce high-quality documentation, a company requires expertise. If a company lacks this

expertise internally, it must hire a full-time technical writer or a professional contractor. In most
cases, the professional contractor will offer a wider range of skill and experience, and that will
translate into superior quality, delivery, and output.

If the project requires multiple resources, hiring a vendor with a ready-made team may be better
than hiring multiple independent contractors. More often than not, the team will offer a broader
skill-set and something more, a bench, so you can add and subtract resources as demand
dictates, gaining flexibility over operations.

14
Though scarcely hidden, the central message here bears repeating: Companies that take their
products and customers seriously must support both with high-quality, cost-effective
documentation. To do this, companies must consider outsourcing documentation to a
professional documentation vendor.

Nothing less than business success is at stake.

15
References
Cover, M., D. Cooke, and M. Hunt. 1995. “Estimating the Cost of High-Quality Documentation.”
Technical Communication (42).
Drucker, Peter. 1993. Post-Capitalist Society. New York, NY: HarperCollins Publishers Inc.

Edwards, A.W. 1989. “A Quality System for Technical Documentation.” In Proceedings of the
36th International Technical Communication Conferences. Arlington, VA: Society for Technical
Communication.

eHelp Corporation. 2003. “Publishing Policies & Procedures Online.”

(Available on-line at: http://www.ehelp.com/products/roboinfo/whitepapers.asp)

Hackos, J. 1995. “Finding Out What Users Need and Giving to Them: A Case Study at
Federal Express.” Technical Communication (42).
Hall, W. 2001. “Maintenance Procedures for a Class of Warships: Structured Authoring and
Content Management.” Technical Communication (48).
Latimer, Dewitt. 2002. “The Cost of IT Staff Turnover: A Quantitative Approach.” Educause
Center for Applied Research.

Mead, Jay. 1998. “Measuring the Value Added by Technical Documentation.”

Technical Communication (45).
Scholz, J. 1996. “Adding Value by Developing Information for Online Customer Support
Services.” Intercom (October).
Schriver, K. 1993. “Quality in Document Design.” Technical Communication (40).

Smart, K.L. 1996. “Cost-justifying Technical Communication.” Intercom (December).

Spencer, C., and D. K. Yates. 1995. “Case Study: A Good User’s Guide Means Fewer Support
Calls and Lower Support Costs.” Technical Communication (42).

TechScribe. 2003. “Improving Product Value through Quality Documentation.”

(Available on-line at: http://www.techscribe.co.uk/techw/press_business_value.htm)

X-Hive Corporation. 2003. “Content Management of Technical Documentation.”

(Available on-line at: http://www.x-hive.com/img/2003-05/white-paper-techdoc.pdf)

16