The Lone Writer as Project Manager

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 a lone writer must also become their own project manager, managing the documentation demands of the organization 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 since 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 (SME). 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 documenting 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.
  • Integration - Make choices about where to focus the work on a given day of the project and coordinating the work on the project.Used when various knowledge area processes interact.
  • Scope - Verify that only the processes required to complete the work for the project are completed.Used to define what is included in the project.
  • Time - Scheduling of resources and the time it will take to complete the various pieces of the project.Used to keep the project on track for the deadlines.
  • Cost - Budgeting of resources and time required to complete a project and the future maintenance of the finished product.Used to determine the cost of resources.
  • Quality - Identify and assign processes to assure that the level of quality expected of the completed project is satisfied.Used to address the quality of the end product.
  • Human Resources - Assign and manage the staff necessary to complete the project.Used to develop and coordinate the project team members.
  • Communications - Plans for how all communications about the project will be handled, including distributing information about the project, progress reports, and employee performance reviews.Used to coordinate all communication between project staff, management, and stakeholders in the project. Project stakeholders are people or an organization actively involved in a project so the lone writer and the developers of software, for example, are stakeholders.
  • Risk - Plans for dealing with any uncertain event that could impact the project (risk) positively or negatively, including identifying, planning for, and monitoring factors that make risks occur.Used to plan for the risks associated with a project, whether their impact is positive or negative.
  • Procurement - Processes used to acquire services or goods from outside of the project and/or project staff to complete the project.Used to get the extra assistance required to complete the project, whether by contracting another writer or buying additional tools to accomplish the project tasks.
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, communications, 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, risks 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. I begin the planning phase by looking at the implementation plan created. If there is a new piece of software the customer requested, this 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 working on it, 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. 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 order 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 as I understand the software better. But it also can make prioritizing what to do first a big task! 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. 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 came up with the writing process and get ideas for improving the documentation process. For example, I began 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. The biggest difference between myself 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 was 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. I have a general game plan for completing new documentation and updating old documentation that I’ve worked out with my manager and I use across most of my 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. Contributed by Laura Dahlinger