The Lone Writer as Project Manager

by Laura Dahlinger

Laura has been PMP certified for eight years in Columbus, Ohio.

Lone writers occupy a unique position within an organization. Generally, lone writers have their "hands" in much of what is happening within the organization and can anticipate a need for their services in a variety of departments. However, this can lead to over-scheduling of the lone writer.

So lone writers must also become their own project managers, managing the documentation demands of the organization by using the basic principles of project management.

There are five main "stages" of a project: initializing, planning, executing, controlling/monitoring, and closing. I have found that I am more involved in the initialization process as a lone writer because I know what's happening around the organization. Most writers are assigned a documentation project in the planning or executing phase because they are part of a team of writers and their manager performs the initiating and planning phases.

I can suggest where I can help out in new projects or wherever I see a need for a process to be documented. I can then be involved in all of the remaining stages as I'm doing the writing and discussing it with my subject-matter experts (SMEs).

Nine Knowledge Areas

There are nine knowledge areas that a project manager must be able to use as well: integration, scope, time, cost, quality, human resources, communications, risk, and procurement. A basic explanation of each knowledge area is included in the table below. These stages, described in the 2004 Project Management Book of Knowledge, play a part throughout all stages of the documentation project. Each document I create has its own time frame, varying from long-term maintenance and upgrading of the user help manual to the quick editing of the marketing department's news releases.

Initializing

The initializing phase can begin with a new software release or a change in equipment at a plant. New instructions must be created and old ones updated. So the managers in charge must see the need for a change. I start my initializing stage when I find out about a new release date for a software update. I start by talking to my manager about when the release will occur and what the release number is.

At the initializing stage, communication, time, risk, and integration management are the key knowledge areas I utilize. In general, the only risks I deal with are time consumption by other projects — if another document project must be completed within the same time frame, for example. This can easily be dealt with by carefully planning the communication with all parties involved about the deadlines, determining the quality of the documentation I will produce so I don't spend too much time on something that is supposed to be a brief overview, and making sure the scope of the documentation does not expand beyond what is intended. This limits the time spent, the risk of not completing my documents on schedule, and the cost of my time to the company.

As a lone writer, the cost, human resources, and procurement knowledge areas are less relevant but still play a part in my job. There is the cost of overtime if I work over the 40 hours a week, the cost of delays in releasing software if I cannot meet my time deadlines for the associated documentation, the possibility of outsourcing or bringing in a second writer if my workload gets too heavy. Will that second writer be hired on a permanent basis or just for the length of the project that must be completed? I am the main project team member, but I also take up the time of the SME that I speak to, whether it's for five minutes or three hours. The cost of completing documentation is inherent in my salary but it extends to using the time and resources of other people in the organization. So I need to be sure of my own questions to SMEs and minimize the costs and risks of spending too much time documenting something that is only a very small portion of the whole.

Planning

I begin the planning phase by looking at the implementation plan created. If there is a new piece of software the customer requested, this plan includes the details of what change must be made to the software. If it is just company-driven changes such as fixing issues, I may need to speak to the person who discovered the issue, reference the case opened about this issue, and speak to the developer, who is my SME.

I begin to use integration management skills to coordinate my need to ask questions into the time and resources of my SMEs. I am dealing with the scope of the document to be sure I am not documenting extraneous information, but I also have to explore the updated software to make sure I'm not missing anything. If I forget to document something, the help desk will be sure to get calls about the problem or instruction I missed, adding costs in that department and lowering the quality of my document in general.

If I find issues to document, I can also gather those and forward them to the help desk as part of my communication with other employees who are affected by the new release. And I can give these issues to the development team to be fixed in future releases, so the steps I used to cause the issue must be documented adequately as well.

Executing

Then I begin writing the release document, using my own testing of the new release, if available, and my research so far to write what I can. This part of the execution phase overlaps with planning as I also map out what needs to be changed in the related user help manual. I also plan out how much time I think it will take me to complete the new release upgrade document, which is a cost to the organization.

If multiple documentation projects are ongoing, which they usually are, I must organize the projects by priority, communicating any changes in completion date to the right people. I always need to return to the scope of the project to make sure I'm completing my documents within the plan I created.

As I test the new release to confirm how users will use it, I must always write with the scope, cost, time, and quality of the document in mind. Too much testing can lead me down the path of all testing and no writing, which is the job of a quality assurance (QA) tester. I actually am part of the QA team, but I have to keep the document I'm writing for users of the software foremost in my schedule to make sure I write the best document I can for them. My ability to work on different aspects of the software, from testing to answering support questions, also makes my documentation much better because I understand the software better. But it also can make prioritizing what to do first a big task!

Monitoring / Controlling

As I test and write, I am also performing the monitoring process. Planning, executing, and monitoring all fall into the same process for the lone writer. I have to stay on my toes, keeping track of what I've completed and what I have yet to document. I need to communicate any software issues with the SMEs and possibly managers if I run across any issues with the software that are big enough to be a problem for the release. I am constantly keeping track of my schedule as well, making sure that I'll be able to complete the changes in related documents, such as the user manual that accompanies the release, and the new release document on time.

Closing

And once the documents are complete and heading out the door to customers, I find that the closure part of the process can be either very helpful or very tedious. Since I am a lone writer, I generally have a short meeting with my manager to talk over any issues that come up with the writing process and get ideas for improving the documentation process.

For example, I can begin to add some small icons to the new release document to help visually categorize what information is useful for an administrator, someone installing/setting up the software, and an everyday user. This stage is generally short and just gives me some time to review the documenting process and see where I can improve the way I do things. This can improve the entire process, from the cost of my time spent to the quality of the documentation produced.

Summary

The biggest difference between me as a lone writer/project manager and a full-time project manager is the amount of paperwork! I do not necessarily write a work breakdown structure (WBS) for each document I work on. I create a plan that is my own version of a WBS, but it isn't as detailed as it would be if I were working with an entire project-specific team. I don't need to include actual cost totals and a detailed process for making changes to the scope or schedule.

With my manager's input, I worked out a general game plan for completing new documentation and updating old documentation, and I use the game plan for most documentation projects. I use all nine of the knowledge areas and go through the five stages of a project every time I write documentation, giving me the experience of a writer and a project manager all wrapped up in one job.

Laura Dahlinger is a technical communicator/project manager at the Ohio Department of Transportation for Quick Solutions, Inc. in Columbus, Ohio. Laura earned her PMP certification and has been a technical communicator/project manager for eight years.

.