[Fwd: Re: Document Post Analysis]

Subject: [Fwd: Re: Document Post Analysis]
From: Dick Margulis <margulis -at- fiam -dot- net>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Sun, 23 Nov 2003 07:32:21 -0500


Anachie Shakespear wrote:

Hi:

Has anyone out there had any experience in conducting a document post analysis, both from a customer point of view and from an internal point of
view (engineers, writers, marketing folks, etc.)...

I'd be most grateful to receive information on how to initiate this process and what to include, what not to include, and if you have some preset
documents that you would be willing to share that would be great (you can of course remove sensitive data).
Also, I'd be willing to share the info with those folks interested in the answers.

A.


A.,

Mostly I wouldn't bother. Certainly, it's something I've never done. But fools rush in and all that, so here are some thoughts on how such a process _might_ be useful in a sufficiently large, bureaucratic, and anal organization.

What you want to know is how to make the next document better, so you want to save the good stuff and figure out what went wrong that led to the bad stuff.

First draw a workflow diagram, if you don't already have one, that shows the standard process for creating the document. This should have titles/roles at the nodes, flow arrows showing how the document gets passed, and cycle-times (number of days or whatever) captioning the arrows to show how long a step was supposed to take. Put a letter on every node and a number on every arrow. Do this in Visio or the equivalent.

Now make a second layer that is an exact copy of the first (standard) layer. The second layer will be where you do part of the analysis for the particular document. Put individuals' names at the nodes. Make the arrows green if the step happened within the prescribed cycle time. Make the arrows red if they didn't.

First level of analysis: Is there one node from which many red arrows emanate? This is not about blaming the person but about analyzing the process. So unless you know that someone is personally an obstructionist by nature, you want to withhold judgment until you've done a similar analysis for documents from different projects/different teams. You may find that the step is being requested of the wrong role or an understaffed department, for example.

Next, list criteria for document evaluation:

i. Accurate
ii. Organized for accessibility of information
iii. Well written/edited
iv. Engages customer
v. Conveys company branding/messaging
vi. On time

Make up your own list--I'm just throwing those out as possibilities. Do rank them in order of priority.

Next to each of the criteria identify which node or nodes on the diagram (letters) have responsibility for ensuring that it is met; next to each letter, in parens, list which arrow in particular is involved, if there is any ambiguity. If you have an evaluation criterion for which you cannot assign a responsible node, bingo, you've got a problem right there, and your workflow needs to be fixed to address it. For example, where in your process are customer expectations identified and expressed? If there isn't anyplace, then asking whether the document meets the customer's expectations is pointless, right? If you identify a problem at this point, don't bother analyzing the document. Instead, fix the process and do you post analysis after the next documentation cycle.

Assuming you've made it past this test, go on to the analysis of the document in question ...

Next make a spreadsheet.

In the first column list the sections of the document at whatever level of granularity you want to analyze (whole document, chapter, topic, paragraph--your choice/your budget).

Assign the second through nth columns to the criteria you listed in the previous step. Each column can belong to a single evaluator or all of them can belong to an evaluation committee--however makes the most sense to you. For example, the marketing department could own the column about company branding and messaging.

In evaluating the document, assign grades in every cell of the spreadsheet. Calculate average grades for each column.

Make a list of all the nodes and a list of all the arrows on your diagram. Now trace back through the criteria listing to see which nodes/arrows each of these average grades applies to and write it next to the list entry. For each node or arrow with multiple grades, calculate an average grade (although this is not necessarily the most interesting feature).

Second level of analysis: Does the number of grades next to a given role appear to have an impact on the average grade? For example, does someone who is responsible for six steps consistently have a lower average grade than someone who is responsible for a single step? If so, rethink the process. Are there nodes to which no grades are assigned? If so, how are they helping? Are there nodes that consistently show high grades? Good. It ain't broke; don't fix it. Are there nodes that consistently show low grades? Can you suss out why that's the case (is it the person or the role or the process)? Can you propose a way to mitigate the problem?

Anyway, those are some thoughts. Time for another cup of coffee.

Dick





---
[This E-mail scanned for viruses at mail.fiam.net]


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP FOR FRAMEMAKER TRIAL NOW AVAILABLE!

RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web. The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4

---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit
http://www.raycomm.com/techwhirl/ for more resources and info.



Previous by Author: A data point on offshoring
Next by Author: Re: Use of A and An
Previous by Thread: Re: Document Post Analysis
Next by Thread: Re: Career moves? What jobs are technical writers likely to move toward


What this post helpful? Share it with friends and colleagues:


Sponsored Ads