Part 1 and Part 2 of this series covered information architecture from the author and user perspectives. But there’s a third perspective that forms the foundation of the first two, the organizational one. The best features and plans don’t exist in a vacuum; without organizational support, they’ll fail. All the effort that went into them will get confused at best or lost at worst. (Unfortunately, almost any author with more than a few years of experience can attest to this.)

As with parts 1 and 2 of this series, I’ll limit the discussion to four major issues – standards, training, authoring statistics, and “corporate memory”. Note that while these issues definitely apply to any authoring using MadCap Flare, they are independent of Flare – they apply to any authoring tools or environments.

Standards

Standards are inherently boring. They’re often the subject of “thinking outside the box” presentations at conferences. Yet standards are actually the foundation on which our work has to rest. (My attitude has for years been that you have to “think inside the box”, “the box” being things like schedule, budget, political, technical, writing, and other constraints.) Without standards, and adherence to them, development is chaotic and maintenance becomes difficult. What kinds of standards am I referring to?

Schedule, budget, and political constraints vary by company so I’ll focus instead on technical and writing constraints. These can be external or internal to the company. For example:

  • Adherence to standards from external standards bodies like the Worldwide Web Consortium. Theoretically, your authoring tool does this for you if the tool vendor follows those standards. This seems self-evident but I’ve worked with many clients that use authoring tools that were last updated in the early 2000s and whose vendors may no longer even exist. So, the company has to upgrade to a new tool but upgrades, especially correcting the code in legacy content, can be painful. Many companies will keep using outdated or even dead tools rather than buy a new one. Many companies will also use an old version of an authoring tool rather than spend money on periodic upgrades. But without the upgrades, deprecated features in the older versions of the tool may send your content into a technical dead end that requires complex cleanup.

There may also be a mid-ground between external and internal standards; someone must decide what external standards to follow. One of my standard questions to consulting clients is whether the Flare authors have to follow proper code syntax and how they know whether they are. This often means using a parser. But my experience is that few of my clients do and they get little direction from engineering. What’s needed is better inter-departmental communication.

  • Adherence to internal standards, and helping develop, promulgate, train, and measure authors on their adherence to those standards. Those standards might include grade level for content, terminology standardization, whether to use index entries for indexing or to enhance searches, what authoring tool and version to use, stylesheet, formats for multi-word file names, whether to make an entry for the File tag, and so on.

There may also be conflicting internal standards. For example, you might create HTML5 output but find that your marketing department controls and sets standards for the company website and expects the Flare authors to follow those standards, you may need to specify when authors can deviate from those website standards.

Three crucial words above are “…promulgate, train… measure…” Too often, the people who develop standards assume that someone else will implement them. The result? Standards that go nowhere because no one is driving their adoption.

Training

One comment I hear often from new users is that “Management bought Flare but didn’t want to spend money on training. They said “you’re smart, you’ll figure it out.” And I’m often impressed by how much users have figured out on their own through trial-and-error, watching archived webinars on MadCap Software’s website, and reading the forums. And yet…

  • Trial-and-error often means a lot of wasted time and inefficiently structured projects that could have been avoided by taking formal training courses.
  • The archived webinars offer a lot of useful information but have two problems. First, there’s no inherent sequence to the webinars so authors often wind up viewing them out of sequence and have to work out the sequence of steps in a project on their own. Second, the webinars often focus on the mechanics of using Flare’s features but rarely cover project design, management and maintenance.
  • The forums also offer a lot of useful information but some is contradictory and multiple threads often get intertwined in the response to a question. Again, the user has to figure out the thread. And the answer often requires that the user understand some fairly advanced concepts.

I’ll simply say “take the formal training”. The reduction in time and cost spent going down blind alleys or designing projects that have to be redesigned will more than make up for the cost of the training.

Authoring Statistics

Collecting and maintaining authoring statistics is one of the best things you can do for your work. Figure out things like how long it takes to write a page of content (after defining a “page”, such as an 8 ½ x 11 and double-spaced – about 200 words), how long it takes to create a topic, how long it takes for non-topic specific tasks in a project, like designing the skin, writing a glossary, creating the micro content, and so on. (I’ve been collecting and maintaining such statistics since the early 1990s. I can use it to spec out the time needed for a new project to within about 90% accuracy.) This in turn lets you figure out if you have the resources for the project or if you need to bring in contractors, and if you can meet the development schedule. It’s one of the most useful things you can do.

It’s also one of the most politically charged. People often resist the collection of statistics because it’s a firm measure of their productivity. Be prepared for a fight if you propose this. It should be worth it. (I’ll add that because of the politics, this is an area for which you may want to bring on a consultant to drive the idea. Let the consultant take the flak.)

Corporate Memory

Too often, after we define standards, take the training, and collect and maintain the statistics, people don’t maintain all that information. Those who were involved in the effort take new jobs and don’t get the new authors up to speed. Basically, all that hard-won knowledge disappears and the next authors have to start over again, often making the same mistakes as their predecessors.

The solution isn’t easy but it is straightforward; document your standards, authoring techniques, and statistics. Put someone in charge of doing this and make that a formal part of their job description and performance reviews to make sure it happens. Do what you can to integrate this into your company culture. It takes effort but it will eliminate a huge number of problems going forward.

Summary

This is easy to summarize – the technical features are the manifestation of information architecture but it’s the organizational context that will make or break the effective use of the technical features.