Coping in the Age of Budget Cuts and Staff Cuts
Most documentation managers are struggling to maintain quality while doing with less. And whether we’re creating Web sites or documenting software, hardware, or other products, we’re being pressured into doing it all on “internet time” (very rapid develop and launch cycles). The old question was, “Do you want it fast, cheap, or high quality? Pick two.” Today we’re being told “fast and cheap,” but we don’t want to give up “high quality.” What can we do? How can we cope in this new economy of budget cuts, staff cuts, cuts in other resources?
You Still Need a Well-Thought-Out and Structured Process
Whatever you do to develop product is your process. It may not be pretty. You may not even know what it is. Chaos is a process if that’s how work is being accomplished. But chaos is not a well-thought-out or structured process.
If your staff are not following a structured process with stages and milestones, they are probably not working efficiently and effectively. If you aren’t managing from the principles in JoAnn’s book, Managing Your Documentation Projects (Wiley1994), you are probably not using your resources efficiently and effectively. As resources get cut, having good processes in place becomes even more important.
Try the SRMS-Smart and Rapid Model for Success
The basic element of a good process is to have a model for how you get from initial request to final publication. Figure 1 shows a model that cuts the process to its essentials.
Figure 1. The SRMS, a Straightforward, Simplified Model of the Documentation Process
I call this the SRMS, the Smart and Rapid Model for Success. Along with the pared-to-essentials picture, we have to talk about how to accomplish each stage of the model smartly and rapidly.
All the stages in the SRMS are necessary.
You can shorten each stage-some more than others. You can get smart about the stages. Skipping a stage, however, jeopardizes all the ones that come after it. Starting in the middle (at drafting, for example) is a time-waster. You’ll find you have to go back and do the earlier stages anyway-and then redo the ones you’ve done.
The process is not as linear as it looks.
Of course, the process is not nearly as linear as the model seems to depict. It’s interwoven and iterative. But if you are developing any type of product, the process does start with planning and end with publishing (or launching a Web site); and it moves through all these stages.
To get “smart and rapid,” you need to have strategies and tactics (plans and techniques) for each stage. Let’s look at some.
When I teach workshops on clear writing, I stress planning even for emails. Planning may take 10 seconds for an email. It may take hours (rather than the days or months we sometimes used to devote to it) for a manual or help system or Web site. But it’s still necessary to answer the three basic questions about any product:
- Purposes: Why are you developing this manual or online help system or Web site or whatever it is? What business purposes are you supporting?
- Users: Who are the audiences? What should you keep in mind about them?
- Scenarios: How, when, and why will different people in the audiences come to whatever you are developing?
The answers to these questions lead to the analysis that allows you to make smart decisions about resources. When you have answered the questions about business purposes, users, and their scenarios, you can make smart decisions by asking this second set of questions:
- What are the priorities among projects?
- What is the right documentation for the need?
- How short can it be?
- Should you be putting your energy elsewhere?
What are the priorities among projects?
With short resources, you may have to set priorities. You may have to decide that projects are not all equally deserving of the same level of time and effort. Answers to the three main planning questions (including understanding the business purposes) help you set priorities.
What is the right documentation for the need? How short can it be?
Analyzing the situation may help you come up with ways to save time and money.
As an example, read Al Blackwell’s story from the STC project on value added (Technical Communication 1995). In the case study that Blackwell reports, the product team had assumed that they would need a 100-page manual. They planned to document every feature. When Blackwell’s information developers joined the team, they went back to stage one and asked the planning questions. When they considered users and scenarios and asked what tasks users would actually need the paper documentation for, they realized that the product needed only a 20-page manual, not a 100-page one. Every feature didn’t need to be documented; users just needed the print manual to install the product and have some troubleshooting help. That decision saved $18,900 just in printing costs. Surveys of users indicated that the 20-page manual satisfied the need.
Are you sometimes writing more than necessary because you’ve skimped on planning and analysis?
Should you be putting your energy elsewhere?
Sometimes a document isn’t what you need to focus on. Your goal should not be writing and producing X pages of documentation. Shouldn’t it be helping to prepare a product that communicates so well users can learn and use the product (application, Web site, hardware) quickly and easily? Are you writing manuals or even online help when getting involved in the product much earlier would be better? Would influencing the interface be a smarter and faster way to achieve the real goal? Would you add the most value by doing a user and task analysis (Hackos and Redish 1998), by mentoring and editing the work of others, by being user advocates and evaluators (Dumas and Redish 1999)?
Even in my earliest models of the document design process, I included an option at the end of planning to decide that the best way to achieve the business goals for the users and their scenarios was a “non-document” solution. We are communicators, not just writers. Maybe helping to imbed communication in the interface is a better way to use your scarce resources.
To be successful, you must implement the SRMS as a user-centered design process.
User-centered design is a philosophy and an attitude as well as a set of techniques. When we serve as user advocates to the entire project team, we are being user-centered. When we bring information about users and their tasks to our own work and to the rest of the project team, we are being user-centered. When we find “guerilla” ways to get users to try out drafts, especially of new designs, new styles, new templates, we are being user-centered.
User-centered design does not have to add time or effort to your process. You can scale the techniques to your needs (Redish and Wixon 2003). It is because you are user-centered that you sometimes end the planning stage by realizing that the best use of your scarce resources is not separate documentation but helping to build information into the system.
In the SRMS, you still must get sign-off on your planning decisions.
In the smart and rapid model, the planning stage must still end in an Information Plan. (See JoAnn’s Managing Your Documentation Projects.) You still want everyone involved to sign off on your understanding of the business goals, the audience definition, the tasks the audience is going to do, and what documents you are (and are not) going to create based on your analysis. If you don’t do this step, you may find reviewers objecting to your choice of content, style, or level of detail-all because the reviewers have a different picture of the audiences and their needs. In the smart and rapid model, the Information Plan becomes a very short document with clear headings and bulleted lists or very short paragraphs. Your reviewers don’t have resources either. They’re overloaded, too, and have no time to read. You have to help them work with you in smarter and more rapid ways.
Getting and Selecting Content
If you do continue with a documentation solution, the next step is deciding what content to include. In the smart and rapid model, you realize that spending the time upfront to decide on content saves time and effort. By taking the time to think about the content first, you don’t write more than necessary only to decide to leave it out later.
Getting the content may mean communicating with product managers, designers, developers, engineers, or other subject matter experts (SMEs). In the new global world of outsourced work, those folks may be geographically far away. But physical proximity isn’t the work model today. Today’s collaboration model is physical distance with instant communication. You may have to do it all by email.
If you were used to just going down the hall to get your questions answered, you may miss the old way. But you can’t mope and groan. You’ve got to make the new way work for you. (See Helen Sullivan’s article about attitude in Best Practices August 2003.)
Set up lines of communication as soon as you know about the project. Initiate email contact. Don’t give up. Communicators must communicate; we’re the ones who have always been the “glue” on projects-connecting users and SMEs, connecting disparate parts of the team.
It can be done. In the 1980s when I was directing the Document Design Center, we did a project for SONY Japan entirely by fax. Every evening, I faxed what we had done; every morning, I came in to find a stack of faxes back again. Today, we would be exchanging files as email attachments.
Here’s where the smart and rapid model begins to rely on designs and templates. Once you know what type of document you are developing (task-oriented manual, procedural online help, frequently-asked questions, catalogue-like e-commerce Web site, and so on), you should have a pre-established pattern ready for that type of document. You shouldn’t have to spend days and weeks deciding whether to write headings as questions, as gerunds, as infinitives, or as statements. Organizing should mean putting the content into the pattern for the type of document you are creating. It should mean deciding on the order of headings, not the type of headings.
If you don’t yet have those patterns, find an example of a document that has worked well for the users and scenarios closest to your new project. Build a pattern from it.
If chaos is your current process (and it is if you don’t have designs and templates ready for the typical document types your group works on), you’ll find that putting some of your very precious resources into getting ready to work smarter and more rapidly in the future is a good investment. (I’ll come back to this point in the last section of the article.)
Okay. We’ve come to the part that everyone else assumes is all we do. And, yes, if you are developing documents (also if you are writing Web content or helping to imbed communication in interfaces), you do get to the stage of creating text and graphics. My point up to here in this article is that this stage can be done much more rapidly with less need to revise if you’ve done the earlier stages well.
What makes for smarter and more rapid drafting?
- Write less. Users don’t have time to read. That’s a result that we’ve found over and over in research and usability testing (Sticht 1985, Carroll 1990, Redish 1993, Schriver 1997, Redish 1999). If the documentation that your group writes is instructions for setting up, using, or troubleshooting hardware or software, what you are creating are tools for using tools. Users want to spend as little time as possible in the documentation. They want to get in, grab what they need, and get back to work. Smart and rapid drafting means saying only what needs to be said, saying it succinctly, chunking information, using bullets and numbered steps, using graphics where they make points clearer.
- Reuse. If you have a content management system, you should be set up to find and reuse material easily. Even without a content management system, you should have an inventory of the files your group has created for different documents. You should be able to easily grab pieces from other documents to bring in and massage as needed for a new document.
- Templates. At this stage, you should be focusing on the content-on the information that users need-and not on formatting. You may have noticed that page layout is not part of the SRMS. Of course, well-designed page layouts are critical for successful documents. However, unless every document your group develops is a totally new pattern, you should not be creating page layouts anew for every document. You should have already worked out templates for the document types your group works on regularly.
- Style guide. Writers shouldn’t be spending time pondering whether to spell database as one word or two, whether to number the step if a procedure has only one step, whether to call something a “note” or “tip” or “hint.” Your group should have decided how you are all going to handle each of these issues and many more and should have codified those decisions into a style guide. If you do have a style guide, make sure all your writers know about it, know where to find it, and use it.If you don’t have a style guide, start to accumulate issues and decisions now. Set up a place on your group’s network drive or intranet space and start to build a style guide as a set of FAQs (frequently asked questions). Let your information developers put up questions. When you answer one of these questions, that Q&A becomes part of the group’s “in the works” style guide.
Edit, Review, Revise
No matter how smartly and rapidly your information developers work, you&’ll still need to plan on more than one draft. Insisting that everything be written perfectly the first time-with no time for editing or revision-may lead to writer’s block. The increased anxiety and stress may make your information developers less efficient, not more.
In the early years, we sometimes went through three or more full rounds of edit, review, revise. That’s gone. And we shouldn’t need it. How can you get through the edit, review, revise stage smartly and rapidly?
- Keep a senior editor. Especially with new information developers, mentoring by an editor is still essential. Even in these days of budget cuts and staff cuts, I would use some of those precious resources for an experienced senior editor who understands your audiences, their scenarios and vocabulary, your company’s business purposes, your style and formats-and who is good at mentoring information developers. Depending on your resources and the group’s work load, you may not be able to have someone in a full-time position with the appropriate title; but don’t give up the job. Editing needs to be done; information developers need to be mentored.
- Don’t wait until an entire document is drafted to start editing or to get reviews. This point should really be in the drafting stage; it’s one of the ways that the model is interwoven and iterative. We’re trying to reduce rework. One way to do that is not to let too much get written before being sure the information developer is on the right track. Especially with new information developers, you may want to ask for a draft chapter and be sure that both you, as communication reviewer, and your technical reviewers agree that the document is shaping up with the right level of detail, right vocabulary, right style for the audiences and scenarios.
Getting to the end, publishing, requires not only your group’s work but time and effort from others-from reviewers. Getting them to work smartly and rapidly is part of our SRMS.
- Communicate with reviewers early. For a very long time, I’ve advocated getting reviewers on board from the beginning of the project. Find out in the planning stage who must review and sign off on whatever you are doing. Involve them in planning. Give them samples of similar documentation. Have them sign off on the Information Plan. That way, what you send them for review later will not be a surprise.
- Get on reviewers’ schedules early and keep them informed of changes. Reviewers are also busy people. Keep on their good side by communicating with them-not overwhelming them by sending too many emails-but enough to have them be ready for what you need reviewed when you need it.
- Get what you need from reviews. Are your reviewers the same people we were talking about back in the section on getting and selecting content? If so, I’ll reiterate the need not to mope about distance but rather initiate contact. Set up relationships by whatever means are available. Find your counterpart in the engineering group in India, Singapore, or wherever and establish rapport.Information developers and engineers are often introverted people, and now we may have cultural differences to deal with. With so little time for so many things, “avoidance of the difficult” may lead to just not getting around to setting up relationships with the technical people who must review what your group prepares. But you must do it. To get useful reviews, you must have contact with the reviewers-or their supervisor. You should have a conversation about expectations before the reviews begin. Consider holding a short teleconferencing session in which you do a joint review of part of a document to clarify what you want from the reviewers and what the reviewers want to give you.
Working Outside the Model
Some information developers are complaining about becoming a “commodity,” about not being able to be creative in their work. In part, that’s an issue of attitude and self-perception. As I’ve argued before (Best Practices June 2000), working within a structured process and patterns can be liberating for an information developer-can free the information developer to focus on users’ needs, to focus on content.
In part, I think the sense of being a “commodity” comes from the fact that working smarter and more rapidly usually means having a structured process and appropriate patterns, designs, templates, and styles for different types of documents. Some people feel that much structure creates “boxes” and working with the model means working “inside the