Shoap Technical Services
Wikipedia defines single sourcing as “a content management method which allows the same source content to be used across different forms of media and more than one time. The labor-intensive and expensive work of editing need only be carried out once, on only one document. This reduces the potential for error, as corrections are only made one time in the source document.” A decent, I think, explanation of what this mysterious approach to documentation is all about.
For additional information regarding Waterfall/Agile development and how it impacts technical writing, please refer to previous blog posts written by Eric Sedor and Shaun Kelly.
Moving a product out the door to capitalize on market demand is a necessity – it’s simple economics! Consumers demand constant product improvements. This “out with the old, in with the new” mentality has led many successful companies to switch from Waterfall development to Agile. What does this mean exactly? For the uninitiated, use this simple analogy. Waterfall development can be compared to a marathon. All software features are built in one long process and then errors are fixed. Agile development is more like a series of sprints. Software is released in a series of small iterations. Each release includes a few added features, and errors are corrected along the way rather than at the end. As you can imagine, the switch to Agile development completely shatters the status quo and roles of people associated with the development teams. This led us to wonder: Specifically, how does the switch to Agile impact the role of technical writers?
Technical writers are a rare breed. To be successful in this profession, you have to be patient, know how to communicate, and, last but not least, understand technical concepts. These tough demands have been the inspiration for this article, the third and final, in what we like to call our technical writing “rant topics.” See the first two in the triptych, “What’s Wrong with the Passive Voice” and “Why is Consistency Important.”
So, what makes technical writing such a challenge?
It’s not like technical writing isn’t already incredibly boring, so why does it have to be consistent? Such is the typical complaint about what we at Shoap do to earn a living. So how important is consistency?
While we sometimes fantasize about people grabbing one of our documents and cozying up to the fire to spend some quiet hours learning how to use a new piece of hardware or software, the reality is starkly different. As they used to say about Ivory soap, 99.44% of the time the only reason people crack a user guide or click on online help is because they’re stuck: they can’t figure out how to do something that they need to do – and need to do immediately.
Consistency means you can find information quickly and understand that information when you encounter problems. Let’s see how.
In an earlier article (http://www.shoap.com/rfp-responses-go-technical), we discussed the importance of responding to RFPs with correct, easy to read and understand responses. Several of our readers wondered if there were any tools that could help them address the arduous task of responding to RFPs. This article is for them.
Unquestionably, there are more onerous tasks than responding to a big, fat request for proposal (RFP). Unfortunately, I just can’t think of anything. People who have to do this for a living spend countless (and thankless) hours, ensuring the response is correct and flawless. These responses can go for hundreds of pages, require inputs from various and sundry departments within the organization, and are under tremendous time constraints. It’s stressful just thinking about it. Many companies, however, are facing this nightmare head-on by investing in software that automates the process. Leave the copy/paste method behind.
When you are a company dealing with your customers’ most valuable personal information, you need them to trust you. One easy way to do this is to have your documentation flawless (or close to it). Also, performing a test run with a small group of people before releasing it to the masses is a good idea. The group of people should be 3rd party users who can find the mistakes you can’t find (since you’ve read and reread the form 40 times and never want to see it again).
At Shoap Technical Services, we take pride in our ability to offer our clients fixed-priced bids for technical documentation and training. We feel that this is an advantage to our clients because everyone likes to know how much a project is going to cost before they start. And we feel confidant that we can correctly estimate a project because 1) we’ve done so many technical writing and training projects over the past 25 years and 2) we’ve learned how to break down a project into small enough parts so we can assign numbers (time) to each part to determine a total cost. What we like to say is, “If we can put our arms around the project, we can successfully bid it.” While we have, at times, missed our estimates and had to finish a project at a loss, most of the time we’re pretty accurate. That makes our clients happy because they know from the outset what they’re going to have to pay and it allows us to make enough money to stay in business.