Note: This post summarizes some lessons learned from a course I’m currently taking about managing complex projects for technical documentation. It also includes my personal views and ideas.
The Project Management Institute divides the large field of project management into 10 more digestible parts, which are known as the 10 project management knowledge areas:
- Project integration management
- Project scope management
- Project time management
- Project cost management
- Project quality management
- Project resource management
- Project communications management
- Project risk management
- Project procurement management
- Project stakeholder management
In a documentation project, not all these areas will be always relevant.
The integration area brings together the organizational aspects of the project: scope, time, cost, quality and so on. This area can be used as a reminder that every time you make a change to one aspect, you need to reevaluate the impact of the change on the whole project. For example, any budget changes, e.g. budget cuts, will have a big impact on other areas of the project and trigger some changes in, for example, the scope and schedule.
The scope area refers to the tasks and goals that should be covered when completing the project. You must clearly define what you are going to deliver to avoid misunderstandings and have a roadmap you can relate to.
Time is the third knowledge area. Here you define the schedule and how much time should be spent on each activity. The definition of a project already implies that it has a planned end date or release date. This date is usually very close to the release date of the software. If you work in Agile mode, with iterative deliveries, this might be even more challenging, so it’s important to have a very clear statement on how are you going to handle the time management aspects of the project, as you need to have a version of the documentation ready for release by the end of every sprint.
The cost area might not always be relevant. It depends on the business relationship you have with your client (if you are an external worker versus in-house technical writer). If you have a contract to deliver one or more projects, you might have to take into account the total budget you can use, if you are spending according to the plan, etc…
The quality area includes different metrics that should be applied to ensure the quality of the output. It is very important to discuss with stakeholders which KPIs will be measured: a certain volume of content, language correctness, perceived quality based on customer’s ratings, quality of the processes, etc…
Procurement is the sixth knowledge area, which is only relevant if you have to work with external vendors or third-parties. That is, if somebody else (a specialized company, freelancers, infrastructure vendors) will be hired to author the documentation and/or provide the necessary infrastructure, like documentation tools and cms. Procurement is about negotiating with third-parties the organizational aspects and conditions to execute the project.
Human Resources is the next knowledge area. It deals with the headcounts assigned to the project and other team-building aspects (collaboration, possible conflicts, clear definition of roles and tasks, how are decisions going to be taken and by whom).
Once your team has been properly set up, you need to consider how communications are going to be managed, which is the eighth knowledge area. This is probably the area you should devote more time to. It includes internal communications (within your team and with other teams and stakeholders) and external communications (with end-users or customers). You need to evaluate which information is needed, by whom and when to share it. The communication channel is also relevant. Your job as project manager is to ensure that information is exchanged regularly and flows in a bi-directional way between you, your team and the stakeholders.
Risk management is the ninth knowledge area and is as critical as communications. Assessing risks and elaborating a contingency plan will help you be prepared for any project deviations. In the risk register, you document the incidents that can impact your project or even shut it down. These incidents can be classified into different areas, and they can have a positive or negative impact on the project.
The last knowledge area is Stakeholder management. Here you plan how to interact with your stakeholders to ensure that they are happy with the progress and the documentation output. Always bear in mind that your stakeholders are different. That means that their requirements might not only differ, but also sometimes be contradictory. That’s why it is important to always document their requirements, bring the stakeholders together in case of conflicting interests, let them come to an agreement and communicate the final decision to all the people involved in the project.
One thought on “Project Management for Technical Writing – Planning to Manage a Documentation Project”