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.
Re: Uniform processes and designs through an editorial guide
Subject:Re: Uniform processes and designs through an editorial guide From:"Riese, Claudia" <CRiese -at- tunstall -dot- de> To:"'techwr-l -at- lists -dot- techwr-l -dot- com'" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Thu, 18 Feb 2021 12:51:40 +0000
Hello Nina, hello Jim, hello everyone,
Thank you very much for your detailed comments.
Jim's experience on the subject of processes is very helpful.
>> One of the first things we did was to collect written processes ... from all facilities.
We then organized them in tables so that it was clear how each facility performed each process and what could be standardized.
This also highlighted those things which could not be standardized and allowed each local facility to have a clear understanding of how they would have to modify these "leftover" processes to integrate with the new corporate standards, as well as identify areas for future corporate standardization.<<
That sounds very logical, and that's exactly how I would start.
>>â, you will need to have high-level corporate AND local management support for this effort; it cannot be just the brain child of one person/group that happens to have some current visibility, else it is doomed. <<
I can also understand this tip very well and will take it to heart. It is good to consider this in advance.
Winston Churchill was probably right too:
>>"You can depend upon the Americans to do the right thing. But only after they have exhausted every other possibility." You can probably fill in the nationality to suit the situation...<<
Nina gives me confidence that I am on the right track with Confluence.
On this, perhaps a second question. A few people are currently building an intranet for the whole group of companies.
I have no experience with intranets. Is the intranet the right place for a technical writer's guide?
Nina points out the headings in the Technical Writerâs Guide.
Yes, I have already made the experience in other tools (also without any problems with the search function) that the informative value of the headings has to be good. Thanks for the tip.
>>It can be a good thing to not define *every little thing* in detail.<< Yes, thanks for that tip too. It also fits well with Jim's point about being very careful about guidelines for colleagues (in other locations).
It would be great if someone could give me an example table of contents that talks about processes, e.g. approval process, printing process, translation process.
I worked in a couple of places and depending on how people work, it can be a good thing to not define *every little thing* in detail.
Some people get in touch with the SMEs and manage via tickets.
Others use email.
There may be more methods in place at your company.
The less steps and effort needed for managing input as well as reviews, the better for all concerned in time of hassle, time-consuming rules to learn and to follow.
Start simple, extend where necessary. Would be my suggestion from experience.
Additionally, everything you document, has also be kept up-to-date over the years. So, sometimes, less could be more.
As regards an internal tool for documenting style guides and processes, I agree with previous posters:
*Confluence is fine for that!*
It's fast, stable, has all you need in terms of collaborating, without too much effort needed setting everything up.
We used it in 2 previous jobs for that and I liked it a lot - in that context.
You can assign pages, notify people of changes, comment, inline and at bottom of pages, and easily revert to previous editions of pages (history).
Another tipp: Confluence search is known to be weak, even Atlassian, the vendor admits it and suggests that you use plugins for improving it. (I don't like using many plugins with Confluence, the more you use, the more effort it needs maintaining.) Your project sounds very ambitious in terms of page count and so - make sure *page titles* are clear, 'speaking', unique, and contain the necessary terms for searching/finding them. Otherwise they quickly will get 'lost' because of the weak search...
Good luck!
Nina
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | https://techwhirl.com
