Skip to Content Skip to Main Navigation
 

During the spring of 2008, I got a call from a friend who asked if I could help a valued client with a “rescue” project. In her brief overview, she relayed the organization needed to produce a number of deliverables that included training materials and user guides for a new enterprise system that was being rolled out, in under eight weeks from the time of our call. My friend said she didn’t have the bandwidth to take on the project herself, and had decided that if anyone could pull off this miracle, it would be me. After meeting with the training manager and test lead for the application project, I decided that if the client allowed me free rein to efficiently manage my end of the project, I would be able to deliver a suite of communication products on time and within budget, and accepted the assignment.

Working on this project was akin to running a race. There was no margin for error, and even the smallest of missteps had the potential of spiralling the project into a time or cost overrun. The pressure cooker environment reduced the normal tolerance range for project errors and, similarly, magnified any areas of weakness. The learning potential for all the stakeholders was immense, and because of the organization’s willingness to be-fellow travellers on what sometimes felt like an episode of The Amazing Race, we all took away valuable lessons.

The purpose of this case study is neither to simply rehash the project nor to provide a pressure-cooker story that others can use as a comparative benchmark. This article looks at the decision points within the project and provides an analysis from a real-life, practical approach that other technical communication managers can use when called upon to engage in a rescue project of their own.

Understanding The Project

The project was described as a training project. A healthcare organization, my client, was implementing the first two modules of an enterprise-level healthcare administration system. This would replace the client’s existing systems, which worked quite differently than the more powerful, incoming system. As with any enterprise-level system, the vendor does substantial customization to make the application work within a specific organization. As a result, the client needed to customize the user support materials – training and user guides, and so on – for the organization. In this case, the difference between how the Canadian healthcare system worked and how the American vendor’s software worked also gave the project a little extra space to traverse.

According to the organization, they wanted user guides for two application modules and training material for three classroom courses. Some of the course material in those courses overlapped, as they incorporated workflow from the two application modules (see Figure 1). They also wanted to deliver some online training to off-site workers who needed to learn about the new software and how to view information in the system.

Figure 1:

Like many rescue projects, the project definition changed several times. The time lapse between the beginning of the engagement and the first train-the-trainers session was just over six weeks. We had an additional eight weeks, with staggered deliverable dates within those eight weeks, to complete the remaining deliverables. As the project requirements grew clearer in the project stakeholders’ minds, and as development on the software itself continued, the number of deliverables rose from eight manuals (three instructor guides, three student guides, and two user guides), plus one online module and some job aids to a more comprehensive list of training materials, including:

  • User guides
  • A series of 30 cheat sheets
  • Online modules linked to interactive software simulations
  • An online knowledge base
  • Adjunct training modules with a full complement of support material, such as peer support and concepts of training
  • Job aids, such as a full-color tent cards with a key to the software color scheme

My assessment of the project revealed we could re-use much of the content between deliverables. I explained to the client that in order to meet the deadline, I would need permission to use a single-sourcing technique that would allow my contractors to create all the material in discrete topics. Then, through the magic of technology, this would enable us to easily recombine and re-use topics to create the manuals.

During this project-evaluation period, it was of no value to us knowing that the client usually used nurses as the subject matter experts to create training material or user guides as Word documents. Typically, a nurse would create three training manuals and two user guides, or perhaps some hybrid manual for all purposes. Our training manager was sceptical about this, given the client’s emphasis on using SMEs and their lack of technological acumen. During our discussions, I focused on the deliverable, but resisted discussing how we would take care of single-sourcing the content in the back end, and assured the client that what they would get would be the usual Word documents. I then asked the client to let me plead my case with the lead integrator.

During discussions with the lead integrator, once again I resisted the temptation to go on and on about the “how” and focused on explaining concepts in his language. For example, he immediately understood where I was coming from when I compared creating object-oriented content to object-oriented programming. Then, I explained a few benefit points, including the ability to:

  • Make changes in one place yet generate the same changes automatically in all the final documents.
  • Use variables to handle the naming uncertainties due to development delays.
  • Drag-and-drop topics in order to create additional deliverables on the fly.

Alright; a little exaggeration on the final point. But the goal here was to be persuasive. As a result, we struck an agreement and I was asked to begin immediately.

Critical Decision Points

Having worked previously with this client and similar clients in the public sector, I knew that getting the paperwork in place could take as long as the project itself. Although it was a gamble, my company was already set up as a vendor in the system, so I felt confident about getting a preliminary agreement in principle from someone at the VP level and jumping into the work. We had a mere seven weeks. After deducting days for content reviews, stakeholder sign-off meetings, travel absences, and statutory holidays, the actual content development time was considerably less than a month.

My decision to start the project before getting the contract signed turned out to be a sound one. Due to various factors associated with government contractual processes, the final step of the contract process took place a week after the project was finished. What helped keep the process moving was the perseverance of a dedicated administrative assistant who figured out the intricacies of the process, and my willingness to stay engaged in it. I realize that any balking on my part could have easily derailed the purchasing process, and I could still be waiting for signatures and funding. Had this been a client in the private sector, I doubt I would have made the same decision.

The next decision point was to decide on the content-development process. During the negotiation phase, I had identified that topic-based content development would be advantageous to meeting our goals, but that could have been carried out in a number of ways: XML authoring in DITA, structured FrameMaker, content insets in unstructured FrameMaker or MS Word, and so on. Before choosing my software tool, I thoroughly considered the organization’s overall requirements. The client needed Word, PDF, and HTML output, but had no knowledge of, or need for, content produced to any XML standard. They could use XHTML source files but not proprietary formats. That would require them to buy specialty software with a steep learning curve, an unlikely prospect for clinical staff in a public sector organization. I needed a content repository that was both popular in the industry and easy to use, in order to coordinate the efforts of multiple contractors, and allowed me to concentrate the content in a single content repository.  From the many software tools I invest in and maintain, the logical choice was Madcap Flare. We could avoid the proliferation of duplicate content chunks, and get all of our deliverables from a single source.

As the client re-allocated resources to meet shifting project demands, I found myself spending more and more time doing project management, and less time involved in the content development. Aside from the instructional designers, I brought on board two contractors, one with a training background, the other with a technical communication background, and I explained the content-development strategy to both of them in great detail. I knew both by reputation, and they were both experienced contractors in the technology field.

One of the contractors was very familiar with creating topic-based content, and had Flare experience, but she had never worked on a training project before. Her challenge was to grapple with the new concepts such as competency-based training and structuring procedures around learning objectives. She made the conceptual leap, and was able to structure the content in Flare to be output in a variety of formats, such as user guides and course guides.

The other contractor was very familiar with creating training materials, but resisted using Flare. I came to understand this was from a fundamental lack of understanding of the benefits of topic-based writing. He was familiar with the framework of contextual, linear content that then gets chunked and converted to another format – for example, converting FrameMaker to HTML through WebWorks. My low point was at a meeting where the same phrase, which appeared in multiple places through both manual, was supposed to have been changed but only some instances had been corrected. It hit home that not only was it causing a severe lack of confidence from the project sponsors, but the contractor had not bought into topic-based writing at all, and the result was slowing us all down. At some point, by mutual agreement, the contractor from the training background withdrew from the project, and the other contractor assumed the entire load.

One of the biggest challenges with the project was getting stakeholder agreement on critical project decisions. All good intentions went out the window as I realized that waiting for formal sign-offs would have resulted in unacceptable project delays. We got whatever agreements we could, and output our deliverables fast and furious. Most of the client team had a hard time grasping that generating a new document was the least of our worries; the hard part was getting them to commit to a decision so that we could finalize the table of contents and move our topics into place. For example, the client had requested the usual complement of student guides and instructor guides, which contained training instructions not intended for students. The in-class trainers then asked that the manuals be revised to be simply “course guides” – all the instructors’ notes were reworded in a more general way, and included for everyone to see.

At one point, I received a panicked phone call from the training manager who asked about the online module and the likelihood of having it ready in time for its scheduled delivery date. I was able to impress upon her that if she could get agreement on the content, we could deliver our end in record time. Once we were given the TOC, the contractor wrote a couple of topics, pulled the remaining content from the existing topics, and delivered an online module the next day, with a promise that their e-learning department would supply the software simulations before their deadline. Our credibility factor rose considerably that day, and I knew that our decision to use a topic-based approach had paid off. And when we said we could “wrap” all the deliverables – manuals, cheat sheets, job aids, and related materials – into a searchable knowledge base, known to us in the industry as an online help system, they were delighted. This was provided for the cost of the time to assemble the TOC; in other words, without an increase in the budget. Whether or not they realized the value of what we’d just provided as more or less a goodwill gesture was irrelevant to me; it adds to the client satisfaction rating, and maintaining a healthy relationship is my primary goal.

The contractor, to whom I continue to owe my undying gratitude for being so professionally stoic under what was sometimes intense pressure, admitted that had she been in charge of the software side of the project from the beginning, she would have structured and maintained it in a more efficient, elegant way. However, given the time constraints and knowing that the material would probably never be used after we wrapped up, I didn’t feel there was enough impetus to redo the project before handing over the source files.

The irony of the project was in one of the final deliverables: a series of close to 30 how-to “cheat sheets.” Throughout the project, we shied away from using screen shots because development continued until the day training started, and software fixes that affected the interface were still being made during the training period. As well, software views were customizable, so showing screen shots were problematic because what one department saw on screen would vary from another department’s display. However, the trainers were adamant that they wanted lots of screen shots, both in the manuals, and in a series of cheat sheets that featured a screen shot with a few instructions (see Figure 2).

Figure 2:

I knew the client had no graphic composition software and would be unable to modify any files unless they were in a ubiquitous application. I thought back to a PowerPoint document (one that contained graphic elements) that one of the team members had provided to me. So while we inserted the screen shots into the manuals using the usual practices, we created the cheat sheets outside of the single-sourcing process. We imported the screen shots into PowerPoint, pared down the instructions to as few words as possible, supplemented them with arrows pointing to the appropriate places on the screen shots, and gave them a consistent look and feel. Of all the materials we produced, these turned out to be the most popular job aids, due to their brevity and visual appeal. In the post-project debrief with the training manager, we concluded that for the roll-out of future modules, the training material should be centered around visual aids such as the cheat sheets.

Lessons Learned

In the final analysis of the project’s logistical aspects, I realized that a contractor who is comfortable with topic-based authoring can indeed produce more content of better quality, and with more cost efficiency. This includes the time to rework the traditionally authored materials into topic-based content in order to make it work with the remaining content.

As a leader in the technical-communication community, I have long maintained that core competencies, not software knowledge, are the criteria on which to base contractor suitability. This project has made me re-assess my thinking on this. I still believe that knowing how to use a specific software package does not guarantee quality work, just as I believe that someone’s assertion that they know how to play the violin doesn’t mean they can play from a symphonic musical score. However, I am revising my stance to recognize that contractors who can show they are comfortable with a type of software (in other words, RoboHelp, Flare, Author-it, or any other topic-based authoring tool) have effectively given me a short-cut to assess their abilities. To go back to the music analogy, if a person says they play second violin with the symphony, I can make certain assumptions about how well they can play, read a musical score, and understand music theory.

In the final analysis of the client management aspects of the project, the aim was to give the client whatever they needed, on what I knew going in was an impossibly tight schedule, to meet their goal of having training materials ready by the time training started, and the remaining materials ready by the application go-live date. The principles I followed were much the same as what I would have done on any other project. I established a trust relationship with the client by being forthright about the challenges and our ability to deliver. We set aggressive milestones and ensured that we met them, even when the client couldn’t gather their stakeholders to meet theirs. We simply kept going, and trusted that the client would appreciate our forward movement. Whenever I saw an opportunity to do so within the budget, we over-delivered. Why lose an opportunity to make the client look good? In the same vein, we explored every opportunity to add value to the deliverables. Sometimes, the client declined because they felt the effort didn’t make sense, but we showed them opportunities and gave them options.

At the end of the project, when the training manager said she would be delighted to work with us again, it was the icing on the cake. It meant that not only had we managed to meet the deadlines, but did so while retaining client confidence.

About the Author

Rahel Anne Bailie is principal of Intentional Design Inc, a Vancouver, BC consultancy that focuses on the interrelated areas of content management, content development, and usability. Rahel brings substantial business and communication experience to her projects, where she and her team help organizations with requirements and content analysis phases, through to assistance with RFP preparation and vendor selection. Rahel has many years of experience in the content development and user experience environments, and her perspectives are informed by her experience and studies.