I read an interesting article the other day via TheContentWrangler, which discussed managerial use of (or lack there of) performance metrics in evaluating writers. The article stated that most technical communications managers have a background in English or journalism and find writing skill and experience to be the most valuable skill set.

Seeing that I have a background in English, I’m curious what metrics can be used to evaluate writing performance. I’ve seen folks in the consulting world use metrics to log “state changes” throughout the day to determine how much “mental firing” they’re putting into their work. As it turns out, most people tend to write, from scratch, for about 15 minutes at a time. There’s also a much quoted statistic that it takes a writer about four hours to write one page of documentation. What other metrics can be used? The amount of documentation produced in a given period of time?

The full article for this topic can be found at < Most Managers Don't Use Metrics As Performance Measure

The prospect of creating an information space suitable to an entire organization is quite overwhelming. Equally overwhelming, however, is developing the appropriate strategy to get you there, the blueprint for ensuring success. It’s much like trying to build a three-dimensional puzzle where one piece has to fall into place before another, on an entirely different layer, finds its place. There are so many things to consider in developing a suitable strategy: politics, business drivers, maintenance, administration, infrastructure, indexing, metadata, search engine optimization, etc.

Where do you start when building an information space? Do you start with a top-down or bottom-up approach? Technical communication professionals would probably argue for a bottom-up approach of starting with the content and the proper management of it. On the other hand, is it more suitable to have two teams working on such a project? One team focusing on the content and another focusing on the top-down approach of information architecture?

I just finished reading an article from the AIIM Knowledge Center Blog entitled Indexing - Applying Metadata to Records and Information within the Organization. As a key contributor working in the beginning stages of a content management system implementation, I found the article quite interesting.

At present, I’m doing research on metadata and working on the development of metadata elements to use in documentation that will eventually be migrated into a CMS repository. The AIIM article called attention to some interesting points, one of which applies heavily to my current working situation. How can you create a metadata model extensible enough to handle the needs of an enterprise-wide documentation set? An excerpt from the AIIM article reads as follows:

"You will need to develop your policy and guidelines for capturing metadata.  For example, is it best for your organization to capture metadata for all documents (recognizing that only some will become records later) or should you just capture metadata for those documents that you declare as records.  You will also need to define what metadata elements should be captured for different types of records.  You will want to create a metadata model for your organization."

Although I’ve been focusing a lot of energy on the design and presentation of information lately, it’s always important to remember the basics of writing: grammar, sentence structure, voice, etc. That being said, I recently stumbled upon a great blog dedicated to common writing snafus: Daily Writing Tips. As an example, one article discussed how to properly use the pronoun pair of who/whom (an area I sometimes slip up). By using an example of a mystery novel, the article quickly, and in easy to understand terms, provided a clear answer:

"To understand the use of pronoun pairs such as who/whom, he/him, she/her, I/me, they/them, and we/us when used with a verb, one must recognize whether the word is being used as the subject of the verb or as its object."