How to handle risks in Technical Writing

Risk management is a very broad topic, I can’t cover it all within one article. Yet, there will be a lot of text here… By the way, if you don’t mind longreads, you may find this one interesting: ISO 31000 — the international risk management standard.

Most likely, you have already dealt with the risks highlighted below, one way or another. Still, it’s always a good idea to recall, analyze your experience, take a fresh look at the known facts, and seek out for new ideas. As a bonus, at the end of this article, you will find true stories full of d’oh moments. Also, I encourage you to try on the described risks and think how you would cope with them.

So, without further ado, let’s dive into the theory and practice of risk management in Technical Writing (or simply Tech Writing).

Lil bit of theory

A risk involves uncertainty about the effects focusing on negative, undesirable consequences. To prepare accurate estimation and avoid delivery delays, it is important to identify, analyze, track, and mitigate all the available and potential Tech Writing risks on the project. That’s how it sounds in an “academical” way.

In simple terms, a risk is the possibility of something bad happening. And according to the Murphy’s Law: anything that can go wrong will go wrong…

Most common Technical Writing risks for software products

Some of the risks and the resulting consequences are quite obvious. Still, we, as human beings, tend to fall for them.

Take a moment to think whether you are considering these items as risks on your current project:

• Lack of permanent access to the product
• Lack of permanent access to the Subject Matter Experts (SMEs)
• Access to information is blocked (including delays due to the holidays season, vacations, sick leaves)
• Need to migrate between tools or environments
• Changes in the priorities and scope of work (the backlog is changing, and the deadlines are not)
• Inaccurate Tech Writing estimation
• Poor documentation strategy
• Incomplete Technical Writing guidelines (gaps in the naming convention, definition of done, and the product tone of voice)
• Maturity level of the Technical Writers
• Workload and inefficient planning
• Nonexistent review procedure
• Failure to follow the backup procedure
• Localization of the product for other countries
• Ignoring the accessibility and inclusivity requirements
• Client’s business need for documentation is not clear
• Client doesn’t understand the value and purpose of Technical Writing
• Client provides no regular feedback on the deliverables
• Tech Writing risks are not communicated to the stakeholders (yep, the risk of not communicating risks)
• Lack of PM’s involvement in the Technical Writing services
• Tech Writers are not considered to be part of the team
• Communication issues inside the team (including asynchronous communication due to different time zones)
• Cultural differences inside the distributed team
• Soft skills issues and relationships inside the team
• Losing critical information (key players leaving the project)
• Using AI… (check my colleague’s article on ChatGPT in Technical Writing: Risks and Dangers)
• Security incidents
• Force majeure

Have you considered these items as risks before? Have you weighted them up?

A few more risks from personal experience

Some people tend to read theoretical materials and learn from other people's mistakes before springing into their own tasks. Others rely on common sense and personal experience to get rolling with risks (learning-by-doing approach). Either way, you just cannot foresee everything, so some risks, or rather their consequences, may catch you by surprise.

On the projects where I participated as a Technical Writer, the team faced:

• Delays from the client’s side (including agreeing on the budget, granting credentials and approvals)
• Heavy dependence on other team members
• Lack of onboarding materials
• Extra tasks outside of the direct Tech Writing responsibilities
• Unreliable tools and extra time for troubleshooting
• Too many communication channels, environments, and various accounts with various permission levels
• Manual synchronization of the help documentation
• Lack of information in Jira tickets
• Demand to combine old and new UI descriptions in each help document
• Lack of cooperation between the Technical Writers and the Customer Success team

As an example, let me describe my story about delays and dependence. As a final output, we needed to create a Disaster Recovery Plan (DRP). The Tech Writers’ job was to review and polish the material provided by our DevOps and QAs, who, in their turn, waited for clarifications on the deployment pipelines from the client’s internal team. We all had only 3 months to finish up with the DRP, 2 of them the Tech Writers spent waiting… The risk of not meeting the deadline or providing a hasty poor-quality output was very high. Luckily, the team managed to speed up, and the DRP took only 30 pages, so the job was done on time. (But we were totally stressed out.)

Stages of working with Tech Writing risks

Now, that we have visibility of the risks diversity, let’s see what you can do about them. The path to exposing Tech Writing risks on your particular project starts with spending time to acknowledge that the risks do exist.

First, think about what can go wrong and why — what factors can prevent you from delivering consistent documentation on time. This is, basically, the identification stage. Then, analyze the risks found, develop the risks mitigation strategy, and then proceed with constant monitoring. You can use the schema below as a crib note.

Let’s look closer at the trickiest parts of this schema.

Risk matrix (without Neo)

To define which are the greatest risks, you will need to determine the impact and the probability of each risk occurrence.

As an option, you can draw a risk matrix to better visualize the likelihood of occurring and the possible extent of the damage. Actually, this matrix is universal for all industries, not only for Technical Writing. You can find different variations of risk matrixes with various detalization on the Internet. Also, you can find the naming “mild versus wild risks”. I usually use the simplest low-medium-high gradation and thus have 9 squares in the matrix.

Let’s quickly look at how to work with such matrix. For example, your Tech Writer co-pilot, Penny, is planning a maternity leave next month. The probability is high — well, Penny definitely cannot postpone having a baby. The impact is high too — now you will be the only Tech Writer on the project. Thus, this risk is your number one priority to manage.

After drawing the matrix and analyzing all the found risks, document your findings and solutions in a Tech Writing risks document. Then proceed with adopting the risks mitigation strategy together with your teammate Writers and your Project Manager.

Risk response methods

The most common responses to any risk are:

• Avoidance — not participating in activities that may have negative effects. Not doing anything that can provoke the appearance of risks, basically.
• Reduction — attempt to minimize the loss, rather than completely eliminate it. Most commonly used.
• Sharing — the possibility of loss is transferred from one person to a group.
• Transferring — contractually transfer a risk to a third party. This method is rarely used in Technical Writing.
• Acceptance and retention — this stage comes after all the previously described methods have been implemented, and all you have left is to roll with it (as it’s simply impossible to eliminate 100% of the risks).

Risk mitigation strategies from personal experience

The thing is, there is no single correct strategy to set against a risk. There are some best practices and the most obvious choices, but actually, several mitigation options are possible at the same time. And it’s up to you to pick them.

Here are a few examples of the risks and the applied mitigation strategies. As a warmup, you are welcome to think about other strategies possible in these cases.

Risks do exist (always)

A Technical Writer should be fully aware of the risks, document them, and communicate these limitations and assumptions to the Project Manager, the Product Owner, and other people involved in or influenced by the documentation processes.

Risk management is a nonstop process that adapts and changes over time. That’s why constant risk monitoring is needed. And if (when) you find a new risk, go back to the first step — identification, then to analysis and mitigation.

One more time, take a moment to pause and recall. Remember the Murphy’s Law. If nothing bad has happened yet, it means that you were lucky, or you had a cool Tech Writer partner covering your back. It just means that nothing bad has happened, yet…

It is your responsibility, as a Technical Writer, to deal with the risks in Technical Writing. And no one can do it better than you.

True stories (full of pain)

In conclusion, let’s take a look at some more examples based on true painful stories.

To test your skills, you can analyze these stories deeper, distinguish and name the risks properly, and suggest your own mitigation strategies.

Story 1. Sam and Tech Writers not being treated as part of the team

Technical Writer Sam knew that Tech Writing activities should be adapted to the project processes for documentation planning, development, review, release, and maintenance. But what he didn’t know was that there were bi-weekly demo and planning meetings — no one invited him there. Thus, Sam was the last person to find out about the updates in the roadmap and the upcoming app migration to Google Cloud.

Story 2. Sheila and the philosopher’s stone

Sheila has been working with ABC Company for a year. She was writing and updating user guides, creating release notes and in-app what’s new notifications, reviewing the legacy documentation, writing the microcopy. At some point, the ABC Company decided to cut the budget and fire Sheila. Nothing personal, just business. But the client didn’t understand the value that the Tech Writer brought to the project. Within a month, it turned out that ABC Company needed the release notes to pass some kind of external audit. So, the Product Owner and the Director of Products had to write the release notes and what’s new notifications themselves. The Customer Support team now received more requests from the end-users asking to explain new features. And the Developers had to invent names for the buttons and texts for error messages themselves. Just imagine the consistency mishmash afterwards…

Story 3. Richard and …

Richard was leaving a project and needed to handle over the tasks to another Tech Writer. Susan worked on the client’s side and claimed to be a Senior, so it should have been a fast and smooth process. But… It turned out that Susan had no experience in the needed tools and processes, she didn’t update her knowledge and Technical Writing skills for a long time. And Richard had only 1 week to onboard her, show how MadCap Flare works, and handle over the tasks…

Story 4. Marcela and …

Marcela and 4 other Technical Writers published the help documentation online using a virtual machine. According to the internal rules, the backup copy of the help docs had to be done once a week. At some point, an error on the virtual machine occurred, and the Tech Writers had to roll back to the previous version of the help docs. That’s when it turned out that nobody had created backup copies for the last 3 months… The team was afraid to break the news to the client and had to work overtime to manually restore all the changes that had been done within the past 3 months. Eventually, they did it, and the client didn’t find out. But if… the Tech Writers had failed to restore data manually, hadn’t reported the problem, and hadn’t met the deadline… That would have evoked other risks — losing the client due to mistrust and loss of reputation. Since then, the Tech Writers do backup copies every day, storing them both in the cloud and locally.

Story 5. Melisa and …

Melisa was writing API documentation, creating builds and merge requests in GitHub. And the DevOps team was responsible for publishing these API docs to the production environment. Besides, Melisa couldn’t see the final docs view until the DevOps published the docs to production. Due to the different time zones and workload of DevOps, it took up to 2 days to commit changes and publish them. Sometimes the DevOps team just forgot to make the necessary build live, or there were technical issues, so the updated documentation didn’t go to production. Eventually, it was decided to create a pre-release checklist and tag each other in the Jira tickets more often.

Story 6. Caleb and …

Caleb had almost finished creating an onboarding video tutorial, and on Thursday evening, he sent the materials for review. One of the stakeholders, who was in the email copy, suggested implementing “a few minor changes” by Monday. When Caleb read the suggestions, he understood that it was impossible to implement all the changes in 1 day and asked for approval to conduct an estimation of the after-review fixes first. So, Caleb created an estimation table in Excel, where he included the activities, comments, and estimated hours. His total estimation was 2 months… The stakeholder realized that the project must be prolonged, otherwise they would have to give up some of the suggested changes to fit in the initial timeframe.

Well, this is it. Thank you for reading (or at least scrolling) till the end of this article. Use the theory in practice, and you’ll rarely deal with the heavy consequences of risks.

Do you have more examples or want to share your experience?

Hit more risks or mitigation actions in the comments to this article. Let’s take arms against a sea of troubles and, by opposing, get stronger together!