November STC Presentation Posted---
For those who were not able to catch my presentation on Task Support Clusters at the November STC meeting, here is a Camtasia podcast of it.
http://mschoen.libsyn.com/index.php?post_id=288750
Thursday, December 20, 2007
Monday, December 10, 2007
Hockey sticks in Flatland...
The principle is called the law of diminishing returns and its graphical representation is shaped like a hockey stick. Initially there is a sharp increase in the dependent variable for a given change in the independent variable, and then, all of a sudden the curve pretty much flattens out. The point where the steep slope bends and flattens is called the knee.
So what does this have to do with technical communication? Well, my department is heading into a "flat" year, meaning that we are not getting any increase in head count. This can be challenging since we had a couple of replacement positions that now go away, and development is adding headcount, supposedly meaning there will be more products or features to document.
And how does this relate to hockey sticks?
First off, if anyone tells you to "do more with less," hit them with a hockey stick. What you do with less is, well..., less! The point is that if you are going to do less, then you must make sure that you are focusing on those things that add the most value.
And that brings up the most important point: In times of constrained resources you must make sure that when you are committing resources--such as head count, tools, training, and time--you are on the steep part of the hockey stick curve. When you hit the knee, put additional investments on another project.
The independent variables
The independent variables that most writers have some degree of control over are Scope and Quality. The good news is that these are two areas technical communicators are loathe to compromise. The bad news is that when resources are constrained, these areas are inevitably compromised. The only question is will the compromise be a managed one or a random one?
Compromises of scope entail not fully documenting the product. The axis of compromise can be vertical (documentation is shallow in detail but wide in scope) or horizontal (documentation is narrow in scope but deep in detail.) Generally the compromises are made in both axes.
Compromises in quality can occur within two dimensions as well: Accuracy of information and correctness/consistency of language.
Take them out at the knees
In a perfect world, we can estimate our work with great precision and tell folks exactly what we can do and what we can't do. Even in an imperfect world, we can predict along the lines of "I don't know what our exact capacity is, but it will be less this year than last, so we have to cut back somewhere."
And that's where the hockey sticks come in. You must decide how complete you can afford to be and how good it needs to be.
Scope
Start first by evaluating your library. Is every document equally needed? Would the impact of dropping the Quick Start card be the same as dropping the online Help or the Administrator's Handbook? This can get tricky is so far as you have to define impact. I think product acceptance and customer satisfaction with the product are the two biggies, but not always consistent with each other. For example, the lack of Help might hurt acceptance into the market place but not be as critical for day-to-day customer satisfaction.
Next, evaluate if the user is better served with a broad coverage or a deep coverage. Readers of this blog and my column in UXmatters know that in Help my vote goes to broad and shallow. (I don't know where they'll ask for Help, but I know they won't stay in it for long.) Specialized documents might opt for in-depth coverage of a few critical topics. For example, a system admin guide might ignore topics that are common (assuming that a system administrator is familiar with them already) but provide in-depth treatment for activities that are unique to the product at hand.
Quality
How good is good enough? My favorite project management axiom is "Better is the enemy of done." The concept of levels of edit has been around for decades. The knee in the hockey stick essentially is that point at which the user quits noticing. For example, I would hate to send out a document with words misspelled, but I don't know how much extra I would spend to get rid of incorrect uses of transitive versus intransitive verbs such as "An error message displays" or to get rid of comma splices.
The bottom line
No, really, it's the bottom line in my blog:
Are you writing the right stuff for the right folks at a level of quality they will notice? When the answer quits being 'Yes," move additional resources to the next item on your to do list.
The principle is called the law of diminishing returns and its graphical representation is shaped like a hockey stick. Initially there is a sharp increase in the dependent variable for a given change in the independent variable, and then, all of a sudden the curve pretty much flattens out. The point where the steep slope bends and flattens is called the knee.
So what does this have to do with technical communication? Well, my department is heading into a "flat" year, meaning that we are not getting any increase in head count. This can be challenging since we had a couple of replacement positions that now go away, and development is adding headcount, supposedly meaning there will be more products or features to document.
And how does this relate to hockey sticks?
First off, if anyone tells you to "do more with less," hit them with a hockey stick. What you do with less is, well..., less! The point is that if you are going to do less, then you must make sure that you are focusing on those things that add the most value.
And that brings up the most important point: In times of constrained resources you must make sure that when you are committing resources--such as head count, tools, training, and time--you are on the steep part of the hockey stick curve. When you hit the knee, put additional investments on another project.
The independent variables
The independent variables that most writers have some degree of control over are Scope and Quality. The good news is that these are two areas technical communicators are loathe to compromise. The bad news is that when resources are constrained, these areas are inevitably compromised. The only question is will the compromise be a managed one or a random one?
Compromises of scope entail not fully documenting the product. The axis of compromise can be vertical (documentation is shallow in detail but wide in scope) or horizontal (documentation is narrow in scope but deep in detail.) Generally the compromises are made in both axes.
Compromises in quality can occur within two dimensions as well: Accuracy of information and correctness/consistency of language.
Take them out at the knees
In a perfect world, we can estimate our work with great precision and tell folks exactly what we can do and what we can't do. Even in an imperfect world, we can predict along the lines of "I don't know what our exact capacity is, but it will be less this year than last, so we have to cut back somewhere."
And that's where the hockey sticks come in. You must decide how complete you can afford to be and how good it needs to be.
Scope
Start first by evaluating your library. Is every document equally needed? Would the impact of dropping the Quick Start card be the same as dropping the online Help or the Administrator's Handbook? This can get tricky is so far as you have to define impact. I think product acceptance and customer satisfaction with the product are the two biggies, but not always consistent with each other. For example, the lack of Help might hurt acceptance into the market place but not be as critical for day-to-day customer satisfaction.
Next, evaluate if the user is better served with a broad coverage or a deep coverage. Readers of this blog and my column in UXmatters know that in Help my vote goes to broad and shallow. (I don't know where they'll ask for Help, but I know they won't stay in it for long.) Specialized documents might opt for in-depth coverage of a few critical topics. For example, a system admin guide might ignore topics that are common (assuming that a system administrator is familiar with them already) but provide in-depth treatment for activities that are unique to the product at hand.
Quality
How good is good enough? My favorite project management axiom is "Better is the enemy of done." The concept of levels of edit has been around for decades. The knee in the hockey stick essentially is that point at which the user quits noticing. For example, I would hate to send out a document with words misspelled, but I don't know how much extra I would spend to get rid of incorrect uses of transitive versus intransitive verbs such as "An error message displays" or to get rid of comma splices.
The bottom line
No, really, it's the bottom line in my blog:
Are you writing the right stuff for the right folks at a level of quality they will notice? When the answer quits being 'Yes," move additional resources to the next item on your to do list.
Friday, December 07, 2007
New Year's Resolutions---
Getting close to that time of year, so I'm starting my list:
Getting close to that time of year, so I'm starting my list:
- I will not whine about anything more than once. (Hey! once is therapeutic, keeps the ulcers away.)
- I will be part of the solution, or I will shut up (other than the exception allowed in resolution 1).
- I have a big presence, so I will try hard to be small and make room for others.
- When the team needs someone big, I will quit trying so hard to be small.
I'm sure I'll think of others.
Subscribe to:
Posts (Atom)