Moving Technical Communication Online
When George Hayhoe began his term as Editor of STC’s Technical Communication, he had many action items on his plate. Prior to the change in editorship, STC had appointed a blue-ribbon panel to evaluate its periodicals and make recommendations based on in-depth audience analysis and comparison with similar publications. Even though moving the journal online was one of the top priorities, George’s first task was redesign the journal, which took 18 months. By mid-1996, the journal’s staff was ready to look at online production.
This discussion charts the ups and downs of moving an established print journal to a mirrored online journal. Although the project was successful (Technical Communication is now available online), George encountered many hurdles in accomplishing this goal. Even though most members don’t publish professional journals, we felt that many information-development managers may encounter similar hurdles when moving from print to online publishing.
Planning and Timing
For over twenty years, Technical Communication had been published by a world-class firm that publishes such prestigious journals as Nature (in the United States) and The Journal of the American Medical Association. George approached these partners when making initial inquiries about pricing, timelines, requirements, and so on. His contact was well-versed in both the technology and steps that were needed to proceed. George made careful notes and began to prepare a Request for Proposal (RFP) to be sent out to several firms to bid on the conversion project.
In the RFP, George set forth a number of technology requirements, including the following:
- Make the journal available in html (allowing browsing and search)
- Make the journal available in pdf (allowing printing)
- Offer controlled access (by STC member number) to the latest four issues
- Offer readers the option of reading abstracts or full text with the ability to go back and forth
- Preserve the look and feel of the paper journal even though many users may not have the required fonts
- Avoid cookies and asking members to install plug-ins
Both quotes that George received met these technology requirements; however, STC’s existing print vendor’s quote was lower, and there was value with staying with a long-term partner. Once he determined the best quote, George began working on a budget proposal.
The Question of Money
George experienced a time lag in awarding the contract for Technical Communication (see Projects at STC on the following page). George issued the RFP in September of 1997 (roughly a year after he began his fact-finding). Only two companies bid on the RFP and, not surprisingly, these organizations wanted both the print and online contracts.
By the time the quotes came in, it was too late to submit a budget proposal for 1997/98. George wrote the budget proposal for 1998/99 and received funding beginning January 1999. Note that many organizations with annual budgets don’t carry projects into the next year (unless you’ve written your budget proposal that way) and do not accommodate upward spiraling costs. Both of these issues became pressing in the spring of 1999 during the implementation of the project.
You Need What by When?
George needed to spend his budget by the end of May 1999. After consulting with the board, he paid for most of the work up front. Because the informal project plan called for the online journal to be in place in two to three months, the initial plan scheduled the September 1999 issue to be online on the same date that the print version was mailed.
During the planning stages, STC had chosen the lower cost “budget product,” passing on the “deluxe” SGML option. At about the time STC authorized the work, the vendor went through one of those 90s events-a merger. Unknown to STC, one result of this merger was that they discontinued the “budget” product and made staffing changes. Everyone who had responded to the RFP or worked on the planning stages left the project.
Further, the “budget” product/process was home grown, written in C. The critical feature of this product/process was the access control feature (recall that STC wanted the most current four issues to be accessed by STC member number). This feature was customized for every journal. However, because the code was undocumented and all of the developers had departed, there was no way to “customize” the product for STC.
Toward the end of summer, George began making urgent calls to check on progress because STC planned to advertise the online journal for September. Finally, after receiving sketchy responses, George went to talk with the company face-to-face. The company didn’t disclose any of the problems, but they did assign a project manager/designer.
George made two more trips (blowing his travel budget) to work on the design. In November, he thought that, given the holidays, tweaks, and so on, they could get the February 2000 issue online and in print. Two weeks before the February deadline, the vendor called to say they couldn’t meet the schedule. Only then did George learn about the merger, staff departure, code problems, and so on.
The vendor told George that they had given STC the “deluxe” product for the same price because they had discontinued the “budget” one. They also let him know that moving to this product added a level of complexity; they were having a tough time writing a filter that met the requirements. They also had no real idea of when they could get done…maybe the beginning of March.
The vendor finally set up project phases. Initially, the journals had no access control and four issues contained abstracts only. Access control didn’t arrive until May.
What Could Have Happened Differently?
George says, “To wind up a long, long story, we have ten issues up and, despite the implementation problems, we’re reasonably pleased with the end result. I just wish it could have been a more pleasant process.” He notes that assumptions and miscommunications account for a great deal of the problems they encountered, and he encourages others to avoid the following pitfalls:
- If more than three months elapse between the quote and the contract award, ask the vendor to update the quote.
- Be sure you understand how the vendor estimates. STC’s vendor proposed an eight- to ten-week project, but never clarified how the project would be staffed. Did they mean one person for 160 to 200 hours? Make sure you understand how the vendor calculates level of effort and how that relates to your expectations. Be sure you both differentiate in the same way between hours of effort and project duration.
- Never pay for work up front, at least not all of it. One major misunderstanding was that the vendor was “giving” STC the “deluxe” product, and they found it difficult to understand why STC was fussing over the schedule.
- Before signing a contract, get tasks, with deliverables and dates, on paper. Get the vendor to commit to the dates and detail the consequences of not meeting the schedule or of renegotiating the items.
- If you are working with vendors outside your location, include travel money in the budget.
- Arrange for regular vendor status reports and maintain weekly (or bi-weekly) communication with the vendor’s project lead.
- If the vendor has to significantly change its product or personnel, take the time to revisit the contract to understand the impact.
- Understand that “off-the-shelf” does not always mean ready to roll.
- Plan for a phased roll-out to put stretch in the schedule and accommodate the normal changes that happen in any organization’s life.
Many information-development managers have faced these same issues when implementing new technology in their organizations. George suggests that you take the time to review these potential pitfalls with your staff before proceeding with new projects. Otherwise, a two- to three-month project could take ten months. George concludes by saying “This was my first big technology project as editor; sometimes there is no other way to learn about the process than to go through it. I know we’ll have a smoother time with the next one.”