Document Life Cycle [1] is a term used in Document Management Systems (DMS) [2], Digital Rights Management (DRM) [3], Document Records Management Theory [4], Customer Relationship Management (CRM)[5], and Content Management Systems (CMS)[6]. The life cycle begins with the creation or receipt of the document and ends with its destruction or permanent preservation.

Creating an accurate and helpful technical document is a multistep process consisting of planning, drafting, revising, and testing. In most cases, a document will require contributions from a range of specialists including writers [7], designers, and subject matter experts. A project manager, sometimes called a Technical Writer Project Manager (TW PM) [8], is the person overseeing the document’s creation.

The planning stage [9] is the period in which the writers map the path for the completed document. As such, it will vary between writer teams but normally features a timeline for submissions and a budget estimate. Additionally, the planning stage includes:

The drafting stage is the period in which the writer organizes information and ideas into sentences and paragraphs. Most technical writers will use a preformatted template at the start of the drafting process.

A technical document will normally undergo multiple drafts before approval. While some writers may still use pen and paper to draft, most will use a computer. The two most popular software tools for writing and editing are Microsoft Word and Google Docs. Other options include LibreOffice Writer, Dropbox Paper, Quip, Draft, and Hackpad.

Best practices advise giving all drafts a precise working title. The title should include keywords that describe the content. Precision in the title makes it easier for collaborators to manage the document. The working title is usually different from the final title.

The revisions stage is the period in which the writers edit the document. The process includes both line and copy edits (LINK). The first step in revising a document is always self-editing. Options for self-editing like spellcheck, grammar check, word count, and read aloud are included in word processing software.

After self-editing is finished, a writer will submit the document to other team members for feedback. The team will study the document and make suggestions for improvement. The writer will then incorporate their feedback into the draft and resubmit. The submit-critique-resubmit sequence can be lengthy but usually defers to the timeline agreed upon in the planning stage. Once the final draft is approved, the document will be sent to the publisher or the testing team (10.4).

Revising an existing, published, or live technical document normally requires less collaboration than a new document. This is because the revisions are additions, subtractions, or replacements of specific copy (e.g., a new disclaimer based on California Proposition 65) that do not alter the purpose of the document.

The testing stage is the period in which the writers learn how the intended audience responds, interacts, and uses their document. The process is called usability testing. Pilot tests, in which a single document is tested, are used to improve the reliability of the usability testing process.
Properly conducted, a usability test will reveal the strengths and weaknesses of the document. The information gathered will be used to improve the document. The goal is to publish a technical document that’s helpful, informative, and intuitive.

The reason companies test documents is that effective technical documents save money. They reduce customer questions (phone, email, in-person). They reduce complaints and bad reviews. They reduce churn and product abandonment. Most importantly, they reduce accidents, even fatalities
To collect valid data from a usability test, administrators need to stay organized. They must be attentive to participants, ready to answer questions as they arise. At the end of the test, they must debrief participants to clarify observations.

Once the team records the results for their test, they’ll send the document back to the writing team for revision. Upon final acceptance, the document will then be sent to the publisher.

In level 3 the company has standardised processes which are established and being improved. As a result, there is consistency across the company. Individual projects are defined according to company policy.

The company sets objectives in line with their standard processes.

Level 3 has a greater scope of standards and procedures than level 2. Because a level 3 company has standard processes, individual projects are in line with those standards rather than individually defined.

The company ensures good project management by using quality project management software.

There is a risk known as: "what you measure is what you get". If we count the number of pages, the chance is we get a huge amount of pages just to get a higher score. If we count words, it may happen to words, too.

The paradox is the properties of documentation that can be easy measured have little importance in regard to the real value of the document from the end user`s perspective. This is the case of counting the number of pages in the document.

Quantity is not Quality.

From the other side, it is more difficult to build a metrics for the attributes that in fact brings an added value to the document from the end user`s perspective. This is the case of: subject coverage by content, language style, enough level of details for the reader, etc...

Also, planning good metrics for the document quality must start at the phase of collecting requirements. If the document must be measurable then the requirements for the document must also be measurable. Only this way we can see if the requirements have been met by the writer and other players in the production chain.
E.g. if the requirement is that we produce a good document, so how could we define the metric showing that the document is really good?

Requirements must be specific so that we know they are attainable. And the match between the content and requirements may be then used as one of the metrics used for measuring the document quality.

Scope creep is the adding of features to a project which were not in the original plan.

There are 2 types of scope creep:

Business Scope Creep - when requirements are added to a project to meet business needs.

Features Scope Creep - when extra features are added to a project by developers independent of management.

To control scope creep it is necessary to have a Scope Management Plan which clearly defines the procedures the project will follow. The Scope Management Plan is part of the overall Project Management Plan.

Features which fall outside the scope of the project are not added to the project automatically but must be assessed to see if they fit the requirements of the project.