How long does it take to go over to DITA?
Blog entry: Submitted by bonbayel on Wed, 2006-06-07 16:29. Last updated on Wed, 2006-06-07 18:04.
The irondog1970 poses a very interesting issue "I imagine a transition from our current writing style to a DITA-based system would take 2 years. And that's a minimum" in Now reading up, that I hope others will respond to.
The following scenario is based on the conditions at a job I just quit, where we kept getting waylaid with other projects, keeping me from having time to analyze legacy material for DITA. My knowledge of the company is up to about 3 weeks ago when I left in frustration - and also because of the commute. But I would like to be ready if another opportunity arises. And their writers may actually see your answers as well.
Given
- Legacy documentation of one 500-page manual and about 6 shorter manuals (up to 100 pages), all of which have versions for 2-3 products or customer groups
- The company wants the 500-page manual completely redone with the next complete revision of the software in October.
- All of these manuals are in Unstructured Frame and converted to PDF for printing and online publishing, as well as some to Help with WWP.
- The docs department consists of one, maybe 2, writers and a SME/writer-wanna-be with no present expertise in XML (but there are developers using XML in the product)
- How quickly can the new manual be set-up and written in DITA?
- Is it possible in this time-frame, with the help of consultants, to get the templates set up so the writers can do the writing?
- How large a department would normally be doing this sort of work, with a new major revision at least annually?
- What categories of writers/editors/developers/designers... would be typical for this department?
- What sort of content-management system should be used? Specific examples would be appreciated.
- Which tools are already in place (or will be, more or less bug-free by October) to do the conversions to PDFand Help, using the company's custom styles?
- bonbayel's blog
- Login to post comments
- 12780 reads
Search
Recent Content
- Forum for DITA Users
34 weeks ago - Publishing for DITA
5 years ago - Optimizing the DITA Authoring Experience — Online Course
5 years ago - Linking to another chunked topic
5 years ago - Advanced Reuse Strategies — Online Course
5 years ago - 2019 Content Management Strategies/DITA North America Conference
5 years ago
Subscribe
Navigation
Currently online: 3 guests and 0 users:
Rapid migration to DITA
My background consists of twenty years of work for systems integrators and software vendors of content/document management and publishing solutions. The biggest frustration I consistently dealt with was the painful, time-consuming, and expensive process to migrate to these new environments. So, we (DocZone) created a rapid implementation approach to help clients move into a production environment in 30 days, including conversion of legacy content (e.g., unstructured FrameMaker, Word, etc.) into DITA or other XML content models.
So, the short answer to your first two questions is: your timeframe is achievable working with us. With most of the "traditional" product vendors, your schedule is likely to be too aggressive. In my experience, most implementations that involved migrating to an XML-based production environment took 12-18 months.
As for the remaining questions:
3. How large a department? I don't think there is a "typical" scenario. I've seen everything from global organizations with one tech writer editing documents authored by engineers to large tech writing staffs of 20-50 writers per product line, belonging to techdoc/training organizations numbering in the hundreds! On the average, I'd say tech writing staffs usually are between 8-20 people.
4. In my experience, I have typically seen a 5:1 ratio of writers to editors, with a separate department for designers.
5. There are lots of good systems out there besides DocZone (Vasont, Content@, Documentum, Docato) and some not so good ones (I won't name them, but they are noticeably absent from my previous list!). I, of course, think DocZone is the best one, primarily because we also include authoring, translation memory, and publishing as part of the package, and we make it available as a hosted solution...so it is more affordable and requires only a browser.
6. Conversion tools will only get you so far, and are usually more trouble than they are worth because of the cleanup time afterwards. I would only recommend using conversion tools if the source content is reasonably well structured (rigorous adherence to templates). Otherwise, you will have to do a lot of cleanup. There are lots of choices of good conversion vendors who will do this for you very inexpensively with guaranteed turnaround times and quality levels. Believe me, your time is more valuable!!!
I hope this was helpful. I tried not to make it sound too much like a commercial. ;-)
-Dan