More in the series: Choosing a Tool
For many years, I have worked with hi-tech companies, creating their documentation and/or online help using a variety of industry-standard tools. In recent weeks, two companies have asked me to help evaluate their current and expected future needs to
determine the best tool for them.
Once we had defined the company’s current status and requirements, it was time to define the potential solutions. In some cases, listing a tool was a political decision. I needed to list it in order to dismiss it with an explanation that even though someone within the company was recommending it, it wasn’t an optimal solution. In other cases, options were listed and then further explored during the recommendation stage. During that stage, some of the potential solutions that I had considered proved less than optimal.
The ability to include review cycles by non-writers was critical to both companies. This became one of the deciding factors that helped us rule out some solutions. Another factor was the flexibility of the output – if the solution didn’t provide the ability to expand later deliverables to include documentation on mobile devices, again, it was eliminated as an optimal solution.
I have to admit that this phase (defining the options) and the recommendation phase were extremely helpful to me, as well as to the company. In some cases, I took the time to experiment with the latest versions of the software, consult with the development teams and explore the real capabilities of various applications on the actual documents that would be converted to a new authoring environment.
In one case, I had a good idea what I would recommend to the company. In the second case, in defining the options as they related to the specified requirements, my final recommendation took shape.
I had reasons for including each option (and for not including others). When we do this for a company, we include these explanations but to save space (and the privacy of our clients), I’m listing the options without the reasons why/how we determined this list.
Options for Company A:
- RoboHelp
- Doc2Help
- Flare
Options for Company B:
- Doc2Help
- Word and SmartDocs (limitation for html-based output)
- Flare
- AuthorIT
- LaTeX
- FrameMaker (limitations explained)
- RoboHelp
Though it was clear from the start that the final decision would be made by the company (the management for Company A; the product manager and the management for Company B), the next step requested by both companies was for me to present them with my single recommendation and an explanation as to why I’d come to that conclusion. There was also a detailed section in the presentation in which we explained all of the associated costs for each option, which was also considered a factor in our final recommendation.
(Here’s where I’ll mention that WritePoint is a recognized Adobe reseller and a MadCap partner. We sell Component One software and represent SmartDocs in Israel – in short – we consider ourselves vendor-neutral, turn-key documentation facilitators. We analyze your needs, recommend solutions, help you determine the best one, offer the best prices (usually) and then help you convert your legacy documentation and/or train you how to continue documenting/converting to new formats on your own.
I’ll also mention that in at least one case, the optimal solution for the company would have been DITA, but they were not open to this suggestion and so it was not included in the above lists. Their concern was bringing all the contributors on board the DITA concept and it was decided that they were unlikely to get managerial approval for this undertaking.
To continue the series, see Choosing a Tool – Recommending the Solution  (Part 6) – coming soon…