So, you've decided that you really, really need to move to HTML Help, and you've considered what changes you need and want to make and what development tools you need. Your next step is to put together an action plan. You will want to involve a number of parties in your discussions:

• Development: Because they will need to convert their programs to support HTML Help, and they might need to develop scripts for your help files.
• Quality Assurance: Because they will need to test the help files to make sure context-sensitive help, scripts in the help file, and other features work. If your QA department uses automated scripts, they may need to modify them to work with HTML Help.
• Marketing: Yes, them too. They at least need to be aware of the change in case they want to promote it as a feature. You might also want to use graphic elements from their web site and other materials in your HTML help. (Also, a number of marketing departments are also responsible for the corporate web site. So, they might have web developers who can provide you with scripts for the help file.)
   

Of course, you want to get your action plan in writing with your estimated schedules and costs. So what if no one else in your company does written plans, and any similarity between the marketing requirements document and the final product is purely coincidental? Remember that in spite of all the HTML coding and context-sensitive help debugging you do, you are a writer, damnit. You live for putting nebulous thoughts into concrete words.

So, here are elements to put into your action plan.

• Your business case for switching to HTML Help. Because of the amount of effort that will be needed by various departments and the risk potential, you need to give a solid reason for making the change and show the benefits.
• Changes that will be made to the help system. Detail all the changes that will be made in the transition, from how context-sensitive help is implemented to what the HTML Help user interface looks like. (There are a lot of people who have not seen HTML Help or noticed that it works differently from WinHelp.)
• Tools and training. If the change requires you to get new tools (like graphics tools or a new or upgraded help authoring tool), you need to indicate what you need, why, and what training you and members of the documentation team need to use the new tools.
• Development plan. Fire up that copy of Microsoft Project that you never use and put together some estimates on time and schedule. Include time for potential problems. Even if you have done your homework, you will always encounter some difficulty once you start working with actual projects.
• Include a fallback plan. Can you get back to WinHelp if a problem prevents a switch to HTML Help (such as the developers cannot convert the code in time, or if scripts you need are not available)? With ForeHelp, you can switch back to WinHelp by changing modes and recompiling. RoboHelp enables you to import your HTML Help project back into RoboHelp Classic to develop as WinHelp.
   

Good luck, and happy help authoring!