Scriptorium Publishing

content strategy consulting

XML product literature

October 27, 2014 by

Your industrial products become part of well-oiled machines. Unfortunately, your workflow for developing product literature may not be as well-oiled.

Using desktop publishing tools (such as InDesign) to develop product literature means you spend a lot of time applying formatting, designing complex tables, and so on. These time-consuming, manual chores:

  • Lengthen the amount of time it takes to get information to customers
  • Make it difficult to update information quickly
  • Provide many opportunities for introducing errors into content

XML-based workflows can solve these challenges in the development of product literature for machinery and industrial components. This post provides three examples of how XML can improve your processes for developing product literature:

  • Creating specification sheets
  • Managing common content across models, product lines, and departments
  • Handling OEM rebranding

Creating specification sheets

Putting together spec sheets and datasheets in a traditional desktop publishing environment is just painful. It’s easy to introduce significant errors by merely transposing digits in a part number, for example, and let’s not get into the horror of composing tables in a DTP tool. By the time you finish the layout, the information may be outdated—and customers haven’t even seen it yet!

Maria robot from movie Metropolis

“Machine Human” Maria in Metropolis (1927)

Part numbers, product dimensions, and the like often exist in a database (or multiple databases). It’s better to extract that content as some kind of markup language from the database and then and insert it into the source files for product literature.

The exact process will vary depending on the database and other tools involved, but generally, you want a workflow that extracts the information from the database and formats it automatically. By eliminating the need for human intervention (typing information, applying formatting, and so on), you reduce the possibility of introducing errors and shorten the amount of time it takes to get content to customers.

Because the workflow is automated, you can also release updates more frequently. If you release specs or datasheets in electronic format (web pages, for example), you could set up nightly updates to distribute the latest information.

Managing common content across models, product lines, and departments

The different models of a product usually have shared features, and those common features can stretch across product lines that contain the same parts.

In a traditional desktop publishing environment, it’s very easy to end up with multiple versions of content about a particular part or feature because there is no “single source of truth.”

A modular content workflow eliminates this problem: you develop chunks of content and mix and match them for a particular information product (a user manual or web page, for example) according to product features. Generally, a component content management system (CCMS) manages the chunks, and authors can search the CCMS to find the modules of content they need.

Sharing content modules has two big benefits: the reuse means you’re reducing the amount of time it takes to develop content, and you present customers with consistent information within and across product lines.

Content chunks can also be shared across departments. For example, a table with specs for a part can appear in a user guide, a trade show handout, and on the web site. Even though that table may be presented with different formatting in those information products, the XML source is still the same for all. That’s the great benefit of XML-based content: formatting (usually applied through automated processes) is completely separate from the content itself.

You really need XML at the core of your content to implement industrial strength (ahem) modular processes. One XML content standard, the Darwin Information Typing Architecture (DITA), is specifically for developing modular technical content. Even if an XML standard isn’t an exact fit for your requirements, you can adapt and modify it. After all, the X in XML stands for “extensible.”

Handling OEM rebranding

If your company provides components to other companies in an OEM relationship, an XML workflow streamlines the rebranding of content.

The separation of content and formatting inherent in XML workflows means you don’t have to open up and modify multiple source files to change logos, corporate fonts and colors, and so on. Instead, you create a new automated formatting process (possibly using your company’s transformation as a starting point), or you apply the other company’s existing formatting transformation if they are already in XML. The correct formatting is applied automatically, saving both companies a great deal of time—and that automatic formatting means you and your partner dramatically shorten the time to market for OEM equipment. By the way, all this talk about the separation of content and formatting has another huge benefit: decreased localization costs and faster release of localized content because you eliminate the manual reformatting work associated with translating content.

XML workflows also provide mechanisms for quickly switching out company and product names, addresses, and so on. The modular nature of many XML workflows also enables a partner company to select just the chunks of information they need about an OEM component.

Even if two companies are using two different “flavors” of XML, scripting can automate conversion. It is much easier to convert XML to XML than to convert content in one desktop publishing program to another.

 

Desktop publishing tools are wonderful for creating visually rich information. But for product literature, you need a system that produces attractive content, speeds up content production, eliminates tedious reformatting work, and streamlines translation.

XML is a better fit for product literature.

Need more information about how XML product literature can help your company? Contact us.

Content strategy and engineers

September 29, 2014 by

When developing a content strategy, you consider marcom, techcomm, and other groups whose primary role is creating content.

But don’t forget about engineering. Just ask the NASA Mohawk Guy.

Bobak Ferdowsi of NASA’s Jet Propulsion Laboratory—a.k.a. NASA Mohawk Guy of the Curiosity mission—recently pointed out how important communication and content are in his job:

Most people don’t realize how much…communication…an engineering job requires. I think about the things I end up sometimes spending a little more time on: for example, PowerPoint, making slides. … You still have to tell other people what you are doing, try to convince people of a certain approach to something, or demonstrate why one decision is more important than other. That communication skill is a real part of the job that most people don’t see.

self-portrait by Curiosity Rover

Self-portrait by Curiosity Rover (photo by NASA/JPL-Caltech/Malin Space Science Systems via Wikimedia Commons)

Ferdowsi recognizes the big part content plays in engineering and other departments perceived “as always cranking away on things, and turning wrenches.” Unfortunately, a lot of employees in the more content-heavy groups (marcom and techcomm, in particular) don’t always share his wisdom.

It’s too easy to follow stereotypical thinking: Engineers aren’t professional writers, so their content is of little value. I’ve encountered that attitude often in my career, and I’ll admit to succumbing to such stupid thoughts on occasion myself.

Bottom line: you cannot implement a successful content strategy without considering the content contributions of engineers, support, and other groups who create content as a secondary part of their jobs.

It shouldn’t take a rocket scientist to figure that out.

Content without a face: anonymity, egos, and corporate content

September 15, 2014 by

The novels of Italian author Elena Ferrante are getting a lot of attention, but “Elena Ferrante” doesn’t actually exist. The writer behind the pen name prefers anonymity and shies away from publicity. Creators of corporate content should take a few pointers from the author when seeking recognition for their work.

Regardless of the kind of information a content creator develops for a company—marketing, technical, training, and so on—the final information product must support the company’s business goals (which usually revolve around making money, saving money, or both).

woman holding mask to face

Anonymity has its place in corporate content (photo by W H, flickr)

Note those business goals don’t include “show the world that content creator John Smith is a brilliant writer” or “enable Jane Doe to show her dazzling proficiency in using Tool X to design content.” Content creators who approach corporate content as a way to get personal recognition are not doing themselves (or their employers) any favors.

There’s nothing wrong with satisfaction from a job well done or expecting to be properly compensated for one’s work. However, the primary purpose of the content produced at work is to support the company and its goals (and, by extension, the company’s success in the marketplace). Corporate content and the processes surrounding it are not about the content creators themselves—unless those authors are the subject of a piece in the company newsletter, and then the content is all about them.

It can be difficult for content creators (and all employees, really) to keep their eyes on the corporate goals while doing their day-to-day work and meeting deadlines. It can be even harder for their managers to offer gentle reminders of those goals when authors get too wrapped up in their daily grind.

So, what are corporate content creators to do? First, check that ego at the office door. Easier said than done, I know. My first draft of this blog post was ripped to shreds. I managed to survive.

To show the world writing or design prowess and to gain personal recognition for it, content creators are better off developing projects on their own time. When authors find other channels for their creative skills, they get to set the goals because those outlets are theirs. Pen names and shying away from publicity are completely optional!

P.S. Don’t equate anonymity in corporate content development with “bland and voiceless.” For example, the marketing group can’t afford to crank out dull, cookie-cutter content. Differentiating the company from its competitors with a distinct voice is key. Otherwise, the marketing content sabotages a primary business goal: making money.

P.P.S. Here’s where my mind went to get the headline for this blog post:

Engage before change: your content strategy mantra

August 19, 2014 by

If you’re about to revamp your content strategy, repeat after me:

Engage before change.

The only way you’re going to plan—much less implement—a successful content strategy is to talk to all the groups who create and consume content. Without that input, you can’t get a full picture of how content is and is not supporting your company’s business goals.

Don’t engage just the obvious content creators. Yes, marcom and tech comm develop a ton of content, so they have to be part of the discussions. But what about the support group, which writes its own cheat sheets and notes on customer issues official content doesn’t address? Finding and reviewing this “secondary” information and then integrating it into your content strategy is essential to ensuring information fully supports business objectives.

Same advice applies for talking to content consumers. If at all possible, get feedback from end users. Getting direct user feedback is often easier said than done, but the support group is a good source of leads because that department has a lot of contact with customers. Also, talk to the sales group to find out how content supports the sales cycle (or doesn’t), and revise your content strategy accordingly.

Give a great deal of thought about where content comes from and who uses it. Otherwise, you’re just paying lip service to the “engage before change” content strategy mantra.

Hat tip to a column on engaging employees before changing the office layout for inspiring this post.

Content strategy mistake: replicating old formatting with new tools

August 5, 2014 by

When remodeling your kitchen, would you replace 1980s almond melamine cabinets with the same thing? Probably not. (I certainly wouldn’t!) Then why make the content strategy mistake of using new tools to re-create the old formatting in your content?

If your company is spending the time and money on new tools for an updated content strategy, you’ve been given a rare gift: the opportunity to make changes. Those changes should include fixing bad, outdated formatting that makes content hard to read—and that reflects badly on the company as a whole.

photo of rubber stamp

Resist the temptation to duplicate old, legacy formatting when implementing tools for a new content strategy (flickr: woodleywonderworks)

Unfortunately, some content groups’ first inclination during implementation is to reconstitute the look-and-feel of information developed in the old tool chain.

Case in point: PDF output, which was a default output back in the day years ago.

If you’re working in a regulated industry requiring PDF output that adheres to a spec, making changes to (or discontinuing) PDF files isn’t an option. Meeting the PDF spec is a business requirement, even if the formatting dictated by those specs is ugly. Case closed.

For those not in a regulated industry, the considerations are very different:

  • Should PDF even be your primary output focus? If your customers are accessing content on mobile devices, PDF is not the best choice for them anyway. You need a mobile friendly output (adaptive HTML? app?) for those customers, but you also can’t unilaterally end PDF production if customers are accustomed to PDF. A good compromise: still provide PDF files—possibly with a simplified layout—as links from HTML versions of content, which you position as the primary way to access the content.
  • Does your page design need rejuvenating? If you’ve been churning out PDF files with the same design the past 5–10 years, there is a zero-percent probability the formatting reflects current design principles. If necessary, get a design consultant’s input, particularly on this question: Does the formatting help or hinder readers? It’s also worth noting some people—particularly those of us in any publishing-related industry—do pay attention to formatting. How many times have you seen outdated formatting in PDF files (or any other output, really) and assumed the company providing the information was behind the times, too? Confess!
  • Did workarounds for shortcomings of previous tools lead to compromises in formatting? If your old tool set had quirks in regard to page layout, PDF production, and so on, you may have instituted workarounds resulting in suboptimal formatting. No need to perpetuate those compromises in your updated output.

The surface appeal of cloning what you already have is understandable. Existing look-and-feel provides a definitive target, and content creators are probably comfortable with said target. However, unless there is a compelling business reason to reconstitute old formatting with your new tools—and “We’ve done it this way forever” generally is not—don’t do it.

If you need more proof cloning can be bad, just watch TV:

Planning your content strategy pilot project

July 21, 2014 by

Your content strategy is approved. Your tools are in place. Now it’s time to crank up—your pilot project, that is.

Consider these tips when mapping out your content strategy pilot project.

Your pilot project is a proof of concept—not perfection

If you expect your first effort using new tools and processes to be perfect, you’re setting yourself up for disappointment and frustration before you’ve even started.

photo of gas stove pilot light

Don’t blow it: set reasonable expectations for your content strategy pilot project. (Pilot light photo: iamNigelMorris, flickr.)

Despite the best planning in the world, you will hit a snag or two as you roll out your new content strategy in the pilot project. Consider the project a proof of concept, which you adjust when the reality of implementation doesn’t end up quite matching your plans.

Your schedule should have slack to compensate for the inevitable hiccups. If the content developed in your pilot project has an aggressive deadline, you’ve probably picked the wrong content—which leads to my next suggestion.

Follow the lead of Goldilocks for choosing pilot content

Take the Goldilocks approach and pick content that’s “just right.” You don’t want something super-crucial that needs to be out the door ASAP, but you don’t want to pick content that receives little attention, either. Instead, pick something in the middle, if at all possible.

The same advice goes for the amount of content. Pick an amount of content that pilot team members can handle without being overburdened, but don’t restrict the content to a miniscule amount that will have little impact.

Also, if the project includes content from multiple departments, make sure that one type of content isn’t overemphasized. You can’t necessarily go by page count—user guides in the tech comm department are usually bigger than the brochures created by the marketing group, for example—so gauge content types in other ways. For example, use the current makeup of content as a rough guide: xx% is tech comm, yy% is training, and zz% is marketing, so the pilot content should reflect similar percentages. You could also consider the effort involved in developing the various content types.

In summary, moderation is the key when choosing your pilot project’s content.

You can’t include everybody in the pilot project

You can’t fit all of your content into a pilot project, and you can’t include every employee, either. Employees with skills in the new toolset are sensible candidates, as are those who are interested in learning new things and understand how the new processes support the company’s overall business goals. Make sure you include employees from all of the departments that are involved in the content strategy.

Consider including skeptics with somewhat open minds. They can be a great advocates for the new processes if the pilot project goes well and the content strategy is adopted for additional content. However, you’re better off not including someone who is completely resistant to change. You don’t need that kind of drag on your project—you have enough challenges as it is.

Even though not every employee will be actively involved in a pilot project, communicate constantly with everyone who will be affected by the new content strategy when it’s applied to more content later. Be truthful. Glossing over rough patches is not advisable; instead, explain a problem and detail your planned solution to overcome that challenge. Be open to input from people outside the pilot team because they may have ideas that could be very helpful in solving your issue.

A successful pilot project is key to a successful content strategy. My recommendations are:

  • Don’t be too ambitious with your goals.
  • Be ready to make changes when things don’t work out.
  • Keep the lines of communication open.

Have your own tips (or horror stories) for pilot projects? Leave them in the comments.

Managing DITA projects (premium)

July 11, 2014 by

A DITA implementation isn’t merely a matter of picking tools. Several factors, including wrangling the different groups affected by an implementation, are critical to successfully managing DITA projects.

Note: This post assumes you have already done a content strategy analysis, which determined the DITA standard supports your company’s business goals.

Wrangling people

Good content addresses its audience at the right level. During a DITA implementation, you must do the same when working with the different groups affected by the DITA project. Talk to them about their particular concerns and requirements in language they understand.

circus tent

Managing DITA projects is a lot like running a three-ring circus (flickr: Nathan King)

For example, engineers who occasionally provide bits of content don’t care about all the fancy features of the XML authoring tool used by the tech comm group. The engineers are far more interested in contributing content as quickly and easily as possible (through a simple web interface, perhaps). Also, engineers will understand the value of DITA’s topic-based, modular approach when you compare DITA to object-oriented programming.

Content modeling

Even though you’ve chosen the DITA standard as your XML model, you still have to do content modeling. You can start by creating a spreadsheet cataloging the tags in your current template and then list out the DITA equivalents. Seeing how existing information works in DITA is a good way to learn the DITA structures—but be careful not to focus exclusively on how you created content in the past. You probably didn’t follow DITA best practices in your old content, so be aware of what you may need to change—or throw out altogether—to develop quality DITA content.

You also need to figure out how to track metadata—data about your data. In DITA, much of your metadata goes into element attributes. You can use those attribute values in many ways, including filtering what content does and does not go into output (conditional text), narrowing your searches of DITA source files, and including processing instructions for particular forms of output (for example, the IDs for context-sensitive help).

Metadata isn’t just at the topic or paragraph level, either; you need to think about its application at the map file level. (The map file is what collects topics together for an information product such as a PDF book, a help set, an ebook, and so on.) In map files, there are elements expressly for tracking publication-level information: publication date, version, release, and so on. Don’t fall into the trap of thinking metadata = attribute.

There are other content modeling considerations. Do you need to create a new element or attribute type through the process of specialization (creating a new structure based on an existing one)? Also, how are you going to use special DITA constructs, such as conrefs (reusing a chunk of text by referencing it) and keywords (variables for product names and other often-used words and phrases)?

Evaluating tools

Choosing a tool is not a content strategy. Choosing tools that support DITA does not mean you have a DITA strategy.

Ensure those evaluating tools aren’t suffering from “tool myopia.” They should not use their current tool’s capabilities as benchmarks for a new tool, particularly when a group is moving from a desktop publishing tool to an XML editor.

Also, tool requirements go beyond primary content creation. Think about the entire workflow; get input from all the groups affected by your DITA implementation, and remember that a tool for one group may not be a good fit for another.

Create a weighted spreadsheet so that the really important requirements get precedence during ranking. Also, you don’t have to limit your requirements to “yes or no” questions. If necessary, create short narratives that explain specific use cases and ask vendors to demonstrate how their tool supports those use cases.

Parse vendor claims carefully. Ask specific questions about a tool’s support of DITA constructs: How does your tool support the use of conrefs? If you’re not comfortable with the answers you get from a vendor during the evaluation process, you’ll continue to be uncomfortable (and unhappy) after you purchase a tool from them.

Strongly consider involving a third-party consultant (yes, Scriptorium!) in developing requirements and vetting vendors. The consultant can help you cut through the bunk and also act as the “bad cop.”

Understanding outputs

Default outputs (PDF, HTML, and help) generated from the DITA Open Toolkit are hideous—but fixable. Don’t be scared off by the ugliness of default output, and don’t let project naysayers use the default formatting as a cudgel: See, we can’t use DITA because the Open Toolkit doesn’t create decent output!

Take a software development approach to your outputs. For PDF content, you can create requirements that specify the formatting for different heading levels, admonishments, body paragraphs, steps in procedures, tables (both for table formatting itself and the text in the table), and so on. If you want to re-create what you have in a template file for your current text processing tool, you can take all the formatting aspects (font, line spacing, indent, color, and so on) from it. Detailed specs are going to make it easier to modify the stylesheets that transform your DITA XML into PDF, HTML, and other outputs.

Get significant budget for modifying the transformation stylesheets. PDF transforms are the most complex and expensive; transforms for web pages, ebooks, and so on may run less, but that depends on their complexity. Even if you have transform experience in house—and most companies don’t—you still need to block off that person’s time, and that is an expense as well.

Considering conversion

Before you even think about conversion, research DITA best practices. Reading the DITA spec won’t help you with that. Instead, get a book such as The DITA Style Guide (download the free EPUB edition) that offers advice on the best ways to implement the many elements and features in the DITA model.

If your legacy content is not tagged consistently and has lots of formatting overrides, you cannot convert that content cleanly through scripting. Also, if your content is not easily broken into chunks that are the equivalent of DITA topics, you may be better off just starting over.

Even if you’re not going to convert legacy information, you still need content to test your DITA model and the transforms for output. Create what I call a “greatest hits collection” of DITA files that represents real-world content you create and distribute. I’d recommend 50 to 100 pages of content to be sure you’re thoroughly testing your processes and outputs.

I have yet to see a conversion project completed without some sort of complication: there is going to be bad tagging, layout quirks in your source, or some other lurking horror that will pop up. Resign yourself to dealing with these surprises, and give yourself lots of lead time so you can handle those issues.

Read more tips on converting legacy content to DITA.

Have questions about managing your DITA project? Contact us. Also, watch this recording of my webcast on DITA implementations:

 

 

From soccer balls to content strategy: the kick of change resistance

June 10, 2014 by

Your content strategy can learn a lot from soccer ball manufacturing plants in Sialkot, Pakistan.

The town produces 40 percent of the world’s soccer balls, and it’s now in fierce competition with other Asian companies eating away at Sialkot’s dominance in the soccer ball market.

soccer ball being kicked

Yes, a soccer post just before the World Cup (flickr: Michael Johnson)

When economists offered the plants technology to decrease the amount of wasted synthetic leather, they thought the plants would jump on the chance to adopt the innovation and save money.

Wrong!

 

“I told the owner that it’s not going to work,” says Mohammed Iqlal Urfnana, a worker at one of the soccer ball firms. He is a cutter, meaning he operates a die-press to cut out the hexagons and pentagons that are sewn together to make a soccer ball. Like many workers, Urfnana didn’t like the new die. “For us cutters, this means lower daily wages.”

That’s because Urfnana, like most cutters in Sialkot, is paid by the piece. Learning how to use the new die would slow him down, so he would make fewer pieces and therefore less money. While it was in the factory’s interest to save money by cutting the fake leather more efficiently, it was not in the worker’s interest.

Change resistance has a long, storied history of wrecking innovation in the workplace—whether it be in soccer ball manufacturing or in the creation and distribution of content. Workers become accustomed to The Way Things Are (TWTA), and talk of higher corporate profits isn’t an enticement for those doing the work to change TWTA.

In the case of the soccer balls plants, the economists offered a bonus for workers who learned about the new die. That incentive realigned the workers’ self-interest (money) with the company’s goals to reduce wasted leather. With the bonuses in place, about half of the plants implemented the new die system.

Despite the fact that money talks (and quite loudly), I’m not recommending paying content creators bonuses to learn about the tools and processes for a new content strategy. Staffers in tech comm, marketing, and support departments aren’t usually paid on a per-topic or per-paragraph basis, so that model doesn’t make sense.

However, there are other ways to gain support for new processes. Employees are often concerned about productivity loss when changing tools —reduced productivity usually means late nights at the office to meet deadlines. Simple gestures (ordering in food during those long workdays, for example) can make a huge difference in workers’ perceptions. It’s also unfair to hold employees accountable for hitting productivity benchmarks during process change, so give content creators time to adjust to new systems before calculating metrics and using them in performance evaluations.

Further mitigate change resistance by pinpointing and communicating the value of change for all the different groups affected by proposed process modifications. For example, if there is manual drudgery that everyone in a particular department hates, ensure the new process automates those tasks. Making unpleasant things go away is powerful force in gaining support. You should also offer training and establish strong communication channels for addressing inevitable pushback.

Forcing process change from the top just doesn’t work. You must align the company’s goals with workers’ self-interest. Otherwise, your strategy will end up in tatters—like scraps of synthetic leather swept from the floors of soccer ball factories.

 

Beware the monster of change management: THE MAGNIFIER

April 15, 2014 by

For his 1959 horror movie The Tingler, director/producer William Castle had movie theater seats rigged with buzzers to scare moviegoers during a scene when the Tingler creature is loose in a theater. Patrons in those seats probably didn’t enjoy the jolt—or making a spectacle of themselves because of the Tingler’s “attack.”

If you’re managing the implementation of new processes and tools as part of your job, you’re in a hot seat of your very own—and you need to be on the lookout for another horrifying monster: THE MAGNIFIER.

Poster for The Tingler showing a chair and the words, Do you have the guts to sit in this chair?

Poster for The Tingler (Columbia Pictures)

When you’re determining how changes will support corporate goals and calculating the potential return on investment (ROI) for process improvements, it’s easy to get caught up in the excitement generated by the positive things that new processes and tools will bring.

But don’t be lulled into a false sense of security by all the goodness. Lurking in the darkness is the Magnifier, and it will pounce on you if you let your guard down.

So, what is the Magnifier? It’s a phenomenon I’ve witnessed again and again on process implementations: the very act of process change can magnify existing personnel problems in an organization.

For example, if employees do not have a significant understanding of the company’s products and goals, they may create a lot of busy work to mask their lack of domain knowledge. When it comes time to update processes, “busy worker bees” want the details of their unimportant work codified as part of the new processes to make themselves relevant and indispensable (at least in their own minds) in the new workflow. These employees are less interested in the company’s goals than saving their own skins, and that trait becomes even more evident in times of change.

Employees with control issues are highly inflexible and want everything done their way. During process change, they will take a “my way or the highway” approach. For example, if they are dead set on a particular tool set, they will sandbag the tool selection process by exaggerating the feature set of their favored tool and by overemphasizing “problems” with other tool solutions.

Before you think I’m wallowing in unproductive negativity here, please understand I have witnessed the preceding poor behavior on multiple consulting projects (and I’m not even close to cataloging all the bad stuff I’ve seen). As the manager of a process change project, you must be prepared to fight the Magnifier. Effective weapons against it include:

  • Outlining clear business goals for process change. If a proposed tool or process does not support the company’s end goals, it should not be part of the solution.
  • Establishing clear communication among all parties. Start the communication channels up early as possible, and involve everyone, even those who are indirectly affected by the process changes. The company’s business goals should be front and center as part of all change-related conversations. As the project manager, you need to differentiate between legitimate concerns and outright recalcitrance during conversations. Pushback from others can help you identify weaknesses in the proposed workflow that you had not considered.
  • Hiring a consultant, even just part-time. A consultant has seen the Magnifier do its evil thing on other projects and can therefore help you locate and dispose of it early—before it does too much damage. Because consultants come from outside the company, many employees give what they say more credence, even if the consultants end up repeating the very things you’ve been saying all along. A consultant can also act as the “bad cop” in unpleasant situations, particularly ones involving personnel changes (detailed in the next bullet).
  • Realizing that successful change management may depend on personnel changes. Implementing new tools and processes is not going to magically transform poor employees into model workers. In fact, bad employees will have a negative impact on process change. If an employee’s recalcitrance is having significantly detrimental effects, consider reassigning them to another project (for example, maintaining the legacy system), placing them on a performance plan, or even terminating their employment. You must weigh the employee’s value to the company against the drag he or she is creating on the project.

Have you fought off the Magnifier in past projects? Please detail your battle scars in the comments below.

 

Tools, the content strategy killers

March 17, 2014 by

Quick! What’s the first thing you think about when you want to change your content strategy (the way you produce and distribute content)? If your answer is “tools,” you’re in good company.

First considering the technical aspects of a project is a common and understandable reaction. However, focusing too much on the tools can be the very thing that kills your content strategy.

Image of Jack killing the giant

Jack killing the giant (from The Chronicle of the Valiant Feats of Jack the Giant Killer, 1845)

Soft—or non-technical skills—are essential to evaluate when you’re hiring new staff. By extension, the non-technical aspects of new processes require your attention, too.

You can implement a rigorous tool selection process and spend a lot of time vetting tools, but those investments are useless if you don’t communicate the value of process change. Getting buy-in from all affected parties means you need to offer tailored messages to the different groups. For example:

  • Executives: increased revenue because of shorter times to market.
  • Middle management: cost reduction through more efficient workflows.
  • Content creators: eliminating tiresome manual chores and learning new skills for career longevity.

Your well-selected tool will make it easier to justify process changes to all parties, but it is not going to introduce itself to the different stakeholders, explain its value to them, or train users.

That’s why your content strategy team’s soft skills—particularly in communication—are as important as the tool itself.