Skip to Content Skip to Main Navigation
 

Five Questions to Ask Yourself While Creating a New Documentation Department

by Eric Butow

Editor’s Notes
Being asked to take the reins of a brand new documentation department is a challenge that many professional technical writers relish, even though the training and development activities they participated in may never have prepared them for such a rewarding challenge. This article looks at forming a new documentation department and determining what’s needed, when it’s needed and what resources are available to help the new department carry out its mission.

Congratulations! You’re the manager of your company’s emerging documentation department — and your work has just begun. To create effective documentation for your customers, you not only have to build a sound team, but also build working relationships with all other departments in your company.

In my contracting travels, I’ve set up two new documentation departments in two very different settings. My first was a documentation department for a startup networking software company in 1999. The company’s only previous documentation was a slim manual written by a programmer.

In 2004, I helped set up a new documentation department at the financial aid division for a major bank. Over the years, this division had been passed along to different parent banks — the newest of which was shocked to find that no one had written documentation about financial-aid processes, and no documentation about the software they had used during the division’s last 20 years! As a result, the new parent organization decided that relying on the institutional memories of its employees was a major risk, so the documentation department was born.

When you create your own documentation department, you should ask yourself five simple questions that will help your new department show its value to the company as quickly as possible. These questions are similar to those that a good reporter must answer when documenting a story — who, what, where, why, and how? — and they are as important for a documentation department manager as they are for an ace journalist.

The questions are:

What has to be done?

To answer this question, you must identify what documentation your company needs to create. In some cases, company executives may have your first assignment ready for you, complete with impending deadline, such as creating a user guide for the company’s software. In other cases, you may need to interview managers and subject matter experts (SMEs) to determine what must be done.

At the very least, you should interview all the managers in all the company’s divisions. This will not only familiarize yourself with the company, but also familiarize each division with you and your efforts. Come prepared with a series of questions and answers for the manager so you understand how that manager uses documentation, even if he/she only gets information passed down to him/her second-hand from a department that uses company documentation.

If you run into skeptical managers, remind them that documentation is the first line of customer support, and that everyone in the company uses documentation — either directly or from other departments.

Visit with each department manager and important SMEs regularly, especially those with whom you deal most often. You’ll likely need to set up formal appointments with those people who have busy schedules.

You can also familiarize yourself with managers and SMEs by visiting their offices or cubicles to say hello if you’re in the area, or go to lunch with them once in a while. The old saying, “the squeaky wheel gets the grease” describes the efforts you should take to keep your department visible in the company.

When must things be done?

When you learn what must be done, you will also learn when things must be done. You may also discover that managers and SMEs realize they need documentation but have no clue about what documentation needs to be done and when.

After you gather all the data from your interviews, put your project management skills to work and create a task chart to show management that you have a grasp of the situation. Don’t worry about getting everything exactly right the first time. The goal of any first draft is to provide the bridge from concepts to a tangible result. Offer the draft as a starting point for discussions and suggestions, and be clear about your openness to constructive feedback. Once your recipients see your first draft, they’ll also see what needs to be added, deleted, and/or changed.

When you send this first draft of the task chart, send it with deadlines for each reviewer so you can receive feedback in a timely manner. If necessary, you may want the deadlines specified in a memo from your manager, especially if you have reason to believe that others will not give sufficient weight to timelines that come directly from you – the new documentation department manager.

After the task chart is finished and approved by the appropriate managers, distribute your entire chart to your documentation team and also determine with your manager how to distribute the chart to other stakeholders. For example, you may need to provide to the project manager a section of a chart pertaining to a specific project.

Who must be hired to get things done?

After you create the first draft of the task chart, you’ll get a sense of how many employees you will need to finish the jobs in the time frames that the company expects them to be done. Document the number of employees you need, the tasks for which they will be responsible, the skills each person needs, and then submit the information to your manager for approval. You might need to attach specific skills for a specific job opening, such as for API documentation, as well as attach a proposed salary. Resources such as the Society for Technical Communication (STC) Salary Survey are good places to find salary information.

Your company’s Human Resources (HR) office should be a key asset in building your staff, so be sure to cultivate positive relationships with the HR people who handle recruitment and hiring. These working relationships will be useful later should personnel problems arise. Usually, HR people are the experts on documenting problems and dealing with them fairly.

No matter how a problem may arise, ensure that you document the problem, frame your concerns around how the problem affects the company (never make it personal), and offer constructive suggestions for resolving the problem. Your company should have written policies you will want to follow in such circumstances. If not, documenting such policies could be another opportunity for your department to address.

What must I use to get things done?

After you create the first draft of your project chart, you will begin to figure out exactly what software, hardware, and documentation you need to supply your team to get things done.

The company may have already supplied you with the hardware you need to at least run software and communicate with the company through its e-mail network. However, the hardware may not be what’s required to get the job done. For example, if your company produces its products on a Mac, you may want your team to use Macs to create the documentation.

The hardware and software your company uses can also affect what software you use. For example, if your customers expect documentation delivered online in Word format, then you will likely have to use Word. However, if you know from experience that another program would be better for the job, learn how the software you want will benefit the company. Frame your proposal around those benefits, including how the new software would resolve issues with your current software, and then talk with your manager about your ideas.

Finally, you should also look to technical documentation Web sites such as STC (http://www.stc.org) and newsgroups to get ideas for books to populate your library, and make sure the materials in your library are available for other documentation team members. You should also adhere to a specific style guide such as Microsoft’s Manual of Style, which is available for downloading on Microsoft’s Web site, or a style guide already in use by your company. If your company does not have a style guide, you will likely have to create one.

How will the department’s place in the org chart help me get things done?

You may or may not have any say in where your documentation department is placed within the company’s hierarchy. For example, documentation may be contained within the engineering division, within a larger communications division, or it may be its own department entirely.

It’s also likely that you will deal with other divisions outside your own. For example, documentation, training, and your company’s Web-site departments are all related to each other, but you may find all three departments in different company divisions.

If possible, work with your company’s executive team to identify what division you should be under, or if you should combine your documentation department with related departments such as training and/or Web creation to leverage your company’s communications assets.

Always keep track of how your department works in its current position on your company’s totem pole. If you find that your department isn’t helping you get things done, bring your documentation and suggestions to your manager. Constant communication and friendly visibility on your part helps you answer this and the other questions you have so your documentation department can provide maximum value to your company.