Tuesday, July 29, 2003
After finishing up on the Unified Content Strategy, the reflexive use of content management systems, pointing them inward into the authoring of structured text, particularly when coupled with business intelligence (BI) systems performing queries on unstructured data, and then reorganizing this structured text for the external stakeholders, is interesting. You move from capturing customer and transactional data and presenting stakeholder-oriented documents and information touchpoints to capturing the sources and underlying data for these documents and creating the content. BI queries on unstructured data typically captured on email servers represents a new source of content and a broader view than was previously available.
Unified Content Strategy was intentionally constructed to play well with translation memories. But, here too I sense that loss of treatment variety, while cheaper to translate, still push the cost of learning off onto the customer where it doesn't belong. This has me thinking that we need to organize translation memories and treatment variety around central metaphors and be deliberate about our treatment variety.
An example of what I am talking about was my efforts to document a code profiler. There was vocabulary from practitioners that talked about register pressure and such. The project manager dictated that such language not be used. The language was to stay specific to the GUI created by functionality focused programmers based entirely on the automation domain. So the application was not going to speak in a voice from the domain from which the requirements were taken. The tasks were going to be tool tasks. User tasks were not going to be documented.
Treatment variety centers on language, culture, knowledge domains, vocabulary, and metaphors. In marcom and advertising, you write a treatment document before you write your content. The treatment document serves as the basis for a campaign and drives consistent language and metaphor use. In some sense, the various information touchpoints like documentation, marcom, and training differ in terms of treatment. Documentation isn't allowed to make competitive claims and must sell through specifics. Marcom makes its home in competitive claims. Training focuses on scenarios where documentation focuses on use cases.
But, back to the code profiler for a minute. The interface dictated the notion that code was linear. It ran from address a to address b. But, MFC is a loop. Another author explained your application as a lifeboat in a sea of code. There were boundaries to the lifeboat, but there were also sump pumps and holes in and out of which code would seap without notice. Given the propensity towards memory leaks, yes, we have a leaky boat. I didn't use the lifeboat metaphor, but we had our own way of talking about putting a box around the code. The GUI set execution limits to compensate for the leaks in the boat, or the notion that the code would never cross those lines of demarcation built into the GUI. Better metaphors make for better explainations for specific audiences. But, what happens when the audience is broader that the box you put the audience in when you eliminate content variety?
So what do we get with the use multiple treatments that incorporate or expand the audiences? We get people who can select their own metaphors, the ones they understand, and their own language. So how would we make this scheme work? First, instead of seeing variation and calling it bad, we would need a set of accepted treatments. Basing these treatments on different audiences would be good. Second, we would need to see that some variation fell into one of the approved treatments, or we would rewrite it. You might assign different writers to different treatments. And, you would expect your editors to make the system work.
Structured writing and content management systems including the Unified Content Strategy concept need not eliminate treatment variety. They need not lead to a lack of understanding on the part of the customer, or increased costs in the customer organization. It might increase the production costs on the vendor side, but the returns from the effort, particularly where translation is going to complicate understanding, should be large enough to swamp the costs.
Unified Content Strategy was intentionally constructed to play well with translation memories. But, here too I sense that loss of treatment variety, while cheaper to translate, still push the cost of learning off onto the customer where it doesn't belong. This has me thinking that we need to organize translation memories and treatment variety around central metaphors and be deliberate about our treatment variety.
An example of what I am talking about was my efforts to document a code profiler. There was vocabulary from practitioners that talked about register pressure and such. The project manager dictated that such language not be used. The language was to stay specific to the GUI created by functionality focused programmers based entirely on the automation domain. So the application was not going to speak in a voice from the domain from which the requirements were taken. The tasks were going to be tool tasks. User tasks were not going to be documented.
Treatment variety centers on language, culture, knowledge domains, vocabulary, and metaphors. In marcom and advertising, you write a treatment document before you write your content. The treatment document serves as the basis for a campaign and drives consistent language and metaphor use. In some sense, the various information touchpoints like documentation, marcom, and training differ in terms of treatment. Documentation isn't allowed to make competitive claims and must sell through specifics. Marcom makes its home in competitive claims. Training focuses on scenarios where documentation focuses on use cases.
But, back to the code profiler for a minute. The interface dictated the notion that code was linear. It ran from address a to address b. But, MFC is a loop. Another author explained your application as a lifeboat in a sea of code. There were boundaries to the lifeboat, but there were also sump pumps and holes in and out of which code would seap without notice. Given the propensity towards memory leaks, yes, we have a leaky boat. I didn't use the lifeboat metaphor, but we had our own way of talking about putting a box around the code. The GUI set execution limits to compensate for the leaks in the boat, or the notion that the code would never cross those lines of demarcation built into the GUI. Better metaphors make for better explainations for specific audiences. But, what happens when the audience is broader that the box you put the audience in when you eliminate content variety?
So what do we get with the use multiple treatments that incorporate or expand the audiences? We get people who can select their own metaphors, the ones they understand, and their own language. So how would we make this scheme work? First, instead of seeing variation and calling it bad, we would need a set of accepted treatments. Basing these treatments on different audiences would be good. Second, we would need to see that some variation fell into one of the approved treatments, or we would rewrite it. You might assign different writers to different treatments. And, you would expect your editors to make the system work.
Structured writing and content management systems including the Unified Content Strategy concept need not eliminate treatment variety. They need not lead to a lack of understanding on the part of the customer, or increased costs in the customer organization. It might increase the production costs on the vendor side, but the returns from the effort, particularly where translation is going to complicate understanding, should be large enough to swamp the costs.
Friday, July 11, 2003
Earlier this week I ran across the Unified Content Strategy concept. It's about using single sourcing across the enterprise. As an audit you look at all the documents mentioning the same thing and eliminate the variation by creating a single chunk of text to be used in all those contexts. It's about eliminating treatment variety.
I don't believe in eliminating treatment variety, because I have been a user of an application where they did just exactly that. I was taking an Interleaf class. I wanted to do something with text variables. They called their chapter on text variables "Effectivity," a particular application of text variables and not the one I had in mind. I looked in the help and it said exactly the same thing that the user manual did. I looked in the training manual, same result. So what did treatment variety get me as a user, nothing. And, that is why eliminating treatment variety is a bad idea.
I insist that user manuals be written in the learn context. The reader wants to learn the application, so they read a manual. I insist that help be written in the do context. They are trying to do real work and the application is getting in the way, so they read help. The content is different. The text is going to be different. Yes, a procedure in help is a subset of the procedure in the manual, but they are different. It gets even worse when you consider that a task will appear in the user manual, help, quick start guide, quick reference card, and training manuals.
In the Unified Content Strategy approach, the same text is used in documentation as in sales literature and marketing communications (marcom). There is no acknowledgement that these documents differ in treatment, intent, approach, and ethic. Technical writers don't put competitive claims in their content. Marcom writers do. So how can you use the same text? Getting atomic enough like down to the sentence is helpful, but still difficult. Inheritance can help writers create derivative texts. But, using the same text without derivatives creates problems for the company and the customer.
At the core single sourcing is a cost management strategy. It is being leveraged from the documentation world to the content management world in the Unified Content Strategy approach. Technical writers see it as professionalizing. But, they are firmly buying into being a cost. When you are a cost, you can be cost managed.
I've looked into the value-adds of technical writing for a long time going back well before Ginny Redish's well known study of the value-adds. One of the notions that came out of her study is the elimination of technical support calls as a documentation value add. That seems reasonable enough, but it is a cost management issue. It is internal to the vendor. It is not customer centric. And, it doesn't generate any revenues. It is departmental. It is totally within the scope of the supply chain manager.
For me an appropriate value add must contribute revenue to the bottom line. Technical writers do this by ensuring expertise development and customer retention, so that the vendor can sell the customers upgrades. Vendors make most of their money from the sale of upgrades. They make more money this way than from selling customer support, or nickle and diming customers for manuals and such. Technical writers also contribute to the inital sale. These value adds are not about cost management, cost centers, or conversion to profit centers. These value adds are strategic and integrating across the enterprise. They provide a path into higher management, but they are not the obvious, departmental, so called value adds.
The economics of production vs. use come into play here. Ultimately, a successful product with a large customer base drives the cost of producing documentation to zero. So we are managing a zero. But, a manual induces costs in the customer organization--invisible costs. Reading is not an activity that can be quantified in dollar terms in any accounting system, so manuals are an invisible cost to the customer in terms of the salary contributions for the time readers spend reading. All supply chain information components have this problem: tutorials, desktop training, user assistance, free technical support calls, and the salary contribution for all technical support calls. Other elements of the user experience are subject to this same problem: time spent on bugs, users doing installation and configuration tasks. If time is spent on any aspect of the software itself, instead of real work, the costs are negative use costs. And, when users spend time this way, it is invisible to the accounting system.
Negative use costs were defined by Gartner at the time Gartner conceived of the Total Cost of Ownership (TCO). These costs were omitted from the TCO, because they couldn't be quantified in the accounting system. The TCO is about costs identified and controlled in the accounting system relative to owning and using software applications.
The current IT recession is only partially the fault of the dot bust. CFOs have long had a suspicion that they were not getting productivity from their IT investments. You can argue that computing isn't about productivity improvements, in the accounting system sense of the word, but you can't make that arguement with a CFO or economic buyer.
Ultimately, single sourcing increases the customer's negative use cost. This is bad.
Another aspect of single sourcing is that it is a cost management tool. Software companies are the most capital efficent businesses on the planet. This hints are any real need to cost manage. There are reasons for this captial efficency that have a lot to do with the way software companies are managed. VCs invest for money. They expect software companies to create wealth, rather than cost manage. Only after the IPO and the VC exit, when a company becomes institutionalized will cost management make sense. And, even then it depends more on what part of the product lifecycle we are talking about. Geoffry Moore's technology adoption lifecycle (TALC) makes it clear that operational excellence should be a goal only in the late mainstream market where techical differentiators have vanished, the products are becoming commodities, and UI controls are being sublimated. Single sourcing is part of that operational excellence paradigm. There are four other serial, management paradigms in the TALC.
A content distributional strategy is not the same thing as a unified content strategy. They can be used together. They really identify approaches to different aspects of the documentation and information touchpoint domain. We will explore that.
I don't believe in eliminating treatment variety, because I have been a user of an application where they did just exactly that. I was taking an Interleaf class. I wanted to do something with text variables. They called their chapter on text variables "Effectivity," a particular application of text variables and not the one I had in mind. I looked in the help and it said exactly the same thing that the user manual did. I looked in the training manual, same result. So what did treatment variety get me as a user, nothing. And, that is why eliminating treatment variety is a bad idea.
I insist that user manuals be written in the learn context. The reader wants to learn the application, so they read a manual. I insist that help be written in the do context. They are trying to do real work and the application is getting in the way, so they read help. The content is different. The text is going to be different. Yes, a procedure in help is a subset of the procedure in the manual, but they are different. It gets even worse when you consider that a task will appear in the user manual, help, quick start guide, quick reference card, and training manuals.
In the Unified Content Strategy approach, the same text is used in documentation as in sales literature and marketing communications (marcom). There is no acknowledgement that these documents differ in treatment, intent, approach, and ethic. Technical writers don't put competitive claims in their content. Marcom writers do. So how can you use the same text? Getting atomic enough like down to the sentence is helpful, but still difficult. Inheritance can help writers create derivative texts. But, using the same text without derivatives creates problems for the company and the customer.
At the core single sourcing is a cost management strategy. It is being leveraged from the documentation world to the content management world in the Unified Content Strategy approach. Technical writers see it as professionalizing. But, they are firmly buying into being a cost. When you are a cost, you can be cost managed.
I've looked into the value-adds of technical writing for a long time going back well before Ginny Redish's well known study of the value-adds. One of the notions that came out of her study is the elimination of technical support calls as a documentation value add. That seems reasonable enough, but it is a cost management issue. It is internal to the vendor. It is not customer centric. And, it doesn't generate any revenues. It is departmental. It is totally within the scope of the supply chain manager.
For me an appropriate value add must contribute revenue to the bottom line. Technical writers do this by ensuring expertise development and customer retention, so that the vendor can sell the customers upgrades. Vendors make most of their money from the sale of upgrades. They make more money this way than from selling customer support, or nickle and diming customers for manuals and such. Technical writers also contribute to the inital sale. These value adds are not about cost management, cost centers, or conversion to profit centers. These value adds are strategic and integrating across the enterprise. They provide a path into higher management, but they are not the obvious, departmental, so called value adds.
The economics of production vs. use come into play here. Ultimately, a successful product with a large customer base drives the cost of producing documentation to zero. So we are managing a zero. But, a manual induces costs in the customer organization--invisible costs. Reading is not an activity that can be quantified in dollar terms in any accounting system, so manuals are an invisible cost to the customer in terms of the salary contributions for the time readers spend reading. All supply chain information components have this problem: tutorials, desktop training, user assistance, free technical support calls, and the salary contribution for all technical support calls. Other elements of the user experience are subject to this same problem: time spent on bugs, users doing installation and configuration tasks. If time is spent on any aspect of the software itself, instead of real work, the costs are negative use costs. And, when users spend time this way, it is invisible to the accounting system.
Negative use costs were defined by Gartner at the time Gartner conceived of the Total Cost of Ownership (TCO). These costs were omitted from the TCO, because they couldn't be quantified in the accounting system. The TCO is about costs identified and controlled in the accounting system relative to owning and using software applications.
The current IT recession is only partially the fault of the dot bust. CFOs have long had a suspicion that they were not getting productivity from their IT investments. You can argue that computing isn't about productivity improvements, in the accounting system sense of the word, but you can't make that arguement with a CFO or economic buyer.
Ultimately, single sourcing increases the customer's negative use cost. This is bad.
Another aspect of single sourcing is that it is a cost management tool. Software companies are the most capital efficent businesses on the planet. This hints are any real need to cost manage. There are reasons for this captial efficency that have a lot to do with the way software companies are managed. VCs invest for money. They expect software companies to create wealth, rather than cost manage. Only after the IPO and the VC exit, when a company becomes institutionalized will cost management make sense. And, even then it depends more on what part of the product lifecycle we are talking about. Geoffry Moore's technology adoption lifecycle (TALC) makes it clear that operational excellence should be a goal only in the late mainstream market where techical differentiators have vanished, the products are becoming commodities, and UI controls are being sublimated. Single sourcing is part of that operational excellence paradigm. There are four other serial, management paradigms in the TALC.
A content distributional strategy is not the same thing as a unified content strategy. They can be used together. They really identify approaches to different aspects of the documentation and information touchpoint domain. We will explore that.
Monday, July 07, 2003
Content distributional strategy organizes content across the enterprise and spans the functional stovepipes. Content dristributional strategy reaches beyond documents to information touchpoints and link anchors.
Let's see where a content dristibutional strategy can take us.
David Locke
Let's see where a content dristibutional strategy can take us.
David Locke
Content distributional strategy happens. Usually just that way. You hire a writer. They create a manual. Then, you hire a technical support person. They create entries in a technical support database. Then, you hire a marketer. They create some marketing communications collateral. Before you know it you have a pile of stuff. And, you have a content distributional strategy as a collection of individually created policies, policies that are unlikely to be aligned towards the purposes of the enterprise.
That strategy probably allows for redundancy, treatment variety, isolation, and a wide variety of recognitional and identity elements. That strategy probably doesn't extend to all information touchpoints, integrate the content into an integrated marketing database, nor organize itself consistent with enactment chains, curriculum marketing, and response management.
Even if you could clearly state that "We sell training," do you really put the resources on that training and pay attention to pedological issues like the learner's psychological state?
Even if you could say that we have an information architect, does that architecture reach beyond the website and across every information touchpoint internally and externally? Does that architecture support the enterprise?
Even if you could say that we have a content management system and chunk content for reuse, what are the upsides and downsides of that? How could cutting production costs cost you money in the long run? Were is the increasing return in the loss of content variety?
With the advent of systems capable of handling unstructured data and initiating authoring and the structuring of that data, the responsibility for content is being distributed. Does everyone in the content value chain understand each other's role? Does everyone understand content flows inside your enterprise, across your supply chain, and into your customer's processes? Does maximizing costs savings and offloading costs to your customer really fit your intentions of retention, relationship, and quality?
Who develops the policies? Everyone and no one. Content distributional strategy happens.
David Locke
That strategy probably allows for redundancy, treatment variety, isolation, and a wide variety of recognitional and identity elements. That strategy probably doesn't extend to all information touchpoints, integrate the content into an integrated marketing database, nor organize itself consistent with enactment chains, curriculum marketing, and response management.
Even if you could clearly state that "We sell training," do you really put the resources on that training and pay attention to pedological issues like the learner's psychological state?
Even if you could say that we have an information architect, does that architecture reach beyond the website and across every information touchpoint internally and externally? Does that architecture support the enterprise?
Even if you could say that we have a content management system and chunk content for reuse, what are the upsides and downsides of that? How could cutting production costs cost you money in the long run? Were is the increasing return in the loss of content variety?
With the advent of systems capable of handling unstructured data and initiating authoring and the structuring of that data, the responsibility for content is being distributed. Does everyone in the content value chain understand each other's role? Does everyone understand content flows inside your enterprise, across your supply chain, and into your customer's processes? Does maximizing costs savings and offloading costs to your customer really fit your intentions of retention, relationship, and quality?
Who develops the policies? Everyone and no one. Content distributional strategy happens.
David Locke
