An Agile Review Process for Technical Documentation

Documentation teams need a fast and effective review process to move forward on their projects and deliver quality, timely content. Reviewers, may they be SMEs (Subject Matter Experts) or key organization authorities, are usually extremely busy and have limited time (or interest) to review documentation. Interesting dilemma, no?

Talbot, Fabrice. LiveTechDocs (2008). Articles>Documentation>Agile>Workflow

Documenting the Flow of Rule-Based Programming in Expert Systems  

With the spread of new technology, technical communicators face interesting new challenges for solving documentation problems. One area of software development that technical communicators are increasingly becoming involved in is that of rule-based expert systems. Because of their complexity, both the systems and their documentation can be difficult to maintain. Technical communicators can solve some of these maintenance problems by flow-charting only the chaining structure of the rule-base design.

Glover, Kyle S. STC Proceedings (1994). Articles>Documentation>Programming>Workflow

Documenting While on Patrol    

While the jobs of Mary Clouse and the rest of the Security and Documentation Unit of the New York State Senate Technology Services department aren't as glamorous as those of the senators themselves, they ensure that the Senate can use its automated systems to conduct its daily business smoothly, efficiently, and securely.

Clouse, Mary. Intercom (2008). Articles>Documentation>Workflow

How Design Documents Enhance Information Product Development Process Quality  

Panelists from LSI Logic Storage Systems review their company's approach to enhancing process quality by using design documents as process enforcement and project-planning tools for planning the development of information products (IP). Hear how effective planning solves problems that occur during the IP development process and how capturing the planning elements in design documents helps solve role-based problems for developers, editors, and managers. Discuss the many problems design documents help project teams solve: they help developers solidify the IP development task sequence, they help editors define the rhetorical context, and they help managers reduce the cost of rework.

Burroughs, Dia H., Randy Clark, Sylvia McCombs and Tony Washington. STC Proceedings (2004). Articles>Documentation>User Interface>Workflow

Making Product Information an Integral Part of the Development Process  

Document inspections formalize the document review process and encourage the full participation of technical developers in the documentation development process. A document inspection consists of three parts: a briefing meeting, a desk review, and a recording meeting. At the briefing meeting, you state your requirements for the inspection process. During the desk review, the technical developers review your document. At the recording meeting, you review the comments made by the technical developers, and as a group decide on appropriate resolutions.

Hildebrand-Lund, Ruth. STC Proceedings (1996). Articles>Documentation>Workflow>Technical Writing

A Procedure Development Model  

Procedure development can be a challenging task, especially since the process of procedure development is not easily defined. The methodology portrayed in the Ten-Step Process for Procedure Development may serve as a useful model for you to adapt and customize.

Whitmer, Diane L. STC Proceedings (1995). Articles>Documentation>Workflow

Re-engineering the Documentation Process: Doing More with Less to Keep Up with Increased Customer Needs  

For the past ten years, the Documentation Department at Hayes Microcomputer Products, Inc. has undergone numerous changes and evolutions--many to keep up with changing technology and market needs, many to accommodate organizational shifts and restructuring. This presentation sheds light on some of the innovative and creative ways the department has been reorganized and the dynamic documentation strategies that have been put into practice as a result.

Belcher, Gena, Scott DeLoach and Juliette Jandel-Leavitt. STC Proceedings (1995). Articles>Documentation>Workflow

Software Documentation Process - McGraw-Hill School Systems  

This panel presents the software documentation processes of three companies. At McGraw-Hill School Systems, the technical writers are involved in every stage of the software development life cycle. This approach ensures that writers are always in control of the information they need and that sufficient time is available for the documentation process. Our involvement allows us to produce high-quality documentation that is up-to-date with the software’s functionality.

Rogers, Anne E. STC Proceedings (1996). Articles>Documentation>Workflow>Collaboration

Software Documentation Process-Datastream Systems, Inc.  

This panel presents the software documentation processes at 3 companies. At Datastream, a software development company with approximately 200 employees, we, the technical writers, have integrated ourselves into all stages of the software development process. Additionally, we have incorporated the tenets of document cycling into our documentation process. In this paper and in our presentation, we outline our documentation process. We do not prescribe our approach but instead hope that it sparks a dialog among software documentation writers in similar companies so that we may learn from each other.

Jeansonne, Jerold and Amy J. Listeman. STC Proceedings (1996). Articles>Documentation>Workflow

The Technical Writing Process  

The technical writing process consists of four phases: planning, writing, delivery and archiving. The phases of the technical writing process are not necessarily discrete. You might start the writing phase before you complete the planning stage, for example, or you might have to deliver the documentation before you feel it is finished. It is highly unlikely, however, that you will ever archive the documentation before you deliver it! Some products are released several times. In this situation, you might be in the delivery phase of the first iteration of the project while you are in the planning phase of the second iteration. Don't panic: overlap in the technical writing process is quite normal.

Docsymmetry (2003). Articles>Documentation>Workflow>Technical Writing

Of the Importance of Documenting

Documentation is important, from the end users to the developers, if you want your project to self sustain, if you want to ease the life of other people, and if you want your project to live a long and prosperous life. People were not in your head (and are not in your head) when you wrote that strange thing. 1-2 years from now you could be working for another company, what would be of other people who are trying to understand what you wrote? How would people easily understand how things work in a complex environment?

Casagrande, Milo. WordPress (2009). Articles>Documentation>Workflow>Policies and Procedures