Sunday, July 6, 2008

Document Lifecycle Management

Document Lifecycle Management (DLM) is the process of handing a document, from the time it is conceived as an idea, to the point of its physical or electronic generation, maintaining its replicas as saperate versions throughout the process as it goes under various iterations; and finally when the document is declared dead.

The entire process revolves around placing and moving these document on storage devices as it is generated, replicated, electronically distributed, protected, archived, and ultimately retired.

DLM couples the process of storing, indexing, archiving, managing searching and retrieval services. To do this, DLM is composed of an interconnected set of processes, storage components, and data and storage management applications.

Note: Going forward we would refer DLM as DMS.

DMS is not only about storage; it is about implementation of an intelligent workflow and business process management. It is as much about automating the searching and indexing, categorizing, and managing of the documents as it is about the storing and archiving of them.

Importantly, DMS is about creating policies that can fit the information flow into the business environment as part of an overall architecture. Owing to its nature, DMS is most effectively implemented using an application-specific solution approach that includes generalized management components such as policy engines, schedulers, and application-specific components like document layout, encryption policies, updation criteria, retrieval modes, document life tenure, etc.

Why do enterprises need DMS?
Today’s enterprises face the daunting challenges of managing phenomenally increasing quantities of information (read: documents) so that its value to the business is fully realized, while minimizing the cost of maintaining and managing the IT infrastructure. It has become painfully clear that critical enterprise data must be continuously available. Automated processes to manage these documents through its life cycle are becoming essential.

The lifecycle of document is divided in the following listed steps
1. Planning
2. Analysis
3. Document Design
4. Instance Design
5. Instance Distribution
6. Management

What Does A Technical Writer Do

TECHNICAL WRITERS compose communication from product developers for users of the products. Users include consumers as well as scientists, engineers, plant executives, line workers, and production managers. Writers must write in a concise and easy-to-read manner for consumer publications or in highly specialized language for experts. With the increased use of desktop publishing, Technical Writers increasingly are responsible for the publication process including graphics, layout, and document design.

Technical Writers create product instructions, reference and maintenance manuals, articles, project proposals, training materials, technical reports, catalogs, brochures, online documentation and help systems, Web pages, multimedia presentations, parts lists, assembly instructions, and sales promotion materials.

Technical Writers perform the following tasks:
1. Analyze the needs of the target audience

2. Conduct detailed discussions with subject matter experts to understand the product or procedure.
3. Index and cross-reference documents such as bulletins and manuals.
4. Produce or arrange for illustrations, charts, and photographs to be included in publications.
5. Edit, standardize, or revise material prepared by other writers or personnel.
6. Prepare layout of material for publication.
7. Prepare rough drafts of the publication for review with the project staff and/or customers.
8. Create and edit Web pages for the Internet, intranets, and extranets.

Technical Writers often specialize in a specific industry such as agriculture, health care, pharmaceuticals, telecommunications, computers, or manufacturing. Within their chosen industry, many Technical Writers will specialize further. For example, Technical Writers in the computer industry might specialize in software documentation, tutorials, or user manuals.

Technical Writer is the most commonly used job title for this occupation. Other titles used include Medical Writer, Communications Specialist, Policy and Procedure Writer, Proposal Writer, Publications Specialist, Science Writer, Documentation Specialist, Health Writer, Information Developer, Technical Editor, Web Editor, and Information Designer. Some titles indicate the particular industry in which the occupation is found.

Technical Writers obtain and present specialized information within strict accuracy and format requirements. Technical writing requires the ability to concentrate for long periods of time and strong organizational skills.

Technical Writers use the following skills, knowledge, and abilities to accomplish their daily tasks:
Writing - Communicating effectively with others, as indicated by the needs of the audience.
Active Listening - Listening to what other people are saying and asking questions as appropriate.
Speaking - Talking to others to effectively convey information.
Information Gathering - Knowing how to find information and identifying essential information.
Information Organization - Finding ways to structure or classify multiple pieces of information.
Synthesis/Reorganization - Reorganizing information to get a better approach to problems or tasks.
Active Learning - Working with new material or information to grasp its implications.
Product Inspection - Inspecting and evaluating the quality of products.
English Language - Knowledge of the rules of composition and grammar, and meaning and spelling of words.

Technical Writers usually work at a desk in an office. During planning and production of publications, Writers may be required to travel to another location to discuss a project with others. Technical Writers use personal computers and word processing or desktop publishing software for text, graphic, and multimedia production. Workers often have deadlines to meet. Technical Writers who work under contract or freelance may work from their home or at the employer's site. Writers may work alone or together under the supervision of a publication chief or editor, a product or procedure specialist, or a marketing manager.

Editing & proofreading a technical document

Being in technical writing industry, we regularly need to bump into technical reviewing of our documents.

Technical Writers often think that technical editing involves checking the spelling and grammar of a document. If this was true, then a spellchecker would have successfully replaced a technical editor, isn't it?

Technical editing does not only involve proofreading. It involves looking at the document as a whole with a fresh eye and then digging into the nitty-gritty of its various aspects.


Looking at the document as a whole means looking at it globally; you look at the front-matter, structure, topics, coherence of the topics, cross-references and links, tables and figures, etc.

After you are satisfied with the global look, you get down to the level of individual topics, and then copyedit and proofread. Check the correctness of information and language; see if it adheres to the company's standards; and ensure consistency.

Let us now divide the process of editing into two broad levels – Global and Local.

Global editing is more of a comprehensive editing that ensures the following:
The document
1. Appeals to the right audience
2. Is focused
3. Is presentable
4. Adheres to the company's standard
The readers will
1. Understand the document
2. Not get confused


Local editing is done to ensure the correctness and completeness of the document. It ensures the following:
The document is
1. Correct
2. Consistent
3. Accurate
4. Complete
5. Useful
The readers are able to perform the desired task and get the desired information (and related information) at one place.
If we dig a bit further into these two levels, we need to know the following:
1. What aspects of the document are covered in each level?
2. What tasks does an editor need to perform for each aspect?
3. Does each aspect need to be checked for all kinds of document?
4. Can we skip a sub-level/aspect depending on the kind of document?
5. What skills must an editor possess to ensure all of the above?


Technical editing can be broadly classified under the following categories:
Proofreading
1. Comparing a document against an original manuscript to verify its accuracy.
2. Reading the document one final time for typographical errors, such as missing commas, periods, other punctuation marks, and so on
Copyediting
1. Checking the document for grammar, punctuation, spelling, capitalization, formatting, and conformance to style guidelines.
2. Editing sentences to remove passive voice, ambiguous references, awkward word/sentence transitions, inappropriate tense usage, sentence faults, and excessive wordiness.
3. Copy editing is also referred as rule based editing. We need to remember here that rules-based editing is usually non-negotiable with the writer: it is the editor’s job to enforce the rules.
Substantive Editing
1. Ensuring that the overall flow of the document content is structured and logical
2. Ensuring that the document is clear, complete, and accurate
Undoubtly, substantive editing requires a fair amount of domain knowledge.
During a substantive edit, you might want to ask questions, such as –.
Why is this information important?
Is this the correct place (within the document) where this information has to be placed?
How does a fact relate to the theory described in a specific Chapter?
Is the information contradicting the paragraph mentioned in a particular Chapter?
Does the document contain a logical flow?
Finally, step into the shoes of the user (who will be reading your document), and figure out if the information makes sense, or adds value.

A few tips for making substantive edits:
Understand the voice, tone, and style of the original author
When in doubt, always “ASK” for clarifications before assuming anything
May involve rewording/rewriting portions of the text
May involve revising the content, organization, or tone of a manuscript, or doing all three.

Now, I am sure all technical writers would agree that technical editing involves a lot of things. The apt name for such a person should be "reviewer" and not "technical editor".

But there are still a few questions that might linger around on our thoughts

· If a "reviewer" is responsible for these tasks, then what does a "technical editor" do?

An editor is a person who makes corrections and the edited work does not go back to the author. It goes straight for publication. The corrections can be grammatical, structural, or related to flow.

A reviewer, on the other hand, is not the final authority. He or she gives suggestions and then discusses it with the original author. If the author does not want to implement a suggestion, he or she explains the logic to the editor. Some of reviewer's suggestions might be stroked down.


· What is the difference between "reviewing a document" and "editing a document"?

Reviewing a document requires author's active participation while editing a document does not require author's active participation.
· Would the person who does the editorial review be called a "reviewer" or an "editor"?

Editors working with a newspaper do not consult the authors, do they? Therefore, it is right to refer to them as "editors" there. However, the scene is different in a software company. Here, it is a two-way process and requires author's active participation. Therefore, in a software company, the right word is "reviewer".

Some other queries could be such as

Is there any ideal sequence that an editor should follow while editing a document?
(Like doing the substantive editing first and then copyediting the document)

Are any specific skills required by a technical editor apart from possessing a good knowledge of the domain and the style standards?

Lets’ try to find answers to the second question first.

If we are to address the "editors" as "reviewers" in technical writing, then SMEs (Subject Matter Experts) too fall in the "reviewers" category because they review the documents for technical correctness.

The editors are a part of the technical writing team, and like the technical writers, they too are supposed to collaborate with the rest of the team. Since they review various aspects of the document, they interact with the lead writers, writers, managers, designers, usability experts, and others.

And, is reviewing the documents editors' sole task/responsibility? Their inputs can add value in planning the documents, estimating the efforts, designing the GUI, and deciding on the usability of the product. They can even act as consultants to the managers, designers, and writers.

But the fact is that an editor's roles vary from one industry to another.

Some people believe that, the editors in the publishing industry do not interact with the writers, but the ones in Technical Writing industry do, not only with the writers but with various other people.

But that’s not the truth. The editors in the publishing industry definitely interact with the writers – very often.

For writers on board, they discuss the plan, brief the writers, allot topics, discuss topics, and often inform writers if any of their stories need last-minute changes.
For freelancers or invited / specialized writers, the interaction involves discussing the topic / copy and a lot of information exchange.

After the copy is submitted, the editor does get in touch with the writer for changes, updates, etc. whenever possible. Due to the tight schedules and space constraint, however, the editor has rights to fit/fix the story as required.
The major difference is that the final publication is the responsibility of both - the writer as well as the editor. In case of tech writing, mostly the writer is responsible for the final copy.

Now let us focus on the flow of technical review process.

Like it was in the beginning itself, the process of editing a document covers different aspects.
For large and complex documents, multiple editors can be assigned to review specific areas.

One editor can copyedit the document, another one can review it for technical accuracy, and yet another one can review the document to check if the editors/writers have missed anything.
Editing does happen in multiple stages and multiple times (as required). But it's the writer who signs off the final release.

While doing copyediting of technical books (for language alone), many reviewers prefer to have a separate sheet called Author Queries, where one could record any doubts/ or clarifications needed. The book does not go to the next stage till the author clarifies all those एंड sends it back to the copyeditor.

So, we can have a Copy Editor (who'd proofread/copyedit), a Substantive Editor (who'd do substantive editing), a Technical Editor (who'd check the technical accuracy), and a Project Editor (who'd edit the edited document).

Now that I have talked about the types of editors, you would certainly like refer an SME as a Technical Editor?

But the answer is a big NO! As being a tech reviewer for the specified docs is only "one of the tasks" for an SME. And really speaking no single person can act as a tech reviewer covering a whole lot of technical specializations.