Tech Biz Writing

A report is a document produced to convey factual information to a specific audience at a certain point in time. A report writer is usually someone with a special knowledge of the subject-matter, who may or may not be a full-time writer. He is quite likely to be an engineer or a technician of some kind, qualified either by his job status or training to undertake the particular task. Or he may be peripheral to the activity, but called upon nonetheless in an attempt to achieve objectivity.

Technical writers, especially those employed on the Tech Pubs department of a firm or organization, are often asked to contribute to the company’s report writing workload. There are several distinct advantages in this from the company point of view. Such a writer can be expected to produce a result notable for its style and clarity. The author will already have a good grasp of the technical aspects of the firm’s products and will not need an excessive amount of time at the briefing stage. And, being slightly outside the drama of actual design and production, should be able to resist internecine politics and influences.

A report, then, requires an element of factual objectivity, an appropriate style of writing and presentation, and a form which organizes the material in the most accessible manner for the prospective reader. Its purposes may be many, but the following six reasons for writing a report would cover most occasions:

* To give an accurate account of the subject.
* To present a basis for discussion.
* To arrive at a conclusion and plan further action.
* To make recommendations.
* To disseminate information.
* To provide a reference record.

A report can be subject-orientated — that is, divided into topics, or groups.
A report may be chronological — it represents a record in time, e.g. a progress report.
A report can be conceptual — dealing in abstractions or philosophical aspects of the subject.

From the technical writer’s viewpoint, we can say that reports are generated as part of a producer’s internal information — his product documentation. This, in general, may comprise:

* An initial requirement, or technical proposal.
* A feasibility study.
* Design and research reports — project definition.
* Pre-production specifications: standards, performance, design philosophy.
* Evaluation documents: trials on reliability, maintenance &c.
* Ad hoc reports: investigation, progress etc.

The requirement report, or technical proposal, begins the whole project. It sets out the requirement in general terms and allows the management and its technical advisers to make a viability decision on the proposal.

Once the go-ahead is given, a feasibility study will be commissioned in which all aspects, financial, technical and temporal are drawn together in detail. Solutions are arrived at, and time-scales suggested based on the best estimates then available. Subsequent stages, leading towards the making of a first model, or prototype, involve even greater detail in producing a definition of the project in terms of design parameters and research and development plans.

A considerable amount of data will have been accumulated at this point, and the formalization of design and test specification can be considered. Evaluation documents leading to reliability trials and consideration of maintenance needs will also be started, together with many other reports on progress, processes and investigations.

Each organization has its own way of doing things, and an author in Tech Pubs, or an engineer at any level, will be expected to become familiar with the company’s policy and methods. We shall, therefore, concern ourselves with a standard type of report, and extract only general information common to all such documents.

Our standard report will contain the following features:

1. Title
2. Contents
3. Aim of the document
4. Summary
5. Body of the report
6. Conclusions
7. A bibliography and/or an index may be required in a large-scale report

Broadening this out, these categories should contain:

1. Title: Not a fancy metaphor or double entendre, the title of a report should be informative, stating clearly, and in as few words as possible, what the document is about. If the report has an internal reference number, this should be printed here.
2. Contents: Seldom necessary in a short publication, but is usually included as a matter of course in larger documents.
3. Aim: Why the report was written, its terms of reference, and general purpose.
4. Summary: Many reports are so long and detailed that some readers will not have the time, inclination, or know-how to tackle the whole document.
5. Body of the report: The body copy is the main discussion of the subject. It may be organized according to house-style or the preferences of the author. British Standard BS4811 Report Writing is a valuable reference for writers likely to be much involved in this area.
6. Conclusions: The author of a report will often be asked to make recommendations on the basis of his investigations. This is frequently the main object of the report. The conclusions should flow naturally from the main discussion and not introduce any new material.
7. Index/bibliography: An index is useful if the report is more than just a one-shot operation to reach a conclusion at a point of time. If it is to be a source of reference for a project, an index is invaluable. An index is often prepared by a professional indexer (sometimes found through The Society of Indexers). Most technical writers, however, have at least a rudimentary knowledge of this often arcane subject, and we shall be covering it in this course as part of the Editing module. Bibliographies are usually included if there is an index, determining the importance of the report. It should be noted in passing that Microsoft’s Word WP program contains useful facilities for indexing, footnotes and other apparatus in document making.

Report writing is not the easiest of authorship tasks. It depends on a certain blend of talents: observation first and foremost, combined with organisational skills and a crisp and clear writing style which leaves no room for ambiguity or misunderstanding.

Next: 7. Technical Articles.

This entry was posted on Tuesday, April 18th, 2006 at 5:58 pm and is filed under Technical Writing, Business Writing, Publishing. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.