Planning in a Technical Documentation project

-

    In any project, success depends on good planning and execution. It takes diligent planning and execution to make a Technical Documentation project successful. We have a lessor error margin because we have less staff, less representation in senior management, and hence lesser bargaining power. Any failure in planning and execution will look glaring, and surely no one wants to put oneself in an odd situation.

Success in both planning and execution depends on asking the right questions at the right time. Ask questions regarding what is in the project scope and why. Planning is not a single step. It goes in parallel with execution. Ask who the key stakeholders are, the mandatory deliverables, and the intended recipients. 

Gather all possible reference material and also check the relevance of the reference material. Develop the document structure and get it reviewed. Be more formal with stakeholders outside of your team. Identify the process to follow and arrive at a common ground. Just jumping into the task without doing the groundwork can get you into trouble with less cooperative stakeholders. Brace yourself into this reality.

Reserve some time for new ideas and innovations. Coordinate as often as possible if multiple Technical Writers work on the same project. Allow space for the other member. It is not required to control anyone, and we need to coordinate. Allow people their working style, but sensitize your members that your's is among the most unforgiving jobs. The credibility of a Technical Writer can erode because of a single avoidable mistake.

Don't wait till the people become interested in the documentation deliverables. Get started as early as possible and work consistently. Revisit the documents every day till you have them in shape. Beware of scope creep as it happens very often and make provisions for the same. Do not rely on the heroics of working late nights when the project deadline is approaching. You may end up introducing more errors in your documents in such a scenario.

Remembers that quality has to be intrinsic and built-in and can't be imposed externally except for the conformance checks, and it applies equally well for Technical Documentation.

Do good quality work even if it takes longer. For example, you feel that a document must use a new template to look good and comply with industry standards. Write to the product stakeholders to get buy-in for the same. Let them know that you may take a little longer because of this.

Track the industry trends and continually explore the ways to do things better. Documentation must be integrated with the product itself if possible. Try to make your documents online and accessible. Make a clear distinction between the documents that must go for print to ship with equipment and other information published online and the documents such as README that goes with the product. The documents that go for print or ship with the product have zero tolerance for error. Put best trained Technical Writers in charge of such deliverables.

Try to solicit participation from everyone. People who have added or tested a new feature or addressed customer queries can contribute Knowledge Base articles.

Do not allow any scope for surprises. Maintain a physical or online status wall and regularly communicate the project status. Do diligent follow-up. Maintain correct match between expectations and outcomes.

Communicate well, and that is the core of our job.

The title image is borrowed from an unknown internet source

Related articles:

The ability to learn is the key to survival. We can learn faster by learning from each other.

Comments

Post a Comment

Popular posts from this blog

YAML front matter in Typora

-
Image
     I was looking for ways to add a cover page, header, and footer in Markdown and just figured out how we do it in Typora Markdown editor. It is easy. Set the header and footer using YAML Front Matter. The YAML front matter must be the first thing in the file and must be valid YAML, set between triple-dashed lines.  Source: https://support.typora.io/ The following is an example for setting the document title, header, and footer using YAML: --- title: Agile Technical Documentation header: A Quick Guide for Agile Technical Documentation footer: ${pageNo} --- Apart from this, you need to make a few PDF export settings. Select File > Preferences > Export > PDF and select the checkbox for Read and overwrite export settings from YAMAL front matters . Now, the document exported into PDF will have A Quick Guide for Agile Technical Documentation in its header and page number in its footer. If you need a cover page as well for the PDF export, paste the following content in the Ap
Read more

Technical Writing essentials

-
Image
     I want to share some of my learnings starting from the beginning days of my Technical Writing career. Everyone in the project must have a cursory understanding of the following, and the Technical Writer must understand it in detail: Language standards Learn the style guides. MSTP (Microsoft Manual of Style - currently called Microsoft Style Guide) is among the most widely followed style guides. You can access it online for free and even download the PDF for offline reference. See https://docs.microsoft.com/en-us/style-guide/welcome/ There are several other style guides, but it is mostly enough to refer only to Microsoft Style Guide. The following are some of the key takeaways: Avoid passive voice - sentences in passive voice are generally longer and harder to read. Use only the simple and easy words understood by the global audience with varying degrees of English knowledge. Your writing must have the same meaning for all people from different geographies and cultures. Never use a
Read more

Apply Goldilocks principle

-
Image
     There is one thing universal about successful managers. They keep increasing the performance benchmark every time. It applies to an athletic coach who wants to make his trainee globally competitive. I have worked under cruelly kind managers who are very ruthless in getting the tasks done. They push you to improve your competency and skills every day. You may have had a tough time working under this manager, and still, it is not something to be resented. Weathers the pressures work? We start looking for ways to do things better when the competitive edge is so narrow, and even a marginal improvement in something will give you an edge over your competitors. I had my dilemmas over if harsh managers are good or bad. A good manager sets difficult but attainable benchmarks and allows members to execute tasks with relative autonomy. There is no use flogging a dead horse. Spend time grooming the people who are motivated to do their best. I have spent time with people who do not have enough
Read more