TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:RE: Building a documentation knowledgebase From:"Len Kirby" <Len -dot- Kirby -at- pwrm -dot- com> To:<chevotilburg -at- postmaster -dot- co -dot- uk>, "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 16 Feb 2004 16:31:25 -0800
I was charged with developing a knowledgebase system to deflect ever
rising routine support incidents. We are working using it to store
documentation as well. So far, success.
The other posts were speaking to management and executive buy-in. This
is your biggest and most important step before getting your kb off and
flying. No management buy-in, no way its going to get the resourcing it
will need. Managers are pragmatists, and will want a measureable goal
and measureable results. Find a manager who is suffering because there
is no kb. Work with them to figure our your goals. Present it. Become
the hero.
Change management is another piece of the puzzle. In our company, we
have a multitude of communications media: Sales use the phone, Support
uses our CRM, Hardware R&D use the coffee station, Software R&D use
whatever is techno-hip that week. I surmised that it would be impossible
to get everyone using one system. I asked each manager to supply 1
author (at a reasonable 5% of their time) to be the 'champion' and
'author' for their teams. These people act as the conduit, ensuring
proper language and categorization of issues and knowledge assets.
Workflow came naturally quite easy after that. The authors and myself
got together to brainstorm how article generation would play out. Since
they had a vested interest in getting quality inforamation fed to them
prior to feeding the kb, it seemed logical to include them. Next, fear
was my motivational word for management: 'we need reviewers for this
information prior to placing it on the website'. Many a manager have
committed to resourcing for the technical and market review process.
It took all three of these stages before I really understood the
technology requirements. We bought a knowledgebase tool that mapped
workflow, has audit trails, html editing, indexing, snappy portal
appearance, bulk document import, etc etc.
Because I got all the buy-in up front, I have no woes with generating
content, no pains getting the content reviewed, and no budget
frustrations.
