Structured Authroing: Enterprise Acceptance, Education, and PM?

Question

After some unusual experiences with a recent structured FM project, I wanted to turn to a community of peers to learn if others have experienced similar situations and what advice you might offer, if you have. Here is the background of the situation:
I was hired by a high-tech company to update a techincal manual almost two years ago. The company had about 6 to 10 very long internal engineering and customer-facing documents, almost all of which had been managed with LaTex for years. In an attempt to improve their documentation process, their former graphic designer/technical writer had migrated the documentation for their flagship product to InDesign. That decision wasn't too practical, as it was a 200+ page hardware and software user guide for a telecom device, something not well suited for a layout program. After taking care of their short-term needs with updates in ID, I explained the benefits of structured authoring to the project supervisor and subsequently my contract was extended to migrate all of their documentation to structured FM. This process went extremely well, largely because I was given a great deal of autonomy due to my experience in such projects.I wrote a custom EDD and templates that could be applied to all documentation and successfully migrated their legacy documents.
After that phase of the project ended, though, I found it very hard to properly manage their documentation needs, largely because of their ignorance and unwillingness to understand some of the basic needs related to structured authoring. I had made a concerted effort to educate them about structured FM all throughtout the migration, but my overworked supervisor considered my detailed reports as "too much information." Somewhere along the way, I believe she came to think of structured FM as a magic bullet of some sort and my explanations became misinterpreted as some sort of waffling, incompetence, or an attempt to pad hours. Really what my requests consisted of were nothing more than a development cycle that preceeded editing, a period that would allow me to manage any EDD work. It should be noted that the document in question was updated in parallel with a software release schedule of approximately 6 months and the management of this document alone was a full-time job for my predecessor. I reduced this process to a cycle of approximately 2 to 4 months per year, largely through the benefits of structured authoring that I don't need to detail here. Problems really began occurring when sales people and management started requesting last-minute, wholesale changes to the documents only weeks before deadlines, changes which required significant changes to the EDD. In my last deadline I received 200 marked-up pages of graphic and content changes two weeks before deadline while I was finalizing release notes and last-minute work. To get these changes done, I ramrodded them through and destroyed the structure of the documents and then had to go back and fix them thereafter. More specifically, I requested two weeks to rewrite the EDD and reauthor the 200+ page document and was confronted with increduility that it could takes so long -- and it was demanded that I complete it in a matter of days. I was actually told to make the "structure" of the document simpler, because "it's just a simple XML file after all" This company obviously had larger problems with their production processes and I was given no authority to change them, but I still find it difficult to grasp what I came up against in terms of acceptance, education, and management realted to structured management project requirements, especially when I explained it in such clear terms.
Certainly I would like to hear from anyone who cares to comment on the details of my experience. But more universally, I wonder if such obstacles are commonplace in your experience -- this was the first time I have come up against them. Also, when it comes to project estimation related to writing EDDs and doing development work, could you share your methodologies for coming up with timelines?
Thanks in advance,
Douglas

Answer 1

Just these brief insights into your own experiences have confirmed to me that I managed the work properly and the issue had everything to do with shortcomings in processes and a lack of understanding regarding structured FM.
I used to work as an editor at an IT trade publication and no matter what enterprise technology I was covering, the experts/vendors in the field who discussed IT implementations for varying companies would always underscore how the success of a project hinged upon the client's understanding and participation in that implementation. I think that adopting structured FM is no different in that regard. Moreover, if a lot of FM users have trouble wrapping their head around the concept of structured authoring and it takes years for a FM developer to really build serious chops, it only stands to reason that someone whose depth of experience with publishing is MS Word will probably have trouble digesting the big picture. Also worth noting is that, at least in my case working in the IT industry, are often IT nerds, who are frequently brilliant but won't always readily admit when they don't understand something.
This whole experience has given me a different perspective on what I need to do to evangelize and educate on structured authoring in future projects. The demands that I was given were so ludicrous in this project that I described, that I resigned after delivering documentation for the software release. Sad to have had to have done it for these reasons of ignorance rather than issues with the quality of my work, but it underscores how problems with adoption alone can impact a project.
A funny anecdote related to this aftermath...so simple does the project manager think structured FM that I learned she tasked the company's graphic designer with ownership of these now mangled templates/EDD - he has never even opened FM. Given the fact that even as an experienced FM user I am constantly confronted with bugs, difficulties, and frustrations with things like propagating formatting, TOC generation, or book numbering, I can only imagine what this guy is going to face. Ultimately, though, I think it will force them to confront the reality of structured authoring. Maybe this should become my horror story in future projects to underscore the importance of a holistic approach with this work. Sometimes you learn the most from such bad experiences.