Moving into Someone Else’s Single Sourcing House: Are We (Best) Practicing What We Preached?
In 2000, a small group of writers worked together in an engineering department of a large, global organization. This organization was made up of hundreds of departments and branch offices. It prided itself on the way that all areas of the company worked together as one team, and it endeavored to create documentation—both technical and marketing—that was usable, consistent, and efficiently created and maintained.
In 2000, this small group of enthusiastic writers learned the term “single sourcing.” Led by a supervisor who was eager to embrace reusability and true content management, this group asked for and was granted the money, time, and resources to become a pilot team—the beginning of company-wide single sourcing.
As we moved from a single sourcing pilot project team to everyday users of our new content management and document creation and maintenance tools, we attempted to learn, document, and follow a set of best practice guidelines: advice, rules, and tips we learned from experts in the field, other companies using single sourcing, and our own experience.
Our attempts at content management, template use, and cost-cutting were successful—we moved fully from Microsoft Word to Epic Editor and Documentum. We even brought another department on board—fully trained and partially converted. Our North American headquarters—where all of the writing is done for the entire continent—had begun to plan a company-wide single sourcing wave. Following the lead of our pilot project, and using a lot of the experiences and knowledge our department had acquired and documented, the technical communication community had started to move in our direction. Document analysis was completed, an outside consultant was hired, management was on board, budgets were approved. And then the economy began to crash, and the expansion was placed on indefinite hold.
As our projects became more global, our documentation expanded across continents. We were no longer only writing for North America—we were working with teams and writers all over Europe. And although our single sourcing solution worked in the Integration department and could have worked throughout headquarters, we as a company were unable to justify the expense, time, and resources required to complete the company-wide expansion that the economic down-turn had interrupted.
Still, this was the time to make a change toward single sourcing. A decision was made by upper management: the documentation teams throughout the company—North American headquarters included—would begin to learn and use a web-based system called Schema Text 4 (ST4). The European groups were already using it, as were the local teams working on global projects. It was up and running, and it would make our documentation consistent throughout an even larger set of departments and teams.
After being so fully absorbed in the first single sourcing pilot team on campus and after being so involved in the decision-making, the testing, the changes, and the training, it was a huge change for the Integration department to be on the other side of such an all-encompassing documentation decision—the tools had already been chosen, the power-users had already been trained, the high-level organization of information had already been done. Yet the challenge remained for the Integration group to get on board, get trained, and get documents converted.
While other groups are comfortable with ST4 and have made the move completely, the Integration department is currently still in the conversion phase of our use of ST4 as a documentation tool. We have been trained, and we have used the tool for some, but not all of our documents. However, we haven’t “flipped the switch” (a term we used back in what we now think of as the original single sourcing days) over to full, everyday use of ST4, and because resources are stretched thin, it may be some time before we can move completely from Epic Editor and Documentum to ST4 and its modular organization.
This, however, proves to be a good opportunity for us to take a step back and see how well we’ve followed our own advice. This time around, even with many of the decisions made for us and with much of the pilot phase done before we even knew about the new system, can we stick to the best practices that we deemed necessary when we in Integration were calling more of the shots?
The mistake we made as a pilot team was becoming trained on the new tools before we were ready to use the tools every day. We went off-site for an overview, but weren’t able to narrow our needs down quite yet. Because we had on-site experts, however, we were able to get help easily, and we had the ability to schedule on-site training that was tailored to our specific needs.
With ST4, the training came to us and at the right time for the TechComm team as a whole. The Integration department, unfortunately, wasn’t ready to embrace ST4 fully, due to project deadlines and resource issues, but the writers were trained nonetheless. Because ramp-up time has been much longer for Integration writers, the local power-users have been endlessly helpful as we move more slowly toward “flipping the switch.”
With Documentum and Epic, our most difficult process change was archiving the native files for each document. Because native files now lived in Documentum rather than on a server in the corporate network, we had to come up with ways to make this work, and we did. Now that we’re moving back to the possibility of Microsoft Word as one output format, we can store Word files on the corporate network while keeping native “nodes” of information on the ST4 web-server in Europe. This means no process change.
We will, however, be able to shorten our review times once we fully move to ST4—our technical editor will only need to review “nodes” that have changed, rather than entire documents or entire templates. This is a process change, of course, but it is a change for the better, for all involved. We’ve also had to determine which illustration formats work best with the new output, though this decision occurred with a simple series of tests done with the help of our illustration team and then a notification to the user group about which formats to request from the artists.
Along with the many new things we have learned (and will continue to learn) with regards to simply using a new tool, a new organizational structure, and a new review process, we will also be turning to new people when we need help. In the past, we worked in a bit of a vacuum. Our documents are a bit different from those written by other groups, and our troubleshooting resources were part of our group and know our products and documents well.
This time around, though, we will be reaching outside of Integration to find help, and while the people we will be reaching out to are experienced writers, good teachers, and people we know well enough to feel comfortable asking even the simplest of questions, it’s still a different dynamic than we’re used to. It’s also made a bit more difficult because our ST4 experts don’t know our documentation as well as our Epic experts did, and this requires us to do a bit of teaching before we can come together to an answer that works for the new system as well as for our Integration needs.
User licenses also had to be addressed—because of cost-cutting endeavors and because licenses are expensive, we had to come up with a way for all users to have access to the server when they needed it. All writers have access to a “thin” client license, which allows them to access the server, create documentation, and make changes to existing files. A “rich” client, however, is necessary for producing the end-product—something a writer might need to do several times a day, or only a few times a week, depending on the project. Working with overseas teams turned out to be an advantage in this regard: because of the time difference, North American and European users could use the same licenses at different times of day. All writers were also instructed to use the “rich” client only when it was necessary and to use the “thin” client when doing the bulk of the writing. This solution has worked very well.
Which “Stuff” Will We (Must We) Use?
The decision about which features are necessary for our needs is a big one. There are always features that are required, those which are optional (useful but possibly too expensive or time-consuming), and those that turn out not to be worth it. With our original move to single sourcing, we made a lot of decisions about features—some of which we stuck with and some of which we abandoned as necessary.
With ST4, we’ve been given a bunch of stuff—a full set of features—and we’ve been told to use what we need. It’s somewhat freeing to be exempt from the heavy decision-making, but it also requires us to fit our Integration document needs into the mold that’s been provided.
This time around, however, we’ve designed a way for ongoing discussion about features—the good and the bad—to be facilitated. Every month we have an “ST4 User Group” meeting, during which users and power users present information about features that have been implemented or improved, as well as tips and tricks for creating the documentation we need using the features we have. This process allows us to make decisions about possible changes in process or style in a way that includes all product groups. Because all decisions and meeting minutes are archived on a Sharepoint site, we’ve also made sure we have continued to document decisions (who, what, when, and why) so they don’t have to be re-addressed at a later time, unless absolutely necessary.
The single sourcing mind-set can be difficult to grasp. The Integration writers started out with a lot of documentation that was “cookie cutter” already, meaning that there was a lot of opportunity for reuse—the perfect documentation set for content management. It was easy to grasp the concept of single sourcing, and because we worked with templates, we didn’t suffer much of a learning curve when it came to the abstract idea—or the practical changes.
ST4, however, uses modules or “nodes,” and this is something that has caused a bit of a roadblock in our thinking. We still have a lot of reusable content, but learning how to think in terms of sections, chapters, or smaller pieces of information can be difficult and is something we continue to struggle with.
Our document review cycle is a process in need of updating as well, and with the new tool, the new appearance of documents, and the new mindset, this is the time to make changes in review policy, as well. Currently, our reviewers use Adobe Acrobat to read and comment on .pdfs. With ST4, they will make the switch with us, reviewing Word files again, as they used to do before single sourcing. While this makes it easier to review and make changes to documents, it is nevertheless a process change that must be documented and communicated to everyone involved.
Some changes that have to be made from scratch aren’t as easily accepted by the writing teams. Tables, for example, were a bit troublesome when we wrote in Word, and the change to Epic was a dream-come-true for writers whose products required a lot of tables (and long ones at that) in the documentation. Now, the switch to ST4 has taken away the simple importing of table data from our Integration tools into the Epic documentation, throwing a wrench into our conversion. It’s a problem that has a solution, though, and with the help of the ST4 User Group meetings, we’ll find it.
Change is never easy, but it is easier every time it comes. A huge change in the way we do our jobs every day is certainly easier to understand, accept, and embrace when we are part of that change. A group of enthusiastic writers, eager to tackle a single sourcing pilot project, knowing that their documentation will be much better at the end of it, and knowing that their tasks will be much easier for it, certainly has a much smoother road toward single sourcing, in spite of the roadblocks and obstacles in their way. Such change is much more difficult for a group of writers charged with the task of learning, using, and converting to a new documentation system that was decided in another country, with no input from many of the writers who would be using it, even when many of the roadblocks have already been cleared.
The best practices, however—appropriately-timed training, new processes which include all departments involved, enough resources (both human and technological), mindful decisions about necessary features, a positive attitude about the things which must be redesigned or recreated from scratch, and many others—remain the same.
About the Author
Siemens Building Technologies, Inc.
Heidi Sandler has been a Technical Writer for the past eleven years, creating engineering and marketing documents for the Integrated Solutions department at Siemens Building Technologies in Buffalo Grove, Illinois. Heidi has co-edited a family memoir called Wanderlust, taught college English, and worked as a copy editor in the academic and non-profit sectors. Heidi began working with XML and Single Sourcing in the fall of 2000 and has used it every day since. Heidi earned a Bachelor of Arts in German Language and Literature, and a Master of Arts in Teaching English to Speakers of Other Languages (TESOL) from Northern Illinois University in DeKalb, Illinois. She is a youth ministry volunteer as well as an accomplished member of Toastmasters International, where she has achieved the title of Distinguished Toastmaster. Heidi lives in the Chicago area with her two teenaged daughters.