Documentation
   
     

 

"Seagull, seagull, sit in the sand,
It's never good weather when you are on land "

 

Documentation  deliverables are categorized from the root product and branch out into various types of output. This is important to know because the client may not have any idea how many variations there are in terms of final output for documentation, or realize that a healthy blend of several deliverables will meet his/her needs more cost effectively.


Single-Sourcing  refers to creating the elements of the client’s documentation only once and in one application. Then, we store the source files centrally and publish that same information with minimal adjustments in multiple formats and uses.

Single-sourcing documentation provides numerous benefits:

1- Better quality documents. By defining one set of deliverables that can be reused in a variety of media, we can focus on making this set of single sources the best they can be.

2- Reduced deployment time. Because we use only one set of source files to create the final deliverables, the client can reduce the amount of time to deploy their technology to the desktop. The client achieves this faster time to market by tightly integrating people, processes and tools.

3- Improved document development process. By identifying and simplifying the document development process, the client gains efficiencies in the control and deployment of resources through joint planning techniques. The process improvements brought about by interfaces and hand-offs in the organization also result in reduced expenditures.

4- Reduced update costs. Maintaining one set of source files takes writers less time and reduces the costs for updating a documentation set. Less expensive localization. With an ever-changing global marketplace, localizing documentation in the most cost-effective manner is critical. Localizing one set of source files reduces localization costs and speeds the localization process.


The Project Process

Communication Lines customers come in all shapes and sizes. In the following definitions of company size the characteristics listed are just guidelines for description purposes. The sales figures listed are gross sales,, not net profit. In general, the larger the company the more money the entity should have budgeted for documentation.

Development Costs

The following discusses the types of ways cost is presented and contracted with a potential client.


Time & Material: Time and Material (T & M) type projects are based upon a fixed cost per hour of work and the client paying for any additional material required to complete the project (cost of software, professional printing costs, photography or images). It may also include any travel experiences incurred on the behalf of the client.

In some cases, there is a limit set on the amount of hours that can be billed so that the client can set a budget for the project. This may also be considered a combination T & M and Fixed bid type project. The proposal and contract will clearly state following:

1-The hourly rate.
2-The required deliverables.
3-The estimated completion date (s) for a deliverable.
4-The payment terms (normally on a weekly, bi-weekly or monthly billing (with either 15 or 30 days net).
5-The requirements of the client.
6-Our requirements.
7-Whether expenses will be paid by the client and what is covered.

The Fixed Bid

A fixed bid project is one where the cost of the project is agreed to before the start of the project. It is based upon an estimate either we make or the client defines (we agree that this is a reasonable amount). In this type of bid, we perform an analysis of the requirements and determine the cost of the project. This is normally a calculation of the estimated hours to complete the task times an hourly cost PLUS a factor (normally 20 – 40% of the estimated hours * rate) to allow for additional work not anticipated during the initial analysis stage. In some cases, we can bill the client for the analysis work.

The proposal and contract will clearly state following:

1- The cost.
2- The required deliverables clearly defined with as much detail as possible.
3- The process for items that are not included in the original scope of the project (how is this communicated, the process for determining cost, the approval process, etc.).
4- The estimated completion date (s) for a deliverable.
5- The payment terms (normally percentages of the cost based upon deliverables (for example, 30% due at signing, 30% due on first draft and the remainder at the acceptable of the deliverable by the client) with either 15 or 30 days net).
6- The requirements of the client and the penalties that could be invoked if the client does not live up to those requirements.
7- Our requirements and any penalties we might have if we do not live up to those requirements.
8- Whether expenses will be paid by the client and what is covered.

The Financial Negotiation Process


In most cases, the negotiation process will consist of a proposal (see above) that details the costs, payment schedule, deliverables and deliverable schedule. This proposal is submitted to the client for their approval. Only after a proposal is approved and a contract signed (this might be the proposal), does the work for a client begin. The client is always the company that we have the contract with but the work can be performed for that company or for a client of that company.


Requirements of the Client in Project Engagement


1- Schedule a Project Kickoff meeting at client site for documentation/training initiative including the formation of a small team of project champions that will be committed to the review and input of documentation and training materials.
2- Schedule face-to-face meetings with key SMEs immediately upon project start.
3- Supply Communication Lines with background source materials.
4- Identify a Project Champion at client site who is the primary contact for Communication Lines on content issues. The Project Champion should also have final review and approval authority for all interim deliverables.
5- Identify primary and alternate SMEs from key departments and their fields of expertise.
6- Review and approve the Project Plan to finalize the content and format of the class and documentation outline.
7- Review and approve document prototypes per existing standards from client or those Communication Lines establishes.
8- Complete reviews of each interim deliverable and approve each final deliverable.
9- Make SMEs available for meetings (via phone or face-to-face) and respond to communications (email, voicemail, and faxes) during the courseware and documentation development process in a timely manner.
10- Approve final deliverables.

Dependencies
There are many dependencies that directly affect Communication Lines’ ability to deliver the courseware and documentation according to the established schedule, including:

1- Adherence to milestones in the schedule. Communication Lines’ writer/courseware developer has access to SMEs for quick issue resolution.
2- Ability of client to agree on the documentation prototypes established, Table of Contents and their relative priorities. Availability of additional source material to be identified by client.
3- Obtaining detailed, accurate reviews from client per the established schedule.
4- Obtaining approval on all interim and final deliverables (outline and drafts).

Proposals, Statement of Work, Change Orders

Every project begins with a needs analysis to scope out the type of work required. Is it a small job, or large? How many resources are needed, and how much information is already available? The SOW, or statement of work, serves as a proposal, or a blueprint, and tells the client we have performed due diligence and to the best of our knowledge, this is what we believe is required to get the job done. The estimates for tasks that must be completed are provided, and based in part, on the needs analysis, and on past experience.


The client must sign off on the SOW before work begins. When there are changes in the project, a change order stating the additional work necessary must also be signed off by the client. A NDA (non-disclosure agreement) is usually also signed by Communication Lines at this stage.


Assignment of Rights


Sample wording for the assignment of rights in a Communication Lines proposal reads:

"Communication Lines agrees that all works, ideas, and inventions made by Communication Lines during the term of this Agreement in the course of performing Services, and all proprietary rights therein, including but not limited to rights of patent, copyright, and trade secrets, shall be the exclusive property of XXX and works for hire under the United States Copyright Law. To the extent necessary to effectuate the foregoing, Communication Lines hereby assigns and agrees to assign to XXX all of such rights and agrees to provide such reasonable assistance as may be necessary (at _____ ’s expense) to perfect _____ ’s rights hereunder."

 


 

 

 

 

 

Documentation Product Line

 

Documentation as product can be produced in three standard formats: hardcopy, PDF (or Microsoft Reader), or online for viewing in HTML or another markup language with Flash components. The following describes each of the standard documentation product offerings:

End User Guides

What is an “end user”?  Webpedia defines it as: “The final or ultimate user of a computer system. The end user is the individual who uses the product after it has been fully developed and marketed. The term is useful because it distinguishes two classes of users, users who require a bug -free and finished product (end users), and users who may use the same product for development purposes. The term end user usually implies an individual with a relatively low level of computer expertise.

Unless you are a programmer or engineer, you are almost certainly an end user.” End user guides are typically less than 100 pages and are targeted toward the end user audience learning about using a piece of software or hardware. The standard end user guide covers common tasks the user can perform using the software or hardware or device. Occasionally, the end user guide includes how to install or implement the software as well as troubleshooting. However, if the software, device, or hardware is complicated or enterprise-related, it is not uncommon to generate a separate installation guide or troubleshooting guide as well as the end user guide.


Because the audience for the end user guide is usually not as technical as a system administrator level, the document is written to a lower reading level, and uses more visual instruction in the form of screen shots of the application, process maps to show sequence of steps, and/or other graphics to identify key components (such as cables for a network architecture).


A common myth from some clients who are not familiar with the large menu of documentation/training offerings available in the industry, is that an end user guide can also serve as a “training guide.” Nothing could be further from the truth. An end user guide focuses on content in a reference or procedural format. In a training guide, information is presented first as a demonstration or instruction, followed by practice sessions using an instructional design approach that meets adult learning theory models. Often, an end user guide is part of a larger documentation solution (i.e., a library of docs including an end user guide, system/administrator guide, etc.).

The end user guide can also be referred to as the “front end” guide. Often, in software technology, the infrastructure for the application splits into a front-end and a back-end; the front-end represents the client interface, and the back-end represents the database, server configurations, and library of code. An end user guide can be produced typically for the external customer; however, end user guides are also required by internal audiences as well. The main difference between the external and internal audience is the packaging. The end user guide for the external customer is considered part of the purchase (i.e., part of the product which is the software, device, or hardware). The end user guide for the internal customer/user is more of a necessary evil. It generates no revenue, however, it is critical within organizations that every user be provided a reference of information to operate various software, machinery, hardware, and so on.

Return to Top


System/Administrator Guides


A system administrator guide, or back-end guide, typically covers configurations, installation, implementation, application, operation, troubleshooting, and any other administrative tasks that the more technical user performs using the application in question. These guides can range anywhere from 50 to 400 pages in length, and usually resemble a phone book in style. The guide can provide procedures, concept overviews, and then generally tends to house large volumes of data reference type information that you would find in high-end technical manuals. This type of manual can certainly be provided to both the external paying customer or for internal audiences as well.

Return to Top


Policy, Procedure, Process Guides


Internal audiences use policy/procedure, or process guides. Rarely, are these type of guides used for external consumption. A policy and procedure guide is becoming increasingly popular due to Sarbanes-Oxley legislation which dictates that every publicly traded U.S. company provide written procedures for every valid process within their organization. Procedure guides are used for every operation and date back to military days for procedure spec writing. Process guides can be a part of a procedure guide, however, there are stand-alone process guides that illustrate a high-end concept on process, and/or are used in consulting to show a break-down of processes within an organization. These guides are usually anywhere from 50 to 150 pages in length.

Return to Top


Reference Guides


Reference guides can be targeted toward external customers or internal users. They are typically over 100 pages in length and are usually used to provide language references such as API guides (Application Programmer Interface). They are used by a technical user who usually already understands the product (a prerequisite may be to read an end user guide first to learn how to use the product), but requires a reference look-up for various details.

Return to Top

Technical Editing


Every document that is produced for external or internal audiences should be edited. This is performed during a peer review, however, in many organizations a need for a technical edit is required. Part of the technical edit is to identify grammar and clerical problems with the text as well as perform full re-writes of sections where necessary. Style guides are used as the technical editing reference such as the AP Style Guide or the Chicago Manual of Style. A formal edit is performed just as would be done in the publishing house, marking up copy either online or in hardcopy notes, for the writer or source provider.

Return to Top

Online Help


Every application usually provides an online help button or link which gives the user a compressed library of documentation displayed for online viewing (links, drill-downs to other related sections, and a full text search engine). Online help is a deliverable that often must be produced in tandem with the developer because it relies on code that the developer retains in order to run. If the online help is context sensitive (meaning, you can click on words for additional assistance, at the window or page level), the developer must work with the online help author since tags or unique topic IDs must be assigned within the developer’s code in order to make the online help work.


Currently, online help is produced in compiled HTML (.chm) format or Flash. A variety of vendor tools makes this possible, and the help author usually is writing procedures, reference material, and many times, tutorials, all part of the online help package. The difference between the online help deliverable and other documentation products is that the audience is an online viewing audience, and similar to website content, the online help must be presented in a meaningful manner with a discreet amount of links, and architecture which is usually planned out in advance.

Return to Top

Newsletters


Technical information can be presented in a newsletter format for hardcopy or online viewing. Although newsletters are usually associated with marcom or corporate communication deliverables, they are not always used to promote or deliver a message. In many cases, newsletters provide necessary up to date information on a regular basis that a user community relies on in order to make meaningful decisions concerning operations within their organization. There are a wide variety of formats, however usually technical newsletters do not exceed 16 pages in length.

Return to Top

 

 Design by Communications Lines
 Copyright © 2006 Communications Lines, All Rights Reserved