I’ve recently started to work on a new project with a very complex structure, involving different teams, products and technologies. To make sure that I can deal with this complexity and deliver the best quality for the product documentation, I’ve decided to sign up to a course on Udemy to learn how to manage complex projects for technical documentation.

These are the takeaways from the first lesson “How to Define a Plan for Managing a Documentation Project”

What is a Project?

The Project Management Institute (PMI for short) defines a project as a specific set of operations designed to accomplish a singular goal. A project is temporary, and must have a defined scope and resources.

The technical writer’s project is usually a documentation deliverable, which can contain different types of files (software documentation in html, pdf or any other formats, trainings, videos, interactive activities -e.g. Pendo, WalkMe- ). After delivering a first version, the TWs usually switch to a more operational role in which they enhance and optimize the content.

The project manager is the person responsible for delivering the project, but it does not have to be the one that executes the actual work. A project manager can be usually seen as a coordinator or facilitator to the project.

As a technical writer and project manager, you create a project in which you plan, design and develop the first version of a documentation deliverable. You need to define specific KPIs (metrics of acceptance). For example, what are the minimum requirements for a user guide or what is considered as “acceptable”. 

Some methodologies (e.g. agile) include things like “definition of done”, which helps us define the criteria by which the release will be approved or rejected, that is, when can a task be considered to be “finished”. 

It is important to remark that the technical writer must act as a “customer advocate”, meaning he/she has to make sure that the definition of done includes quality criteria that guarantee a positive user experience. The documentation must be always evaluated with the customer glasses on.

Another thing to clarify is whether we still have a project after delivering the first version of the documentation. The short answer would be “no”. After the first release, the project enters into maintenance mode. Here a sequence of steps is taken to keep it relevant and updated, but the project is finished, as we are not creating anything new, we just improve what we have in place. A documentation project starts with the project definition and finishes with the release of the first version of the documentation.

Differentiating between the project phase and the maintenance phase is key for allocating resources. When creating a new documentation deliverable we must always take into account (and not underestimate) the cost and resources needed for the maintenance phase, although it is not strictly “part of the project”. Don’t forget to have a buffer for the second phase.

The following are knowledge areas identified by the PMI to define a project:

• Integration of processes
• Scope: which goals will be defined for the project?
• Time: what is our schedule
• Associated costs: how to track the budget and expenses (e.g. salaries, infrastructure costs), allocate resources
• Quality
• Procurement: relevant if you are working with vendors. Which kind of contracts must be signed and other legal aspects.
• Human resources: who is going to work on the project. 
• Communication: set up a communication plan and a documentation strategy to work with the stakeholders and make public announcements. Ask yourself who has to receive the updates on the project: end users? Other project managers? 
• Risk management
• Stakeholder management: know their expectations and make sure that your deliverables meet them.

Stages of a Documentation Project

Every project consists of 5 phases:

• Initiating
• Planning
• Executing
• Monitoring and Controlling
• Closing

Initiation Phase

It all starts with a need. Your company or your customer needs documentation for a project. As soon as you receive a request for documentation, you enter into the first phase: Initiation. 

In this phase, you try to figure out who are the stakeholders; that is, any person that might be affected by the documentation project. That includes both the end users of the documentation and the people contributing to create it. On the development teams you work with, there must be always one of more persons that provide you with the information you need: 

• Functionality
• Capabilities
• APIs
• Parameters
• User interface
• Access
• Steps needed to use the software
• …

The outcome of the initiation phase is a written document that outlines the project goals. Having clearly defined and written goals helps you create a solid commitment, which in turn allows you to define the rest of the plan. Actually, by writing down your goals, you can increase by more than 50% the possibilities to realize it!

Beside the goals, the documentation project summary should include the project scope:

• Name of the project (obviously)
• Project sponsor (the person that named you project lead. He/she is paying for this)
• Project lead (your or your manager)
• Project timelines
• Project budget
• Tools
• Deliverables

The project summary should be reviewed by different stakeholders to make sure that the goals described are aligned with their requirements and expectations. If their expectations are higher that the output that you can deliver with your current resources, make sure they strike out one or more goals. You should only focus on the remaining goals and make sure you also plan a buffer to resolve any unexpected events. Above all, avoid scope creeps and gold-plating (don’t give the customer more than what he originally asked for).

Ideally, you will also have a signed-off project charter, which is a document signed by someone with the authority to assign project resources and name the project manager. This document entitles you to act as a project manager and ultimately gives you more visibility and power.

Planning Phase

In this phase you develop a plan to define how you are going to reach the goals set in the scope of the project.

Execution Phase

Here you do the actual work that has been planned in the previous phase.

Monitoring and Controlling Phase

In this phase you check:

• If the work has been correctly executed and if the KPIs defined in the initiation phase are being met. 
• If the quality delivered complies with the requirements defined in the DoD.
• Any adjustments required by unforeseen changes in the overall project (e.g. release data is postponed)

Closing Phase

You deliver the documentation output, mark the project as “done”, and capture the lessons learned during the execution of the project to avoid negative situations in future projects. In this document, you can include the following five steps:

• Identify comments and recommendations that could be valuable for future projects

• Document

• Analyze

• Store

• Retrieve

For more information, see: https://www.pmi.org/learning/library/lessons-learned-next-level-communicating-7991).

Optionally, you can schedule a formal “closing meeting” where you identify what went well, what went wrong, and what are the takeaways that we can relate to when a new project is started. This is a great asset for any company, as it helps to save time and improve the overall execution of the project.