Making The Mental Shift to Topic-Based AuthoringPresentation Transcript
Making the Mental Shift to
Topic-based Authoring and
This is really a presentation about
Change is inevitable…
Managing change is not
If you don’t manage change…
It will manage you
Who are you?
• The person responsible for planning and carrying out
a TBSA* implementation
*Topic-based, structured authoring. I will probably slip and say
“DITA” but that’s not the only TBSA framework.
What have you already done?
• Exhaustively researched TBSA
• Developed a solid business case
• Sold it to the higher-ups
• Gotten buy-in at all levels above you
And now, the rollout…
The rollout sets the tone for the whole project
Have a plan
• Before you present TBSA to the team, cover all your
Anticipate every question and opposition
Be able to communicate exactly what will happen, when,
and who will be responsible:
• Tool selection (XML editor, CMS, etc.)*
• Information architecture
• Output styling******
• Legacy content conversion
• Collaboration among authors*
* These will be HUGE areas of discussion!
• The learning curve will be steep
• There will be extra work in the short term
Learning principles of TBSA
Maybe duplicate content maintenance for a while
• Be honest about what will change
Not just a move from one tool to another
• Completely different approach to writing
No control over formatting and outputs
No more Lone Rangers…writers must collaborate and follow
same styles and guidelines
Be honest (2)
• Be very specific about the rewards
Articulate the team’s pain points & note the solution
• Errors & inconsistencies in documentation
• Frantic scrambling near deadlines
• Duplicate content in different formats
• Inconsistent toolsets and processes
Articulate the company’s pain points
• Customer complaints
• Rising support costs
• Ability to deliver innovative solutions limited by ability to
provider user assistance
Base rewards discussion on the research you did to justify
the move to TBSA in the first place.
If you can’t be specific about the rewards, you’re not ready
to implement TBSA.
Don’t get sidetracked by naysayers
• Address their general concerns
• But don’t get led down the garden path
“So we can’t have tables with the 3rd column of every 5th
row shaded and a dotted line after rows that start with the
letter G? Our clients really expect that. They’ll complain if
we can’t do it.”
• Stress that all conventions, especially styling
conventions, are up for reevaluation
Everything is on the table.
They must be prepared to offer solid justification for their
“We’ve always done it that way” is not solid justification.
Enthusiasm is not necessarily contagious
• Even though you explain the problems and how
TBSA will solve those problems, many people will
still be unconvinced
Don’t let the resistance take you by surprise
• Is this the best solution?
• What other solutions can we look at?
Don’t get exasperated
• Lots of uncertainty and doubt associated with change
• Can I learn to do this?
• Increased efficiency = staff reduction?
Talk to individuals
• Completely open discussion
• Get to the root of resistance
It might not be about the current situation at all
• Previous negative experience
• Ongoing life events
• Set individual expectations and measurements
How will their work and responsibilities change?
What is expected of them during and after the change?
How they will be measured?
What will success or failure mean for them and the team?
Talk to individuals (2)
• Everybody comes at change from a different
Dejuan is a writer who works on a very small, simple product with
only two releases a year and only one type of documentation.
Sally is a writer who works on a very large, complex product with
3 other writers. There are 4 major releases, and dozens of
patches/hotfixes a year. There are online help, user guides, and
quick reference guides, each with several variations, that have to
be produced for each release.
Manish is an editor who reviews the documentation, usually in PDF
format, for typographical accuracy and adherence to style
Nadia is an SME who contributes content, usually in Word.
• Frame discussions in each person’s individual
No one-size-fits-all approach
• Identify key people and let them help you
Every team has natural leaders outside management …
people other writers naturally look up to. Involve them at
the earliest practical stage and get them to help you plan.
Have them lead teams as mentors or representatives so
that decisions (where practical) are made collaboratively
from within the ranks instead of coming down from “on
Keep an open mind and stay flexible
• Expect the unexpected
Things will come up that you didn’t and couldn’t have
• Personnel changes
• Company reorgs/change of focus
• Resistance in unexpected areas
• Unexpected technical challenges
• If the plan needs to change, change it
Be clear with the team about why.
If it was something you overlooked, don’t try to fake people
out – (that honesty thing again).
To sum up
• Make sure your implementation plan is complete
Not necessarily every detail but sufficient to reassure the
team that the pieces are in place and all important issues
have been considered and accounted for
• Be honest with the team
State the challenges up front. Don't whitewash. Be clear
about the extent of the effort and its effects on everyone.
Be honest about the effects on day-to-day work both in the
short and long term.
• Don’t get sidetracked
Resist the urge to reassure writers on every minute detail.
This can turn into a sparring contest.
• Don't be surprised by resistance
Just explaining the problem and showing the solution is not
enough to sell the plan.
To sum up (2)
• Have individual discussions
Frame the change in the context of each writer's
responsibilities, experience level, concerns, questions.
• Create ownership
Spread responsibility for certain decisions and processes
among key players on the team, not just management.
• Keep an open mind and stay flexible
Be prepared to change the plan to fit changing
Available in the
and from Amazon