One of my favorite weekend pastimes is sailing. Garage sale-ing that is. (Note to self: that pun works better out loud than on screen…). Gslar.com has a nifty mapping app that allows me to chart a route to local garage sales, local estate sales, and multi-family yard sales. It includes a trip planner with directions. Imagine if TechNet/MSDN offered a version of this that allowed you to plan an itinerary of tech events and/or user group meetings? If you’d like to see something like that, leave comments here – better yet, why not mash it up yourself and let us all know about it here?
I browse for books, games and music. Nothing beats $.99 cds. On a recent trip I found the 1995 Bugs in Writing by Lyn Dupre. This got me thinking about applying Six Sigma methodology to technical writing. I was discussing it with a colleague that had some disappointments with previous attempts at applying SixSig to improve quality in writing.
We talked about defining the “defect” as “failure to meet the customer expectation." Teams he’d worked with in the past had trouble producing an action they could take to improve quality.
I tried a poker analogy on him that seemed to resonate. Using an FMEA approach:
If your goal is to win at poker, then the first thing you should do is stop losing (failure mode). The most important of the many causes of this failure mode is what the poker-types call “playing too many hands.” This just means that if you play fewer, higher-quality hands, you will loose less often than if you play any two cards. There is a whole poker book industry devoted to ranking the fine degrees of severity of this cause. Because of the frequency at which they win, some say you should only play the top 10 starting hands, or fold everything except the top 12 starting hands. Some say only play the top 20 hands. In any case, frequency is not really a challenge – you make the decision every hand pre-flop. Detection can be tricky, because it has two parts: you always see your hand, but sometimes you can figure out what your opponent is likely to have as well. This is called a “poker tell”, “read”, and sometimes “putting them on a hand.” Following this strategy will get you toward your goal, you will have easier decisions, and make fewer mistakes, with less disastrous effects, than if you played more hands.
Apply this to creating technical content. We have data that shows that one of the things that dissatisfy IT Pros the most is not being able to quickly find the content they need (failure mode). This is actually easy for us to detect, we have direct feedback on the general problem, and we have search terms data that tells us the specifics. So, the best starting strategy to tackle this problem is to make it easier for IT Pros to quickly find the content they need. We can use SEO tools and techniques on content that is already on TechNet, and then ensure that all new content has good keywords, and descriptions, and such. We can start with the trouble-shooting content, as we know this is the most dissatisfying content across our set of content.
What are your thoughts about trying to get content teams to look at it this way? Better metaphors? Alternate approaches? Leave comments – much appreciated in advance.