B Y   D O R T E    J A C O B S E N

Founded in 1983, Damgaard is one of the leading software vendors of integrated enterprise solutions for the small and medium enterprise markets with more than 60,000 installations worldwide. Damgaard’s products are sold through a global re-seller network of more than 500 authorized Business Partners.

Damgaard, headquartered in Denmark, operates with more than 450 employees in 11 subsidiaries throughout Europe, the U.S., and Asia Pacific.

The Development division at Damgaard has 120 employees that work with all aspects of software development, from concept and design, to development, quality assurance, and user education. The growth in the number of employees has been almost explosive! During the period of growth, it became increasingly clear that the traditional project structure with a development department that did all the development, and only development, and a quality assurance department that did "all the rest" including testing, documentation, and setup programs, simply did not work. Invisible brick walls existed between the departments, and communication left a lot to be desired. In particular, the documentation - and the documentation people - suffered from this.

About 18 months ago, we introduced a new project and working structure in the Damgaard Development division called Microsoft Solutions Framework. As the term suggests, Microsoft Solutions Framework (MSF) was developed by Microsoft. MSF is the way Microsoft manages their software projects. The two major concepts behind MSF are the team model and the process model.

The team model is comprised of six clearly defined roles:

• Development
• Testing
• Logistics
• User education
• Product management
• Program management

It is essential that all team members have equal say and equal responsibility for shipping a quality product. There is no project manager in the traditional sense, and each member has his or her specific focus and mission on the team.

The teams are situated in the same, or adjoining offices, something that has proven very beneficial to communication, and team spirit.

The User Education role comprises more than "just" documentation. The User Education person is an integral part of the entire development phase from envisioning what is going to be in a new product or release, through designing the user interface, planning delivery dates, and, of course, writing all types of documentation. In short, User Education serves as the user’s advocate on the team, and produces user assistance whenever needed.

The User Education group consists of 20 people that perform a variety of tasks:

• Writing documentation for integrated enterprise solution end users
• Writing documentation for integrated enterprise solution developers
• Writing setup and update information
• Writing newsletters
• Performing edits
• Managing translation of the user interface
• Managing translation of the documentation
• Taking screen shots
• Participating in user interface design
• Managing development of course materials

The writing group forms the majority (about 70%) of the User Education group.

One of our primary markets is the USA, and new products are released for the American market first. This means that the user interface is initially developed in English, and that all documentation is written in English. Only one of the writers is American, so to the majority of the group, writing in a non-native language poses a linguistic and a stylistic challenge. To ensure the quality of the documentation with respect to both content and language, there is an established review process in which documents go through edits by SMEs (Subject Matter Experts), as well as an American editor.

We ship various types of user assistance with our software:

• Context sensitive help, available when the user presses F1
• Online help, available from the software’s Help menu
• Setup and update information
• Newsletters
• Printed manuals
• Technical information and white papers, typically for the system administrator.

It was our finding that one tool could not meet all demands for Help so, we have chosen to use several different tools.

Integrated viewer and editor for context-sensitive online help

Our product is highly customizable. In the vast majority of our installations, the standard system has in fact been modified by the re-seller to suit the exact needs of the company. The high degree of customizability poses a special Help challenge. When a dialog is modified to display additional information, the Help information for that dialog must be modified as well. As a result, partners who make customer-specific Damgaard solutions must have easy and user-friendly access to modifying the standard Help information supplied with the system.

To meet this challenge, the system has a built-in third-party HTML editor, and viewer. The editor is used in-house to write the standard Help information. It is also shipped with the system to enable partners to add their own Help.

Another User Education challenge is that Help information must be available in eight languages (Australian, Danish, Dutch, English (UK), German, Norwegian, Spanish, Swedish). The translation management and version control is handled by an auxiliary database tool known as the DocTool. This database tool is developed and maintained in-house.

RoboHELP for online help

Online help files that users should not be able to edit are shipped as WinHelp or compiled HTML Help files. Such files include a Setup Guide, a Readme file, What’s New in this release information, and a Developer’s Guide. To conform with the latest help system industry standards, we are currently in a transition phase from shipping WinHelp files to shipping HTML Help files. These files are shipped in English only, so translation is not an issue here.

FrameMaker for manuals

For traditional materials, like a User’s Guide, and a Getting Started Guide, we use FrameMaker and ship the manuals as .PDF files. Like the online help files, the FrameMaker files are written in English and translated into seven other languages.

The manuals are available as printed books, but they are supplied as .PDF files on the product CD. The idea is that users can browse the files with Adobe Acrobat Reader or print the books themselves.

Word for technical information

Some technical information (such as database setup and various white papers) we write in Microsoft Word. In the future, these documents may be distributed in HTML as well. Technical information is shipped in English only.

Within the Danish software community, there is a pronounced change in the way documentation and writers are considered. It is changing from "documentation is something anyone can do, and something we’ll do if we find the time in the course of the project," to considering technical writing a craft, and user assistance a vital and integral part of a software product. Useful user assistance is being seen as a competitive parameter. In Damgaard, this is clearly reflected in the number of User Education employees hired through the past two years.

In Denmark, as in almost all European countries today, there is a general staff shortage within the IT-industry and it is difficult to attract qualified staff. Hiring new User Education employees has not been an easy task and often has required assistance from recruitment agencies.

Within Damgaard, as within many IT-companies today, there is a general trend towards more flexibility and individual working hours. This does not mean fewer working hours, but it does mean that you can, for example, work from home occasionally. In Damgaard Development, all employees have recently had home PCs and ISDN (Integrated Services Digital Network) connections installed. Each employee can then arrange with his or her manager to work from home occasionally.

Fall 1999
Volume 2, # 4