Previous | Next


UGS-PLM Solutions

by Tony Wacholtz

The second stop on our trip to Ames, IA, was UGS-PLM Solutions. We visited UGS-PLM to get a better grasp on the review process of a document. The company's primary focus is learning-media development, which includes software documentation, tutorials, and Internet-based instructions. Tracey Tomes, Joanie Dooley and Emil Polashek are three of the 12 members of the UGS-PLM Solutions team. The other nine members are located throughout the United States. Networking, E-mail and video conferences are highly important for the members of this team. The team gave us a first-hand look at what technical writers have to go through when they do a review of their documentation.

First, Tomes explained her current project: Teamcenter Community. Teamcenter Community is an online installation help software tool that focuses on experience. The main processes are listed, and underneath each process are links to sub-processes. Within the sub-processes, a user would find information about how to complete each individual step. If a user already knows how to complete a specific step, he or she can bypass it easily and move on. Polashek went on to describe FactoryCad, a project he is currently working on. The software program is designed to aid in the construction industry. It has similar controls as a basic computer assisted drafting program, but it includes specific capabilities aimed at the construction industry. This software makes drafting easier for creating prints for machinery, tools and other such items.

The UGS-PLM Solutions team outlined the documentation process as the members viewed it:

  1. Research - Find out exactly what you need to document. Read specification documents, interview developers, attend meetings, etc. Write down what you found, who you talked to, where the information came from, and any other important information. If someone else needs to take over the project, this will give them a good idea where you are in the research process.

  2. Write Your Planning Document - Plan how you are going to write your documentation. Have the documentation manager look over it; then make any appropriate changes. Resubmit to the document manager until no further changes are needed. Make sure to have your documentation manager sign off on the plans before you move on.

  3. Write Your Documentation - Write the documentation, then have developers look at it. They will be the subject-matter experts concerning your documentation. They will make sure your documentation is technically complete and accurate. Make appropriate changes and resubmit documentation to developers until no further changes are needed. Have the developers sign off on the document when everyone is satisfied.

  4. Submit for Editorial Review - Give your documentation to the editor. He or she will look over the documentation to find errors in grammar, format, organization, etc. If you have time, have a peer review it first. This will cut down on the time the editor needs; most small, typographical errors will be caught before it is sent to him or her. If possible, resubmit to the editor until no further changes are needed, then have him or her sign off on it.

  5. Submit for Product Management Review - Give your documentation to the product manager. He or she will do an overall review of the documentation. If time, resubmit until no further changes are needed. Then, have the product manager sign off on it.

  6. Submit for Documentation Manager Review - Give your documentation to the documentation manager. At this point, you should be giving him or her the finished product. You may need to resubmit to him or her if changes were made along the way. To avoid constant resubmitting, keep your documentation manager updated about any changes made in your documentation as you encounter them. Have the documentation manager sign off on your documentation when he or she is satisfied with it.

  7. Submit for Translation - The document will now be translated into other languages.

Additionally, Tomes mentioned that comments from additional reviews might surface, so a technical writer should keep a positive attitude and a good sense of humor. She stated that you should go through your own documentation to find additional errors. She also suggested that the developers and the technical writers should work closely together to save time.

The UGS-PLM team did a great job explaining the different levels of documentation review that their company uses. It was especially intriguing watching how the review process works for an actual company. It goes above and beyond seeing documentation review as an abstract idea out of a book. The team answered our group's questions very well since they were experienced with the entire process. The UGS-PLM team gave an excellent presentation that provided great insight into the review process of a technical writer's document.