Moving Technical Communication Online

By GEORGE HAYHOE
STC Fellow
South Carolina Chapter

When I was appointed editor of Technical Communication in September 1995, there were many action items vying for my attention. Most notably, a blue-ribbon panel appointed the previous year had evaluated the Society’s periodicals and made a series of recommendations about the journal’s content, management, and operations. Even though moving the journal online was one of my top priorities, my first major task was to redesign the publication. That effort took nearly two years, so it wasn’t until late 1997 that the journal’s Editorial Advisory Board and I were ready to look at online production.

This article discusses our experience in moving an established print journal to concurrent online publication. While the project was successful in that Technical Communication is now available on the Web, we encountered many hurdles in accomplishing this goal. Although STC is a nonprofit entity, many of the problems we faced are similar to those that corporations and other organizations might encounter when moving printed documentation online.

Funding Requirements

For nearly 20 years, Technical Communication has been printed by the world’s largest producer of scientific, technical, and medical journals, a company that also pioneered online journal production. I approached this partner when making initial inquiries about pricing, timelines, requirements, and so on. My contact person with our vendor was well-versed in both the technology and steps that were needed to proceed. I made careful notes and, with the help of the Editorial Advisory Board, began to prepare a Request for Proposal (RFP) that would eventually be sent to several firms to bid on the conversion project.

I also prepared a budget for the project based on the vendor’s charges for the services we would require for design, production of an archive of back issues, ongoing production of future issues, and hosting of the journal Web site.

STC is governed by an elected board of directors. This board authorizes annual budgets for all projects planned by the organization. To be funded, a new initiative usually needs to be included in STC’s strategic plan, and the project lead must submit a project plan detailing proposed spending. Furthermore, the board expects competitive bids for any services procured from outside the organization.

Because budget problems in the 1998-1999 fiscal year, the board’s approval of the proposed online journal was delayed until late January 1999. Once the budget was approved, I issued the RFP (roughly 15 months after beginning my fact-finding activities). Only two companies bid on the RFP: our longtime print vendor and one other firm.

By the time quotes were returned and evaluated, time was running out to complete the project during the 1998-1999 budget cycle, which ended on 30 June. STC budget line items don’t carry over into the next fiscal year, nor do they accommodate inflation. Both of these issues became pressing in the late spring of 1999 when the implementation phase of this project began.

Technical Requirements

In the RFP, we set forth a number of technology requirements, including the following:

• Make the journal available in HTML format to facilitate browsing and searching
  
  
• Make the journal available in PDF format to facilitate printing and reading offline
  
  
• Control access to the most recent four issues by STC member number, with earlier issues available to the general public
  
  
• Insofar as practical, preserve the look and feel of the paper journal, understanding that some design elements will not translate effectively from print to online and that most users will not have the fonts used in the print journal installed on their computers
  
  
• Avoid unnecessary cookies and plug-ins

Both of the proposals that we received in response to the RFP met these technology requirements, and the costs they quoted were similar. Since there was value with staying with a long-term partner, however, we selected our print vendor to produce the online journal, despite the fact that the prices they had quoted us in October 1997 had increased significantly by the time we received their official bid for the project.

Project Initiation and Problems Behind the Scenes

We needed to spend the budgeted amount by the 30 June 1999, so after consulting with STC’s president and executive director, I decided to pay for most of the work up front. The contract specified that design and implementation would take two to three months, so the initial plan was to have the November 1999 issue and an archive of seven back issues available online on the same date that the print version of the November issue would be mailed out.

Because costs had increased during the 15 months between the time I had prepared the budget and the vendor had submitted an official bid, during contract negotiations with the vendor, we chose the vendor’s low-cost product, passing on a more expensive alternative, to stay within our budget. At about the time we released the money and authorized the work, however, the vendor reorganized internally after acquiring a leading online journal design and development firm. Unbeknownst to us, one result of this reorganization was that the vendor discontinued their "budget" product and made staffing changes. Everyone who had been involved in the proposal for our project and had worked on the planning stages went to other duties or other places.

Furthermore, the vendor had used home-grown software for access control (recall that we wanted access to the most recent four issues to be controlled by STC membership number). Access control must be customized for every journal that uses it, because each journal has its own business rules for access decisions. However, because the code was undocumented and all of the developers familiar with the code had left the vendor’s organization, there was no way to customize the access control product to conform to our business rules.

Slipping Deadlines

Toward the end of summer 1999, I began making calls to check on progress to see whether we could advertise availability of the online journal in our November issue. Finally, after receiving sketchy responses, I flew to Baltimore in late August to meet with the company face-to-face. At that meeting, the vendor didn’t disclose any of the problems described above, but they did assign a project manager and designer for our project. Design work began but proceeded slowly.

I made another trip to Baltimore (exhausting my travel budget for the year) to work out final design details. At that meeting in late November, we agreed that, given the approaching holidays and some unforeseen production problems, the site would debut with the February 2000 issue, and we set a 21 January 2000 deadline for completing the project. Two weeks before that deadline, however, I got a call saying that the vendor couldn’t meet the schedule. It was at this time that I first heard about the merger, staff departures, code problems, and other tales of woe.

At that time, the vendor told me that they had given us the deluxe product for the same price they had quoted for the budget product because they had discontinued the less expensive option. Moving to this more sophisticated product added a level of complexity that hadn’t been reflected in the schedule I’d been given. Finally, they were encountering problems installing the third-party access control software that they had purchased to replace the homegrown software they had expected to use. In short, they didn’t know exactly when they could finish the project … maybe the beginning of March.

Although I wasn’t happy about the delays, we agreed to complete the project in two phases. First, rather than wait until the access control problem was solved, the journal Web site would be available in early March 2000 with no access control. That allowed the vendor to get the site up and running without worrying about access control software problems. In the second phase, the access control software would be installed, probably in mid-May.

Fortunately, the vendor was able to meet this revised schedule, and the project was completed successfully. Today, we have 24 issues online, and new issues are published online on the same date that the print issues are mailed to subscribers. Interestingly, during the past year, our vendor sold the online production and hosting company whose acquisition caused many of the problems associated with our project. As a result, we now deal with two vendors, one for print and another for online production, but so far, that split has not caused any significant problems.

Lessons Learned

We’re reasonably pleased with the end result. I just wish it could have been a more pleasant process. A series of assumptions and miscommunications accounted for most of the problems we encountered, and I offer the following recommendations to avoid the pitfalls we encountered.

• If more than three months elapse between the quote and the contract award, ask vendors to update their quotes.
  
  
• Be sure you understand how the vendor makes their estimates. Our vendor said it was an 8- to 12-week project, but neither side clarified whether that meant elapsed time or 160 to 200 hours of effort.
  
  
• Never pay for work up front—at least not all of it. One major misunderstanding resulted from the vendor’s viewpoint that they were "giving" STC their "deluxe" product for the cost of a less expensive alternative, so they found it difficult to understand why we were fussing over the schedule.
  
  
• Before signing a contract, get a detailed project schedule of tasks, deliverables, and dates. Get the vendor to commit to the dates and detail the consequences of not meeting the schedule or of renegotiating deadlines.
  
  
• If working with vendors distant from your location, include travel money in the budget.
  
  
• Arrange for regular vendor status reporting and maintain weekly (or bi-weekly) communication with the vendor’s project lead.
  
  
• If the vendor has to significantly change its product or personnel, revisit the contract and schedule to understand the impact of those changes.
  
  
• Plan for a phased roll-out to accommodate the normal changes that happen in any organization’s life.

It’s really important to 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.