Developing Good Project Management Skills as a Technical Writer

The Company is rolling out a new piece of point-of-sale inventory management software. You need to write online help, a printed manual, a quick start guide, and produce instructional videos for training staff to use. How are you going to get it all done? Technical writers often need to manage more than one large project at a time. Developing good project management skills is as important (or more so) than good writing skills. Time management also plays an important role. No one wants to be responsible for holding up the release of a new product.

Define a Timetable

When Does the Product Launch?

Write out a timeline by hand or by computer, with today's date on the left and the product's target release date on the right. Make a list of the various steps involved in the project, from data gathering (learning, user consultation, S.M.E. interviews, reading manuals from previous versions), to organizing, and drafting the various deliverables. How much time is available? Do your best to estimate the time each step will require, and then double it. Does the project look doable? Do you have any choice? Can you arrange for help, either from fellow employees or contractors? Can the launch date be adjusted to reflect reality?

Is the Product Finished?

The answer to this question is nearly always "no," unless you're revising the help for an existing product. For a new product, the Company will want to launch as soon as the product can be shipped. You'll need to write the documentation as the product is being developed. If changes are made to the product (and there will be), changes will have to be made to the documentation. Be aware that your project will be subject to revision at any time. This is one good reason to estimate a longer time for each phase of the project.

Assigning Tasks

Do you have a staff or a team, or are you on your own? If you lead a staff, you will need to decide which tasks to delegate to whom. Often, team members develop different strengths that complement one another. One writer may be more comfortable with web page markup, while another has a flare for illustrations. Try to assign tasks to the staff according to their strengths.

If you are on your own, chances are you'll be doing some delegating just the same. Your Company may have an art department that handles the illustrations, but more likely you'll be dealing with an outside graphic designer for visual aids. Many aspects of a project can be outsourced to specialists. Does your Company work this way? It is even possible to outsource technical writing; so an in-house writer may be more of an editor and project manager than an actual writer?

Collaborating

Effective technical writing can depend on effectively dealing with coworkers. While your S.M.E. may be essential in providing the information you'll need, they have their own work to do and their own timelines to consider. An interview with the technical writer may not be the first priority on their list. Try to find convenient ways to get the information you need. How do they like to communicate? Some people prefer to talk in person; others prefer the asynchronous nature of e-mail. Regardless of your preference, do your best to accommodate your S.M.E. Demonstrating sensitivity to their situations and preferences can go a long way in fostering their sensitivity toward yours.

Keeping Everyone on Track

No one likes to go to too many meetings, but it is crucial to stay in touch with team members, and to be aware of what's happening on the product development side. Depending on your Company's philosophy towards communication, you'll need to work to find effective ways of staying in touch with the writing staff as well as the production and design staff. Technical writers may be required to attend development team meetings, or they may be strictly prohibited from wasting time in this way. The important thing is to find a way that works within your Company's culture to stay in touch with everyone involved in the project, to be aware of changes, to be confident that everyone has the information that they need, and that everyone is moving forward according to the timeline.

Check Your Ego at the Door

Working on a team can bring a variety of personalities into play. The S.M.E. may not particularly like taking time from their work to explain a product to a technical writer. There may be conflicts on the design team regarding the best approach to solving a problem, and you as the writer may be pressured to take sides. As the launch date for a product approaches, everyone's patience may wear thin.

The successful technical writer, like any successful member of a team, should approach situations like these with a healthy sense of detachment. When tempers wear thin and everyone is working too many hours, try not to take other team members' sarcasm personally or let someone's rude e-mail touch off a flaming session. Above all, do not let anger cloud your behavior, nor say anything which you may regret later. If you do become angry, excuse yourself. Walk around the building. Go out to lunch. Remember that everyone on the team has a common goal, the successful completion of the task at hand. Keep your emotions in check and don't sink to the level of any coworkers who have lost control of their emotions.

Feedback from Users

If at all possible, getting early feedback from users or beta testers can be invaluable in helping you spot sections in your documentation that need improvement. This is not always possible or part of the Company procedure, but it can mean a much better result when the product and documentation go public. Talk to your supervisor before the project begins and ask what kind of feedback options, if any, are available. If there are none, you may want to suggest some. Perhaps you could put together a small panel of users and interact with them over the Internet. This option is relatively low cost and could save the Company money, especially if your Company's documentation is printed in hard copy format (and therefore expensive to revise once published).

Keep Your Momentum

Your initial plan for the project should include interim completion dates. When should the interview process be completed? How many words of copy will go into the manual? How many weeks will it take to write that copy? What date will you need to begin? By what date will you need to be halfway done? On what date should your outline be completed? With a plan like this, you'll be able to check in periodically to see if your project is on track with your timeline. If it isn't, you'll know that you need to step it up, reallocate resources, or ask for additional help.

One of the most effective ways to keep up your momentum on a project is to keep it moving forward, even if only minimally. Often, technical writers will be tasked with working on documentation for several products at once, and it will be difficult to devote time to one when another has a much closer deadline. Regularly spending a little time on the back burner project, though, can have very beneficial effects. When you know both projects are moving forward, you won't experience the stress of feeling that you have no time to devote to the lower priority project. You'll know that when you do have time to devote to it, the project will already be underway and will have a momentum of its own. When it does become your high priority project, you'll be able to jump into something that you have already moved forward, instead of cranking a new project up from scratch.

Another way to keep your focus is to see how far you've come. As you're writing chapter after chapter of a manual, it may seem that the task is endless, especially if design changes have forced you to revise sections of the manual. Instead of getting discouraged about ever finishing, take some time to review all the work you have done so far. Page through the transcripts of all the interviews you've conducted, scroll down all the pages of notes, outlines, and draft copy you've created. When a project seems endless, noting just how much you've achieved thus far will help you see that you will get to the end of your draft if you just keep going. Taking a few minutes to look back may also help you remember a detail or an example which you once meant to include in your copy but that had slipped your mind until now.

Interested in learning more? Why not take an online Technical Writing course?

The strategies above are effective ones in battling or preventing the dreaded writer's block. Writer's block can strike new and experienced writers equally. It often comes at the start of a project, when you know you need to put those first words down but just don't know what to say. You may be tempted to put off your draft for another day (or several). You may conclude that you haven't done enough research. More than likely, though, you're experiencing fear. Fear that you will not write this manual well. When faced with a large task, many writers can get stuck. The crucial thing to do, though, is to start anyway. Write something. Even if it has to be removed or completely revised later, it is best to put words on the page. If you put the work off, the stress of falling behind schedule will only make the writer's block worse. If you wait too long, you won't have time to give the project the quality it deserves. Keeping a project moving forward, as we mentioned above, keeps stress levels down and lessens the chance of writer's block rearing its head. Reviewing your notes can also help you remember that you have plenty of material to write about. You may also hit on an angle that will help you begin.

Another way to battle writer's block when it strikes is to work on something other than the beginning. Is there a section that is more mechanical than the others? Perhaps chapter 7 is a list of troubleshooting procedures that S.M.E. have listed for you, and you just need to edit them a bit. Perhaps you want to start with a lower tech section of the manual, like keeping the product clean. Dive into something simple, and the momentum you generate will help you keep going as you get into the more challenging sections of your work.

Dealing with Slowpokes

While it will be up to you to keep your own productivity on track, there may be other people on the project upon whom you depend, and who may fail to fulfill their own responsibilities. You may have trouble pinning down one of the S.M.E., or work with an illustrator who is overbooked and keeps giving you excuses. How can you keep your own work on track when someone else isn't holding up their end of the bargain?

Stay in touch
It's wise to keep in regular contact with team members that you depend on. Check in with them periodically to see how they're doing. Ask them if there's anything they need from you. You'll get a sense early on if someone is a potential source of trouble. Team members who are slow to return e-mail or phone calls may be equally slow to turn in work down the road. People like this often mean well, but suffer from poor organization. They are always behind and spend their time putting out the fires they've started by always running late. For coworkers like this, the squeaky wheel usually gets the grease. If they hear from you regularly, they'll keep your project and your needs in mind. Be patient, and be persistent, but don't be pushy. Ask how you can help. Establishing a good relationship with the people you depend on can forestall eleventh hour emergencies.

Unfortunately, this strategy won't always work. Sometimes you'll need to go to a supervisor or project leader to report that your team member is holding up the project. Keep records of your contact with team members, in case this comes up. You'll want to show that you made regular efforts to stay in touch, offered support and feedback, and so forth. You're more likely to get the manager or leader on your side if you prove that you've done everything you can to get the project materials pulled together yourself.