Top Challenges Faced By Technical Communicators at Work

Recently I asked the members of Technical Writers India (TWI) listserv about challenges they continually face at work. The whole point was to understand about the pain areas and derive some workable solutions to meet those challenges. The results were startling to say the least. 

1. Inability to separate content from information

One of the members complained how difficult it was for him to obtain content from engineers. The problem, in my opinion, lies somewhere else. Technical communicators should learn how to separate content from information. In words of Bill Swallow, HATT and WWP-Users List Owner and a senior STC member for the TechValley Chapter, "the two are quite different." I could not agree more.

As professional technical communicators, first understand what is it you are trying to gather from the engineers – is it content or information? Be specific. Content is a vast term. It can imply design documents or first draft written by engineers. You do not seek content; the stakeholders are responsible to provide you with relevant documents from time to time. You seek information from engineers to resolve your issues about the product workflow or behavior.

2. Untimely or no inputs from the Subject Matter Experts (SMEs) or Developers

Neela Thiagarajan, a technical writer with Cognizant, laments, "Getting inputs from the SMEs/Developers is one of the biggest challenges I face. Most of the time they are busy and it is difficult to find time to get inputs from them." 

To this, Bill says, "I approach this with options. They can either give me detailed specifications to work from (coupled with excellent use cases and user profiles from product managers - another wrinkle) and I can limit the amount of time I spend "bothering" them, or they will see my happy face as often as it takes to get the information needed for the documentation." 

I concur with Bill completely. SMEs are hard-pressed for time; this is not to say that technical communicators have all the time in the world. However, for them to take us seriously, we have to ensure that the groundwork is done. If the design documents are incomplete, or lacking necessary information, press the panic button immediately.

You can befriend the developers or quality assurance professionals in your team over a cup of tea, and inform them about the bottlenecks. Tell them upfront that any missing information would seriously reflect on your final output. More often than not, they will be ready to help or at least tell you whom to contact about such problems. 

Vasudha J Singh, documentation manager at CSC, Indore, adds, "I thought I’d provide you a solution that worked for me and my team. The most common problem I have often heard and faced is getting SMEs to give you inputs. 

Technical documentation is growing at a slow and a steady pace and will soon not be a niche domain anymore. You should actually advertise yourself and speak about the contribution you have made. Many process-driven companies now lay a lot of emphasis on technical documentation, as a software product cannot be deemed complete unless it is accompanied by relevant user documentation. 

What I try to do is as soon as I get the high-level project release schedule, I try to identify the list of deliverables that will have to be released along with the product. Most of the project schedules I have come across do not really talk about documentation milestones. You should try to fit your documentation schedule somewhere in between the development and testing milestones. If possible, sit with the development and testing leads/managers and give them dates by which you can submit your deliverables for review. This will help the development and testing teams to develop their low-level project schedule and they would have budgeted some time for helping the documentation team with inputs/review comments. This would apply to you too. Your documentation project schedule should contain the dates by which your documents should reach the SMEs and come back to you. Getting documentation work listed as a deliverable in the development/testing project schedule is one of the best ways to ensure that SMEs take time out to help the documentation team. 

One important thing to keep in mind is to do your homework. Play with the product, read the specifications, and try to create a draft to show the SME before you actually ask an ocean of questions. SMEs are to give inputs, they are not meant to write documents for you." 

3. Getting a clear answer from management about just what it is they want

Guy Haas, a member of the Silicon Valley, San Francisco, Trans Alpine, and India chapters of STC, feels that this is a serious challenge for technical communicators. He adds, "Getting useful information from product management (and/or product marketing) about where the product is headed. Sometimes, it is very helpful to know what the expansion plans are, so that you are not doing something in release 1.0 that will need to be totally scrapped and redone in release 2.0 (or even 1.5)." 

This information is hard to get due to the changing market conditions. In fact, developers themselves are not sure if the end user requirements mentioned in the System Requirements Specification (SRS) will remain the same until the last minute. 

Judith Herr, an STC Associate Fellow, opines, "We’re gaining more respect, so now we’re being given more responsibility and decision-making authority. A good place to be – but, how do we get it all done? How do we get the key senior managers to provide us more resources – tools and staff?" According to Bill, the answer to these two questions lies in acquiring project management skills and job knowledge. He believes a business plan driven by need-based metrics can do the trick. 

4. Getting people to review your work for content

This happens to be one of the biggest challenges, especially if you are the lone writer in your team or organization. According to Bill, "That can be a tough one. I try to be as clear as possible about what I need from a review, and when I get anything other than what I asked for, I thank them for their input, tell them that their suggestions and comments will be taken into consideration, and I re-send them the document again outlining what I’m looking for from them. It can take a few cycles but eventually they get the hint (and if you make good on reviewing their other feedback and incorporating what makes sense, they appreciate that as well)." 

I would like to add on to this. If you wrote something but no one ever reviews it, chances are the inadequacies in your writing will go unnoticed. This can pose a problem later when some client or customer points them out to your organization. It will not only jeopardize your credibility as a writer, but also reflect badly on your work. My suggestion for this is to buy some time from the stakeholders. Tell them the importance of a review and what you expect them to look at. 

Neela feels, "Getting review comments from the SME or Developers can be frustrating at times. Often we need to keep following up with them for their review comments after sending a document for review." Mugdha Kulkarni, another technical writer working with S P Software Technologies (I) Pvt. Ltd. in Pune, adds, "Enough time is not given to reviews. SMEs do not perform the technical reviews with complete ownership (loopholes remain even after their review). Review comments are some times biased. Review comments only point at the problem, solution is not clear."

Bill has an excellent solution for this. He says, "Automate the process and allocate their time to review in the project schedule. This builds visible accountability for their reviews." 

5. Writing a document with little information about the Product/Process/Project

This is a precarious situation if you would have asked me. It is always a good practice to meet the product managers or stakeholders should such a condition arise. Make them understand that insufficient information will put you out of business very soon. As technical communicators, we are supposed to provide the complete functionality for our end users. We must document facts as they are. We will not be doing any justice either to the end users or to ourselves by providing incomplete facts. 

6. Less importance given to documentation

Neela believes, "The false idea that is prevalent in the industry is that technical writing is not as important as development and testing." Mugdha holds the same opinion when she says, "We are not involved when the project scope is defined. Instructions are some times vague. Effort estimates are negotiated."

People are open about their opinions. The same people will change their opinions once the profession starts gaining credibility in India. In many organizations where technical writers are employed today, writing is seen as a strategic business function. Making our presence felt requires that we must work harder towards transforming the profession itself into a core business function. It is our responsibility to educate product stakeholders about the importance of hiring technical communicators. 

Bill does not feel that the problem is as much of a war. He says, "This is all on us to fix. As with all the comments above, most people perceive writers as customers of development. You need to break this cycle and add value at the beginning of a project through to the end. How you do this varies from group to group, but once you size up the organization you can usually see where you need to inject yourself and how to do so. I’ve not had a problem with regard to changing this perception." 

7. Lack of clarity among the software professionals about the role of technical writers

Neela feels that since there is no clear roadmap defined for technical communicators, they end up getting all sorts of odd jobs. According to her, there might not be defined jobs for some technical writers.

Anand Kumar, a technical writer working in Bangalore, wrote, "The senior management in my company visits the Bangalore branch every three months, but they just tend to ignore the TechPub division, all the other divisions are worth enough to be given a visit but not TechPub.

I do not know whether this happens elsewhere, but this is a visible attitude I find towards technical writers. However, I can say that I am proud to be a technical writer and am immensely satisfied with my job."

Bill begs to differ on this. "If your role is ill defined, then define it, and deliver value beyond their expectation," he says.

It is interesting to see that technical communicators all around the world share the same sentiments about the challenges that surround them. In my concluding part of this article, I will summarize the remaining three challenges that continue to be discussed on the listserv. I would like to conclude this part quoting Mugdha Kulkarni, "I believe you can make such problems vanish by being a good professional (by being disciplined, transparent, proactive and excellent in your work)."