Sample strategy recommendation reports

Jump to –

• Demo scenario 1 –
  Established heavy industry client requests an internal process documentation and training strategy
• Demo scenario 2 –
  New enterprise software company requests a client-facing technical documentation strategy

IMPORTANT
In practice, your recommendation report arrives to you as a formatted PDF and is likely be several pages long to provide comprehensive and accurate recommendations.

The abbreviated samples below are to demonstrate the type of content that you'll receive.

Demo scenario 1 –
Established heavy industry client requests an internal process documentation and training strategy

Overview –

• TestCo states that shop workers are not enthusiastic to receive additional training or to use current internal process documentation.
• Most workers feel that current material is unrealistic and does not apply to the real world. According to a worker that I interviewed, the current material is "pretty obviously written by somebody who's never done the work."
• Management and executives understand the disconnect, but feel strongly that the current style, coverage, and depth are required to uphold regulatory body requirements and to create and maintain a corporate safety culture.

Content and process recommendations (summary) –

• Slice training content and process instructions into much smaller, more digestible chunks.
• Reduce wordiness in all training and process documentation. Use shorter sentences and paragraphs to reduce the "wall of text" appearance.
• To disguise the dry nature of the material, switch to a friendly, casual voice that's less stodgy and corporate.
• Include shop workers in the content development process for both training and process instructions to develop material that is more applicable in the real world.
• Include shop workers in the document review process to ensure that draft documents capture the true intent, and be prepared to make meaningful changes based on worker reviews.
• Switch to a graphical training document model using PowerPoint slides (or perhaps video clips) from the current text-based model. I strongly recommend avoiding any patronizing "cute" graphics or animations for this type of audience.
• When possible without compromising safety or compliance, avoid extremely specific process instructions or training points to allow workers some freedom to find efficiencies on the job or to learn from each other.
• Provide a mechanism for workers to submit changes to the instructions or training, and be prepared to modify documents quickly when required to incorporate useful changes.
• To demonstrate TestCo's sincerity about valuing worker input, add a contact email address or phone number at the bottom of each document to allow readers to submit changes without having to hunt through a company directory for the correct recipient.

Content and process recommendations (detailed) –

NOTE
In a real report, this section provides additional detail for the items in the summary section, including specific, contextual examples to illustrate recommendations.

Documentation development software recommendations –

• TestCo does not immediately intend to hire any dedicated technical writers, but does intend to hire a relatively junior writer at some point in the future. With that in mind, I recommend using Microsoft Word to redevelop process instructions and Microsoft PowerPoint to redevelop training material.
  
  Neither of the Microsoft products is an ideal choice for technical documentation, but both are well-understood by virtually any office worker who will develop documentation in the present and by any junior technical writer that TestCo hires in the future.

Documentation storage and access recommendations –

• TestCo currently provides computer terminals and tablets to shop workers for accessing vendor documents. So, I recommend posting process instructions and training material on TestCo's intranet to allow convenient remote access on the shop terminals and tablets, and to avoid requiring shop workers to download and print documents in the office.
• Remote access to training documents also reduces the resentment that some field workers have for bureaucratic tasks that distract from "real work."
• With easy access in mind, I recommend organizing process and training documents under topical headings on TestCo's intranet to avoid requiring workers to scroll through dozens or hundreds of uncategorized documents to find the right one.

Document update frequency recommendations –

• I recommend updating the process instruction and training documents only when necessary, at least until TestCo has improved the workers' relationship with documentation. Many field workers find procedural document changes to be quite frustrating, especially soon after learning the previous process iteration. In this case, where there's an existing reluctance to use documentation, I recommend allowing workers to absorb the improvements to the overall documentation development process and the result before expecting enthusiasm.
• When process or training document changes are required, I strongly recommend making the changes clear in a prominent What's New section within the document. Again, TestCo will benefit from allowing workers to gain trust in the documentation and from demonstrating that the workers' concerns are heard and are being addressed, while still providing a depth and coverage of documentation that the company feels necessary.

Overview –

• TestCo is developing an enterprise software package. The package is moderately complex and the user interface (UI) is not very intuitive by design.
• The software package is largely feature-complete, but UI element changes and minor to moderate functional changes are still happening frequently due to beta tester recommendations and requests.
• TestCo is currently mid-way through the beta software phase and wants documentation ready for the full product release in approximately three months.
• Staff developers have produced some unofficial documentation during the development process. The current documentation is high-level and inconsistent, has not been a priority, and is mostly useful as a starting point for official documentation.
• TestCo intends to hire an experienced technical writer as soon as possible and will hire a trainer to travel to client sites.
• TestCo wants both a detailed reference guide and a higher-level illustrated user's guide to be prepared in time to act as a basis for a PowerPoint presentation that the trainer will produce for onsite client training soon after product release.
• Based on my experience with the beta product and discussions with stakeholders, I estimate that the reference and user's guide manuals will be no less than 300 pages combined.

Content and process recommendations (summary) –

• Based on the current state of progress, I suggest that TestCo's planned documentation timeline is not realistic.
  
  Recruiting, hiring, onboarding, and familiarizing an experienced writer, producing a large volume of documentation for a product that is still evolving, and assigning resources to review all produced content for accuracy and adherence to the company's look-and-feel desires in 90 days is very unlikely to be successful.
• I recommend that TestCo consider a more basic initial documentation strategy that can become detailed as the product stabilizes.
• I recommend that TestCo use a recruitment agency to locate an experienced contract technical writer.
  
  Agencies have existing relationships with qualified workers to speed the process, and contactors are accustomed to moving between clients and projects more freqently than employees. As a result, contractors tend to become productive faster in a new setting, in addition to the reduced amount of onboarding required for a contract worker.
• I recommend directing the writer to produce training material first to allow the contractor to become familiar with the product and for stakeholders to become accustomed to the review process before starting larger, detailed documentation.
  
  In addition, PowerPoint slides are much easier and quicker to update to match an evolving product than manuals that might contain large volumes of text and screen captures that become obsolete with every change.
• After the training material is completed, I recommend proceeding to a high-level basic user's guide with sufficient instructions to get a reader off the ground.
  
  My experience has repeatedly shown that evolving beta software does not lend well to detailed usage instructions or screen captures, and inaccuracies due to product changes are almost certain to be missed during a review process that runs alongside a hectic initial release schedule.
  
  Inaccurate documentation is worse than no documentation, especially for an initial release with no ad-hoc product experience available.
• When the product reaches a stable release stage, I recommend directing the writer to increase the level of detail in a next version of the user's guide and to begin work on the reference manual.
• If TestCo intends to release frequent product patches or updates soon after the initial release, I recommend directing the writer to produce release notes or what's new documents to allow customers to track changes until the larger manuals are available.

Documentation development software recommendations –

• TestCo has chosen to use PowerPoint to create training material.
• Considering TestCo's intent to keep an experienced technical writer on staff even after the initial documentation is complete, I recommend Adobe FrameMaker as the documentation development platform. Despite FrameMaker's steep learning curve, it's a suitable product for large and small technical documentation and is well-understood by most experienced writers.
  
  Unlike Microsoft Word or most any other word processing software, FrameMaker is very stable when producing large, complex manuals as per TestCo's goals.

Documentation storage and access recommendations –

• If TestCo accepts my recommendation to use Adobe FrameMaker as the documentation development platform, only personnel with access to a FrameMaker license and the required knowledge can make changes. So, there's no need to sequester the documentation from unnecessary personnel.
• If TestCo opts to use a more commonly-understood software package to produce documentation, like Microsoft Word, then I strongly recommend allowing access to only required stakeholders.
  
  My experience has shown that new software companies without established documentation change management processes tend to struggle with keeping too many chefs out of the kitchen, and various tangental stakeholders often feel empowered to make impromptu changes that inevitably compromise consistency and quality.

Document update frequency recommendations –

• I recommend releasing small documents (release notes, what's new, etc) and large document revisions very frequently with a new software product to provided needed instructions and to develop a positive corporate reputation for timeliness and attention to detail.

Technical writer candidate profile –

• The candidate must be fairly experienced. I recommend no less than 5 to 7 years. In this scenario, assertiveness is more important than years.
• The candidate must have experience with startup enterprise software companies.
• If TestCo accepts my development software recommendation, the candidate must have considerable experience using Adobe FrameMaker to produce large manuals.
• The candidate must be an autonomous, high-volume producer who gets rolling quickly and with minimal training.
• The candidate must be assertive when interviewing subject matter resources.
• The candidate should have experience developing and managing document review processes.
• The candidate should have UI and UX writing exprience.
• The candidate must be willing to defend technical documentation's value in the software development process. Quiet, reserved technical writers do not often flourish in startup software companies.

| Previous page | To the top |