STC UK...almost live, part 2...Managing change
posted by Sarah
Ant Davey, Rail Standards Safety Board (RSSB)

Another excellent session. Ant provided a discussion of change management with quite a lot of references to more detailed resources.

Knowledge is being lost.
Information has value.
Web is changing search methods and expectations.
Web is changing ability to contribute and review content.

Findable information requires chunking.
Chunks are potentially reusable.
Ultimately, you have single sourcing.
Not "how we have always done it."

Chunking requires modular and collaborative writing.
Not "how we have always done it."

Single sourcing @ RSSB
* Still finding our way
* Technology led (in part)
* Starting to introduce standard templates
* Paving the way by communicating
* Planning an XML pilot

Change management
* Linking people and processes toward a desired change
* change is not where you are now
* need to know where you are going and tell those who you want to come with you
* "you are almost certainly under-communicating by a factor of at least 10 and possibly 100"

Carrying people with you. People view change as an attack on their current competence. Need to begin by celebrating what they have been doing right. 5-25% of people can't or won't be able to work with the new processes (Emma Hamer)

The change equation:

C = (ABD) > X

C = change
A = dissatisfaction with status quo
B = desirability of the new end state
D = risk and disruption to get there
X = cost of changing (effort, discomfort, difficulty, risk)

Carrying people with you
* celebration with is working
* explain what isn't and why
* describe how it will be with the new methods
* what's in it for them
* what's in it for the company
* what's in it for the clients

WIIFM = What's in it for me

* Active supporters
* Active dissenters
* Passive supporters
* Passive dissenters

Creating a change team
* You can't do all this by yourself.
* Special skills, talents, and leadership
* Where you can't carry, you may have to push or reallocate

First, Break All the Rules
Marcus Buckingham

Leadership is different from management. (That is SO true.)

Team members
* Champion or sponsor
* sustaining sponsor
* implementer
* change agent
* advocate

* group
* different styles, methods, and needs
* different personality types
* similar team gets quick results
* team with differences gets better result

Where change management goes wrong
* too much complacency
* lack of power in the guiding team
* not having real vision
* under-communicating (effectively)
* allowing obstacles to block the vision
* no short-term wins
* declaring victory too soon
* not embedding changes in practice

learning cycle
* concrete experience for activists
* reflective observation for reflectors
* theoretical concepts for theorist
* practical experimentation for pragmatists
(Experiential Learning, Kolb)

change
* needs leadership and vision
* needs good management
* needs metrics
* because ultimately it's about money
* increase revenue
* decrease costs
* make people's lives easier
* concentrate on the outcomes
* leave individuals to develop their own implementation plans

business process re-engineering
Customer led analysis method for business re-engineering
1. establish the scope
2. target the customer
3. model the process
4. analyze the structure
5. create the opportunity
6. redesign the process
7. refine the customer experience
8. ??

Why?
* customers dissatisfied
* position in value chain changes
* move from product to service or vice versa
* merger with another organization
* has to be customer-led
* good business case
* beware of targets (wrong targets lead to undesired behavior)

Influencing others
* getting results with authority
* you can't change other people
* you can change what you do, which may change how others react to you
* need to be politically savvy

Effective influence
* open
* honesty
* integrity
* loyalty
* rapport

* adult to adult communication and relationships
* maximal listening
* dovetailing needs outcomes

Strategies
* Logic
* Personal appeal
* Networking
* Bargaining
* Assertiveness
* Hierarchical appeal

Great presentation, and happy to see that my anecdotal experience has some amount of overlap with Ant's much more research-backed approach.

Labels: change management, stc2008, xml

6:51 AM Permalink | |

 
STC UK: Almost live, part one...Lessons on Introducing XML Publishing
posted by Sarah
[updated to correct number of employees]

I attended STC UK's Trends in Technical Communication this weekend. For once, I actually got to be a regular participant in the sessions. And I got to vote on chapter-related matters (as I joined it this year).

Shannon Milsom of Cambridge Silicon Radio delivered an excellent overview of their XML implementation and lessons learned.

When she joined the company eight years ago, she was employee number 69; CSR now employees 4,000 people and 1,000 in the UK1,000 people. They create chips for Bluetooth (market leader), wireless, GPS, and other radio technologies. Most of their customer base is in Asia.

Development is in the UK and UK; "fabless" manufacturing in East Asia. Sales everywhere.

Their original workflow used Word and had all the usual problems you might expect. Styles were corrupt and style guides were not followed. As the company grew, the problems became worse. Single sourcing was needed for shared content; the copy and paste approach led to a risk of missing changes. Content from SMEs needed heavy editing and fixes of bad Word usage -- they created their own individual styles and made a huge mess -- and that assumes that they actually used the official template.

They had a wide range of content, and they classified it by product status (which is interesting and I don't think I've ever seen before):

• Advance information
• Pre-production information
• Production information

Side note: A slide with the various contributors and roles includes an excellent graphic of the software guy as a hippie California dude with a tie-dyed shirt. Sales and marketing on the beach under the umbrella with a laptop.

Their goal was to have:

• Content re-use
• Cost-effective translation
• Version control
• Reviewing

In addition to The Usual, their reasons for moving to XML include the ability to substitute "common text," such as the product name and number, document type, and document status.

Modular authoring results in a workflow where they build documents from common blocks. If a block has been "released" (I think this means reviewed and approved), it can be used as needed.

Benefits they see from XML:

• Shorter production cycle
• Do more with small staff
• Increase throughput
• Marketing can build documents from signed-off information modules
• Use data direct from source (SMEs)
• Ease checking and sign-off
• Has taken human confrontation out of review cycles...approved modules are set in stone and it's easier to reject change requests on those modules
• educe composition and review time
• Version control
• Automated system reduces errors -- nothing falls through the cracks
• Cost-effective language translation...partial localization to save money over localizing everything
  

They considered building their own CMS but eventually bought. After a few trials and a false start with a product that didn't work, they ended up with Ovidius TCToolbox, which they are very happy with.

Lessons learned

• Understanding XML technologies is much more interesting than working in Word and not that difficult
• Choosing freeware, shareware, purchase, or DIY is a big decision
  
• Be sure to choose a mature, well-supported system
• May have to re-invent corporate style to accommodate XML publishing [or face huge costs in replicating existing style]
• Glossary is generated based on terms actually used in the document and pulls content from a 700-entry master glossary
• Solution is still changing
• Beware of solutions that are not fully supported
• Evaluate service vendors by looking at real-world implementations that they have done.
  

Issues to consider

• New way of working
• Will your tech comm group work this way?
• Can you recruit people who can work this way?
• Keeping a single voice in a single-sourced system
• Learning how to write in XML for content re-use
• Writing for one voice helps translation
• Editor/GUI is important to success
• Getting content directly from SMEs
• Budget

Focus on:

• Good training/support and actual solution
• Involve authors in the setup of data and design
• Designate information architect for CMS-based solution
• Identify the skills gap
• Test drive the software
• Focus on your needs and examine the existing process
• Do you need a CMS? What about a staged approach?
• Can you create output, symbols, graphics, equations, xrefs?
• Be prepared to make diversions from original corporate style
• Hidden/rising costs?
• Allow time

Involve...

• Everyone on the journey
• Team for evaluation
• IT system support
• Info architect
• Contributors/reviewers
• Tech communicators

Today's language lesson: "trial" as a verb, as in "We trialled XYZ, but didn't like it."

Labels: change management, conferences, stc2008

4:52 PM Permalink | |

 
STC 2008: Wrap-up
posted by Sarah

My next round of conferences will be in the UK. I'm leading an XSL workshop for STC UK on June 22 and giving a presentation on June 21 as part of the Trends in Technical Communication event. Then, it's onward to X-Pubs, where I'll be discussing the implications of Web 2.0 on technical communication.

As far as I know, after that I'm done with the conference circuit until the fall. However, senior technical consultant Simon Bate will be attending the Gilbane conference in San Francisco and participating on a DITA panel. Please contact us if you'd like to set up a meeting at the conference.

Labels: change management, conferences, stc2008, xml

1:44 PM Permalink | |

 
WritersUA: DITA pilot techniques
posted by Sarah
Mark Wallis of IBM ISS on how to run a successful DITA pilot. Some great information in this presentation on how to reduce risks.

He recommends selecting your pilot project based on the following items:

• Right timeframe -- don't choose the project that has an imminent release
• Choose a manageable documentation set size
• Reduce risk by avoiding the strongest (or most critical) product
• Identify a product with a known need to improve the user experience

They had one person out of a group of twelve, a "senior in name only" writer, leave because of this transition.

The ideal team for a pilot will need cross-functional and complementary skills:

• Project management skills
• Tools and technology strengths
• Product knowledge and understanding
• Architecture and design skills
• Editor for standards and styles

Some advice on planning your content. (And it's worth noting here that these apply to good writing and topic-oriented content rather than to DITA tools.)

• No autopilot writing
• Don't just migrate existing content; you'll get trapped in old paradigms (this assumes that existing content does not fit the DITA topic paradigm)
• Perform use case analysis and task analysis
• Determine the critical scenarios to document
• Focus on tasks; backfill supporting information as needed

Some interesting discussion of "task support clusters," which include conceptual overviews, related tasks, deep concept, and reference information. (Michael Hughes did a presentation on this earlier today, which I unfortunately was not able to attend.)

They set up a DITA War Room in a small conference room and met at least daily (1.5 to 2 hours per day. Yikes). They set weekly goals and used small tasks to build momentum.

There was also heavy use of an internal wiki to put up initial "straw man" design, then revise, comment, and discuss.

Layering deliverables
Implementation deliverables were split out into smaller tasks, such as:

• Creating topic files, links, and navigation
• Testing links from code and navigation
• Creating task and reference topics
• Validating help against the user interface
• Creating concept topics for principles, guidelines, and best practices ("deep concept")
• Validating content in the expert community
  

For the third time, he points out that they are no longer documenting how to use a check box, so I guess I'll mention it.

Choosing the DITA toolset

Task Modeler (free) for building and managing ditamaps, defining relationships between topics, and creating skeleton topics (stub files).

DITA-compliant editor to edit your topics.

Compiler (part of open source toolkit). Compiler? What are they compiling? HTML Help? Oh. He just referred to Ant as a compiler. Ohhhhhkay.

Proof of concept

They picked a subset of the pilot to do the proof of concept.

The presenter's boss is quoted as saying, "There's no such thing as bad weather, only insufficient clothing." I'm guessing that she's never been to Minnesota in winter.

The objectives for the proof of concept:

• Learn and evaluate tools
• Address technical obstacles
• Specify end-to-end requirements

They learned that deliverable formats matter because they must deliver several different formats.

Managing costs

Purchase toolsets only for pilot team.

After completing proof of concept (successfully!), invest in tools for the remaining writers.

Wiki

They used their wiki to capture conventions and guidelines.

Improving acceptance

They paid attention to the change management issues. He doesn't mention it here, but I would assume that the combination of an acquisition by IBM plus the requirement to change the authoring environment could have caused significant angst. Their approach included presentations, wiki content, email discussions, and online training.

At the point of transition, DITA boot camp was offered.

They used collaborative walkthroughs, or reviews, to help standardize their content development. Interesting. This sounds as though it could be a) threatening and b) an unbelievable time sink. But just maybe it might also c) help improve the content.

Other lessons learned

Think more, write less. (Don't document the obvious, don't document common user interface convention, write only if you're really adding value.)

Don't squander your ignorance. (If something makes you stumble in the interface, that will probably also cause problems for your users, so capture it.)

The more structured your content, the easier the transition to DITA.

Documenting the obvious teaches readers to ignore your text, so don't document the obvious.

The handouts are available here: http://www.writersua.com/ohc/suppmatl/

Labels: change management, dita, writersua2008, xml

5:29 PM Permalink | |

 
Culture clash
posted by Sarah
[Disclosure: I have several friends who work at IBM and Scriptorium is an IBM vendor.]

Both IBM and Tata Consultancy Services have recently laid off employees in India.

I think it's fair to say that many Indians are shocked by this development. At least one person says that the interviewers should be let go because they did a bad job of evaluating people. Others are wringing their hands over ruined careers because the layoff means a black mark on your resume.

And, with much sympathy, I say to them, "Welcome to our world." Layoffs are a fact of life in the U.S. I started Scriptorium after a layoff and I think that most people in high-tech have a layoff (or two or three) in their job history.

For U.S. workers in the generation that is now retired, getting laid off was in fact shameful. I remember one colleague back in 1996 who told his father about his layoff. His father, who worked his entire career at one large corporation, said to him, "What did you do wrong?" (thanks, Dad) But today, layoffs happen. Corporations merge, or don't meet their revenue targets, or overextend themselves, and then they lay people off.

The multinationals, like IBM, have brought this mentality to India. But Indian expectations appear to be that, once hired, you get to stay.

In BusinessWeek, we find a flattering story about Tata's approach to acquisitions:

Tata's unique shareholder structure makes it easier for the group to tread lightly. Since its founding in 1868, Tata has been controlled by charitable trusts. Today, they own 66% of parent Tata Sons' shares and aren't as focused on short-term gains as most investors. The trusts, says R.K. Krishna Kumar, a director with Tata Sons, have long insulated employees "from the greed that is sweeping the corporate world." As the company gets more deeply enmeshed in the global economy, that gentility will be put to the test. Says Harvard Business School professor Tarun Khanna: "There's a different kind of rough-and-tumble to competitive pressures outside of India."

And it looks as though this is already happening.

Employee costs in India to U.S. costs are rising quickly because of the exchange rate (weak dollar/strong rupee) and salary increases. As a result, the standards for Indian employees must rise as well. (If you cost more, you had better add more value.)

For U.S. employees, the Indian layoffs may be an oddly hopeful sign. Rick Smith says this at wral.com in an opinion post:

The evidence right now is anecdotal, but the IBM fresher story could mark a tipping point in offshoring/onshoring. Stay tuned.

At least life in this industry is never boring.

Various reactions:
pluggd.in
digitalbhoomi.in
Yahoo News India
humsurfer.com

Labels: change management, globalization

1:59 PM Permalink | |

 
The Age of ... Expertise?
posted by Sarah
Over on O'Reilly's Radar blog, Andy Oram has a fascinating article about the demise (!) of the Information Age and what will be next:

[T]he Information Age was surprisingly short. In an age of Wikipedia, powerful search engines, and forums loaded with insights from volunteers, information is truly becoming free (economically), and thus worth even less than agriculture or manufacturing. So what has replaced information as the source of value?

The answer is expertise. Because most activities offering a good return on investment require some rule-breaking--some challenge to assumptions, some paradigm shift--everyone looks for experts who can manipulate current practice nimbly and see beyond current practice. We are all seeking guides and mentors.

What comes after the information age? (be sure to read the comments, too)

It's an interesting idea, but I don't think we're getting away from the Information Age into the Expertise Age. After all, expertise is just a specialized (useful!) form of information.

In the comments, Tim O'Reilly points out that the real change is in how information is gathered and distributed with "the rise of new forms of computer mediated aggregators and new forms of collective curation and communication."

I believe that we are still firmly in the Information Age because information has not yet become a commodity product. There is, however, clearly a shift happening in how information is created and delivered. I think it's helpful to look at communication dimensions:

• Traditional technical writing is one-to-many. One person/team writes, many people consume it.
• Wikis are many-to-many. Many people write; many people use the information.
• Mailing lists are many-to-one. Many people respond to one persons' question.
• Technical support is one-to-one. One person calls; one person responds.
  

Technical support is the most expensive option; it's also often the most relevant. Technical writing is more efficient (because the answer to the question is provided just once), but also less personal and therefore less relevant.

Many technical writers are concerned about losing control over their content. For an example of the alarmist perspective, read Joanne Hackos's recent article on wikis. Then, be sure to read Anne Gentle's eponymous rebuttal on The Content Wrangler.

Keep in mind, though, that you can't stop people from creating wikis, mailing lists, third-party books, forums, or anything else. You cannot control what people say about your products, and it's possible that the "unauthorized" information will reach a bigger audience than the Official Documentation(tm). You can attempt to channel these energies into productive information, but our new information age is the Age of Uncontrolled Information.

Furthermore, the fact that people are turning to Google to find information says something deeply unflattering about product documentation, online help, and other user assistance. Why is a Google search more compelling than looking in the help?

Labels: change management, web 2.0

1:29 PM Permalink | |

 
Facebook
posted by Sarah
In the past couple of weeks, I read an excellent post from Dave Kellogg about Facebook, and then received an invitation to join from a fellow technical writer.

So I did.

Here are a few initial impressions:

• Facebook is much more compelling than LinkedIn (where I also have a profile). I find myself logging into Facebook to see what others are doing.
• I'm uncomfortable with a single profile for personal and professional use. At a minimum, I'd like the ability to label contacts as personal or professional and then control what information they see about me. Kellogg made a similar point in his posting.

I really wonder how Facebook might fit into a corporate communications strategy. Are there ways in which the Facebook platform might be used for technical support? Or for user forums? I can easily envision "We Hate Product X" groups, but I'm having a little trouble seeing how a more traditional user group might fit into Facebook.

Labels: change management, technical writing

10:09 AM Permalink | |

 
Inside our XML workshop...
posted by Sarah
Leanne Rollins of the Southwestern Ontario STC posted a summary of the workshop I did in March. It gives you an excellent flavor of what these workshops are Really Like.

I particularly enjoyed this bit:

The planning requirements and cost implementation alone were enough to scare the entire the room into reassessing their *actual* authoring and publishing needs.

I call that success.

Labels: change management, xml

9:28 AM Permalink | |

 
When you have a hammer...
posted by Sarah
...everything looks like a nail.

We all suffer from this syndrome to a certain extent. Once you develop familiarity with a particular tool or technology, you see possibilities everywhere.

Sean McGrath refers to this as the Just Use X Club. He is none too happy with the rising membership in Just Use X and proposes a counter-organization:

A second club needs to be formed called "When not to Just Use X" club. This group should devote itself to taking all values of X from the "just use X" club and listing off all the scenarios in which each X should not be used. They should also list off all of the things which will not automatically be true by virtue of the use of X. They should also list off all the areas where good old fashioned thought and design and hard work cannot be replaced by the simple gambit of using X.

This fall's Intercom will launch my new column, tentatively titled The XML Strategist. The first installment is devoted to scenarios in which XML is not appropriate.

It would appear that Mr. McGrath and I are kindred spirits.

Labels: change management, xml

8:42 AM Permalink | |

 
Understanding change resistance
posted by Sarah
Implementing new technology presents numerous challenges -- choosing new software, training staff on new technology and processes, setting up new workflows, and so on. For technical writers, the transition from traditional desktop publishing to XML-based workflows requires a significant shift in mindset. Instead of focusing on the appearance of the final deliverable (usually on paper), writers must now give up control over formatting, follow a set of structure rules, and assume that the end result will be formatted automatically.

You should not underestimate the difficulty that this transition presents. With that, I was disappointed to see the following at Accelerated Authoring:

If Pete decides to go for DITA, he’ll have to [...] persuade management, get a budget, train writers and figure out how to manage the transition. Not easy. And, if the transition is not smooth, Pete could be penalized.

On the other hand, Pete could get through the transition period to DITA and leverage the same team that he had yesterday to produce more documents, more focused documents, better documents. Is there risk in the transition? Of course, but that’s what life is about - adapt or disappear.

No.

"Pete" must first determine that the benefits of XML-based authoring outweigh the costs. Then, Pete needs to think about whether DITA is the right choice for his organization's content.

DITA is not right for everyone. XML is not right for everyone.

Keep in mind that the benefits of XML generally go to management and the difficulties (worse tools, less control, more constrained authoring) are imposed on authors.

If you're interested in more details, the slides from my Coping with the XML Paradigm Shift presentation are available here (PDF).

Labels: change management, xml

11:24 AM Permalink | |