It All Starts with Standards
“Standards.” The very word brings a chill to the creative bones of the technical writer, while simultaneously creating a warm fuzzy in the heart of the project editor. As for the managers of technical publications departments, visions of dollar signs dance in our heads: Will the immediate cost of implementation balance the long term savings in translation, reuse, and updates?
Over the last 18 months, Jeppesen’s Aviation Courseware Department wrestled with these issues as we developed a comprehensive set of Jeppesen Standards for our department. The impetus for creating these standards was clear:
- Growth in the documentation and training business resulted in a geographically dispersed team who needed governance
- Acquisitions by the company brought new documentation and training departments looking to fit in
- Product lines that share similar, if not the same, audiences required similar approaches to avoid confusing our customers
- Digitization of the information assets of the company offered the potential of significant re-use of content in a variety of media to a variety of audiences, if that content fit together well
- Potential needs for translation of content mandated a more efficient process and an economy of words
The benefits of having these standards were equally clear:
- Standards point everyone in the same direction. If training and documentation is to be a core competency within the company (a mandate from our president), we cannot dilute it by letting people go every which way. Standards keep us focused on the goal.
- Standards bring new people up to speed faster. Not only do they
provide the initial orientation a new writer or editor needs on the way we do things here, they also ensure that help is available for those new people wherever they turn – anyone can answer their questions, and they don’t get different answers from different people.
- Standards help control costs by improving efficiency, eliminating questions and arguments, and preventing trips down a rabbit hole. Projects with standards are easier to manage, leaving less room for interpretation and providing a clear process to follow throughout development.
- Standards provide an unbiased way to hold writers and editors accountable. Creative endeavors frequently are difficult to measure as they are somewhat subjective. While a writer might argue that “utilize” is a perfectly valid word, if the standards say don’t use it, the argument is no longer a matter of preference and taste. And, in a backwards benefit, standards provide unity to the team by providing a “common enemy” – edits are no longer personal but can be blamed on the standards instead.
What was not clear was how to go about creating those standards, what the standards should include, and how to get global buy-in. The lessons we learned, we now offer to you to help you avoid the pitfalls and to stimulate your thought processes as you decide what to standardize.
Defining the Project
While the benefits of standards garner no argument, the extent of what to include in those standards proffer more debates. Before we could begin defining standards, we had to agree on what we meant by the term. Are standards simply a style guide, dictating writing style, word choice, and acronyms? Were we going to reinvent the wheel of The Chicago Manual of Style? Did we need to cover the basics of each profession, or could we assume that our audience already knew how to write, draw, program, and so on?
We agreed that we wanted Jeppesen’s standards to provide a common understanding of
- the product being developed
- the process by which it would be developed
- the presentation style it must conform to
With these goals in mind, we identified the following 13 chapters to include in our standards document.
Although it seems rather basic, we found we needed to start with good solid definitions of our various product types. Too often, we called similar products by dissimilar names, while customer expectations of what those products contain were based on the name. We found that the word “textbook” called up one mental image, while “manual” and “handbook” meant different things. Yet all of these terms were slapped onto similar products. Our standards addressed this issue and others:
- What is the difference between a tutorial and a Computer Based Training (CBT)?
- What sections must always be included in a user guide? An installation guide? A technical support guide?
- What is the purpose of release notes?
- What distinguishes a study guide from a test guide from a question bank?
While you might think that job responsibilities don’t fit into the three goals of our standards and should be handled by human resources, not our department, we found it necessary to include responsibilities, accountabilities, and authorities of team members into our standards. The HR job description did not always match how specific job positions were actually being used by their project teams. Our standards in this area answer questions:
- What are the responsibilities, accountabilities, and authority of my position?
- What is the difference between a project editor, technical editor, and a copy editor?
- Does the writer or the subject-matter expert write the first draft?
- Who can grant an exemption to these standards?
Although our group has always tracked our time well, integration with a company-wide tracking system resulted in a variety of approaches to project management. We found it helpful to standardize common elements:
- How often must status reports be provided and to whom?
- How are risks and issues documented and mitigated?
- What size tasks do we track (duration and/or work effort)?
For virtually every documentation and training project at Jeppesen, we found a different development process. In fact, on some projects we found more than one. Not only did this add confusion to people moving from one project to another, but it was difficult to track consistently according to our project management standards. While there is still some flexibility in the process, we chose to standardize issues such as
- In what order do technical, project, and copy edits occur?
- What is the process for rejecting an edit?
- How many review cycles will there be (internal and external)?
- What must be delivered for a first draft review (i.e., graphics or graphic requests)?
While the simple availability or unavailability of tools provides a default Standard of what we use, we still found it useful to address issues such as
- What programs and versions can be used to create CBT? Graphics? Video?
- When do we use FrameMaker instead of Quark?
- How is the decision made for upgrading to a new software version?
- What software is required to maintain historical products?
It only takes one or two times for a manager to hear “I updated the wrong file,” or “My computer crashed and I lost all my work” to realize the need to standardize and enforce good file management practices, including
- What source control system will be enforced?
- How frequently do files need to be checked in?
- When do we archive files from the active directories?
- What file naming conventions shall be used?
In practice, we don’t want to reinvent the fine job that The University of Chicago has done in writing and publishing The Chicago Manual of Style. But neither do our team members want to look through the thousands of pages in that guide for a simple answer. We had to balance carefully what content needed to be included in our Jeppesen Standards with what could be well-referenced. Our standards must cover things that Jeppesen might do differently than is typical. We chose to cover such things as
- What is the difference between writing for web content and writing for print?
- Are there different styles for software documentation vs. training?
- When might we use the passive voice?
- What acronyms are acceptable without spelling them out?
In addition to answering these types of questions, we also found it important to list our preferred references for covering issues not explicitly in our standards, such as
- Merriam-Webster’s Collegiate Dictionary, 11th edition
- The Chicago Manual of Style, 15th edition
- Microsoft Manual of Style for Technical Publications, 3rd edition
Although we have professional instructional designers on staff, our process typically has writers and subject-matter experts writing objectives and test questions. We found that while it might be enough to tell the professionals that we use the ADDIE model (Analysis, Design, Development, Implementation, and Evaluation), we needed to provide more detail for our other staff about what that meant to them and the way they did their jobs. In this one area, we broke our rule of assuming everyone had been appropriately trained in their profession and documented some basics of instructional design, including
- What instructional design model will we follow?
- What are the required parts of a well-formed behavioral objective?
- What question types are appropriate for what levels of objectives?
- How many questions should be written for each objective?
Graphic design and photography
We began to use the same graphics in print and online; standards became painfully necessary to ensure the best quality everywhere. Sample topics include
- What color palettes are acceptable?
- What file formats will be used?
- What are the procedures to follow when capturing screens?
- How do we obtain permissions to use graphics from other sources?
Although audio and video work represent only about one percent of the work we do in the department, we still felt the effort to define standards was worth the effort. As technology continues to improve, we expect to use more of these elements in our training materials. Having standards already defined helps us move forward more quickly. We covered items such as
- How is professional talent selected?
- What is the maximum length of a video clip which will be used in a CBT?
- Are audio clips embedded within the Flash animation or called from outside?
XML and formatting standards
These standards are the newest in our set. Although we identified the need for these standards, we had no experience to draw on to create them. We had to start some projects using XML to identify the areas that needed to be covered. So far, our topics include items such as
- What Document Type Definitions (DTDs) will we adopt for what situations?
- What metadata do we need to define?
- What style sheets are appropriate for specific product types?
Ultimately we found this area to be the largest, covering everything from learning management strategies for assigning and tracking learning to the CBT engine to look and feel. As we move forward, this section will likely be split into smaller topics, but for now it answers questions such as
- What data must be collected for student records?
- What navigation elements must be present in all CBTs?
- What screen types are available?
- When do we use audio in e-learning?
In a typical project, testing windows always seem to be shrunk as other phases of development expand. The standards in this category help to protect that function from non-existence as they define what must be included in testing. In addition to functional testing, this section also covers usability testing standards and includes issues such as
- How do I report a bug or issue, and how is the status reported to me?
- How many test subjects are appropriate for a beta test of a CBT?
- What information do I include in a test plan?
- What’s the difference between usability and functional testing?
In The Role of an Information Architect in the Technical Information-Development World, JoAnn Hackos identified a key benefit of taking a minimalist approach.
When information architects begin with a minimalist approach, they are often able to reduce the verbiage, eliminate content that serves no one, and focus content more precisely.
In other words, the writer can leverage their knowledge of the user’s Me—context and agenda—to create information that synthesises the message and discards the exformation that is extraneous to or implicit in the user’s context.
Henry Korman presented strong arguments for adopting an exformation strategy in Do We Manage Information Efficiently? in the June 2005 issue of the Best Practices Newsletter.
- Organisations need to reduce the amount of information they are managing and storing.
- Information designers need to find more effective ways of getting customers to the information they can use without requiring them to spend so much energy that they give up.
Implementing the Project
The standards team also had two other significant tasks to complete:
- The creation of an implementation plan for the standards.In addition to establishing how the standards would be rolled out across the organization, this plan documented processes for the enforcement of our standards. Not only is conformance verified in each editorial pass, but the plan allows for random verification and includes verification in the final quality control acceptance process. The plan also created a community of practice not only to support each other in the use of the standards but to periodically review industry trends for improvements that might be made to the standards.
- The creation of a change management process to define how exemptions can be granted, new standards adopted, or changes made.
Obviously, the comprehensiveness of what we chose to include in our standards required an intensive effort. To date, we have spent almost 3,000 hours defining and maintaining our standards documents. The first thing Jeppesen did right in the creation of our standards was to establish it as a project from its inception. That is, we established a budget for the creation of the standards, we allocated dedicated resources to the project, and we set a schedule of deliverables that had to be met. Treating standards with equal weight to any of our other projects removed any prioritization issues that could have been raised – do you want us to work on creating standards or do our “real work”?
As a real project, the Standards project had a project plan, outlining the specific steps we would take to create our Standards.
Looking back on the 18 months it took to have a mostly complete set of standards, four key challenges stand out.
Not only is there a significant cost in the creation and maintenance of the standards themselves, but the cost of conforming to those standards can also be prohibitive. How many existing products do not conform to the standards you are creating, and what will you do about that?
To create the standards project, we built a successful business case around the needs and benefits that started this article: re-use factors, productivity factors, and to a lesser extent for us, translation factors. However, we also grandfathered in all existing product lines with the understanding that the next time those products were updated, the budget would include the costs of updating them to conform to our new standards.
Incomplete, faulty, or inapplicable
The reasons that standards can so often rankle is the fear that all factors may not have been considered. Certainly it’s impossible to think of everything the first time out. In addition, there always seems to be a special case – customer-driven requirements for a specific product may go against the standards established.
Absolutely critical to the acceptance of our standards was an acknowledgment of these facts, a provision for exemptions, and a change management process. In fact, we have standardized our exemption and change- management process. Teams with customer requirements, or even just a desire to have a project-specific style guide that bends or breaks the standards, can request an exemption from the standards. These requests are evaluated by the standards Change Control Board, for both the immediate question of granting an exemption and the long-term evaluation of whether the exemption should also drive a change in the standards themselves.
In addition to exemptions, anyone can submit a proposed change to the standards at any time. The Change Control Board meets regularly to review these submissions and implement those suggestions that have merit.
We knew from inception that people don’t like to use other people’s processes. Everyone thinks his or her own projects are unique and that standards are a great idea for everyone else but me.
To overcome these attitudes and get as much buy-in as possible, the standards project at Jeppesen was staffed with the people that management identified would be the biggest resistors if they weren’t involved. They became invested in the standards they created, and instead of making the biggest noise against them, were influential in their acceptance. In addition, no standards were adopted without a comment period, where the drafted standards were available to the community for comment. This assessment period gave staff the opportunity to be heard and to feel they were part of the process.
A significant factor in acceptance and buy-in, however, still remains the accountability factor. Project leads and editors were given authority to hold their team members accountable for conformance. Job descriptions were updated to state that every person is responsible for conforming to our standards, and therefore non-conformance is a performance issue directly impacting reviews and raises.
As with any big change, communication was the key to a successful introduction of the standards. Throughout development all staff members were kept informed about the project, asked to participate in various discipline meetings, and given opportunities to comment on draft standards. In addition, another critical factor was actually training the standards. Sure, everyone was able to read them, but reading and understanding are not the same thing.
As part of our roll-out of the new standards, we scheduled multiple training sessions. The first, attended by all staff, introduced the standards to everyone, reviewing in detail conformance expectations and change management and exemption processes, and providing a high-level overview of the contents of the individual standards. After that initial level-setting, individual training sessions covered each of the topics in detail. Specific people were required to attend those sessions, which were optional for all others.
Finally, our communication plan includes continued notifications regarding the standards. New changes are loaded onto the Web site with a flag to call attention to the changes. In addition, staff receive emails informing them of changes and new content.
Return on Investment
So was it worth it, you ask? We spent thousands of hours in the development of standards and we refereed countless arguments about what those standards should be. As we begin to create new projects under those standards and bring old products into conformance, do we see a difference – are the benefits we expected being realized?
While the jury is still out on the actual ROI, we can report that our design standards are being used and are generally accepted by the community. Suggestions for changes, high in the beginning, have leveled off as the standards become more complete. Referencing the standards when a question comes up is now a habit. And although they may not know why, our customers are noticing a difference; for example, one customer recently commented that our current deliverable was the best we’ve ever done.
About the Author
Dawn Stevens is the Senior Manager of the Aviation Courseware department at Jeppesen. In her six years at Jeppesen, she has focused her energies on increasing the process maturity of the organization, particularly in the areas of project planning and tracking and quality standards. Her efforts were recently acknowledged when the Aviation Courseware department was established as a centralized, enterprise-wide group servicing the entire company in recognition of the department’s consistent delivery of quality product on time and on budget.