Scriptorium Publishing

content strategy consulting

Fall 2014 Scriptorium conference round-up

August 25, 2014 by

We have a full schedule of stellar conferences coming up this fall. We hope to see you at one or more of these events.

Let’s start with the big news. You should be able to recognize us at these events, as we have finally updated our web site photos and profiles. Yes, after only six years, we took some new portraits.

Lavacon: Bring on the zombies

That’s probably not the official conference theme (and we hope it’s unrelated to the photo news), but Bill Swallow is presenting Content Strategy vs. The Undead, and Alan Pringle will be at the Scriptorium booth talking about content strategy—and handing out chocolate (of course). Come very early and there might be a few donuts.

October 12-15, Portland, Oregon

Lavacon conference web site

Information Development World

At IDWorld, Sarah O’Keefe is presenting Risky Business: The Challenge of Content Silos. Gretyl Kinsey will be at the booth with chocolate. No word on whether there will be any reenactments of famous movie scenes.

October 22-24, San Jose, California

IDWorld conference web site

tekom/tcworld

Sarah and Alan will team up for a workshop on Adapting Content for the US Market.

November 11-13, Stuttgart, Germany

tekom/tcworld conference web site

Gilbane Conference

Sarah will be participating on a content strategy panel.

December 2-4, Boston, Massachusetts

Gilbane Conference web site

 

As always, we are delighted to meet with you at any time. Contact us to set up a meeting, or just find us during an event and introduce yourself.

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 failure in ten easy steps (premium)

August 11, 2014 by

Here’s how to ensure content strategy failure in ten easy steps. Follow these steps to guarantee that your project disintegrates in spectacular fashion. The top three are:

  1. Pick your tools first.
  2. Don’t talk to stakeholders.
  3. Make bad assumptions.

1. Pick your tools first.

Do you know what your strategy is? Do you understand your business? Have you thought about the implications of AwesomeSoftware™ over the next five years? No? Great, let’s use AwesomeSoftware. After all, their salespeople bought us a nice dinner, and they’re fun to drink with. What could possibly go wrong?

When content strategy = pick a tool, the results will be craptacular.

Content strategy failure occurs when you aren't prepared. // flickr: zachd1_618

Content strategy failure occurs when you aren’t prepared. // flickr: zachd1_618

2. Don’t talk to your stakeholders; they make projects more complex.

Stakeholders can offer project support and critical information. They may also have biases. You need to garner their support, understand their biases, and make sure that you extract every last drop of intel from them.

If you don’t talk to stakeholders, your project will be much simpler—and unlikely to work in the real world.

The more stakeholders you talk to, the more requirements you have to balance. If the requirements are in direct conflict, get your stakeholders together to discuss their priorities.

3. Make bad assumptions, especially based on stereotypes.

Some engineers are good writers.

Some marketing people like technology.

Some technical writers like to socialize.

Some CEOs are more interested in high quality products than cost savings.

The list could go on forever. We all carry biases and stereotypes around. Sometimes, we call them “work experience.” I’ve met a few 60-somethings who are just trying to glide into retirement, but they are the exception not the rule. I’ve also met unmotivated 20-somethings. You need to assess skills, motivation, and learning aptitude of the team members, but don’t assume based on demographics.

In addition to stereotyping people, there is a temptation to stereotype organizations by industry. For example:

  • Government agency = slow and out of date
  • Software company = quality doesn’t matter; only speed matters
  • Heavy machinery = not interested in new technology

Some organizations resemble these stereotypes, but we have also worked with organizations that blow these assumptions out of the water. Nimble government agencies doing awesome things. Software companies that are focused on quality rather than cost and velocity. Heavy machinery companies that are producing innovative content using cutting-edge technology.

People and projects will surprise you. Be ready for it.

4. Ignore people who challenge your assumptions.

You know that naysayer? The one who insists that [whatever] is a terrible idea and will never work? Ignore her at your peril. Your naysayer may be an enormous annoyance, but she is probably expressing concerns that are held by more politically savvy members of the organization. There’s also a significant chance that her objections are valid.

Pay attention when you get resistance to your plans. Do your research and make sure that you address valid objections. Don’t allow your enthusiasm to blind you to the possibility that you have not chosen the right approach. Content strategy failure is likely when the general approach is “Damn the torpedoes, full speed ahead!” (Although, admittedly, that worked for Admiral Farragut.)

At some point, we go from “challenging assumptions” to “sheer obstinance.” It’s important to recognize the difference.

5. Take vendor demos as gospel truth.

Panda cub stuck halfway up tree

Can your tool do what you need? // flickr: bootbearwdc

The purpose of a vendor demo is to tell a compelling story that sells the product. You can learn a lot from vendor demos by paying attention to points of emphasis and the overall structure of the demo:

  • Are there lots of “corporate overview” slides before you get to an actual hands-on demo? This is a well-established company that wants you to perceive them as a safe choice. They probably have a small upstart competitor, perhaps with better technology.
  • Is the demo incredibly detailed and technical? This is probably a smaller company that has great technology. Make sure you ask about technical support and corporate structure.
  • Did the vendor avoid a particular topic area? Their solution is probably not as good in this area. Either put them on the spot by asking about that feature, or follow up later.
  • Does the presenter tell you that a particular approach is a bad idea? This means that a) the vendor’s solution doesn’t work well with that approach, b) that approach is a universally bad idea, or c) both. Figuring out when the answer is (a) is a critical skill for the buyer.
  • How interesting and informative is the person leading the demo? He is probably the person in the vendor organization who is the best at communicating with customers (because, after all, he is involved in sales). You can assume that the technical support person will be no better than what you are seeing in the demo. (In other words, if the demo is terrible, expect lousy technical support in the future.)

Ask the vendor to demonstrate using samples that you provide. This helps you to see whether the solution would work for your information or is mainly functional when working with a highly restricted set of sample information.

A demo is a best-case scenario.

6. Ignore corporate culture.

Corporate culture constrains possibilities. A cautious organization with many layers of approvals will not succeed with a strategy that requires quick action. A startup culture that prizes creative thinking and cheap solutions will reject a months-long implementation effort.

If you ignore the corporate culture, you have the freedom to choose a solution that, on paper, looks like a good option, but that will fail because it’s incompatible with the organization. Think of it like an organ transplant. You have to match the solution (the donor organ) to the recipient, or Bad Things will happen.

Take the time to understand the corporate culture, especially if you are new to the organization. Who really makes decisions? Very often, it’s not the person at the top of the organizational chart—it’s the trusted lieutenant. How do different departments in the organization interact? How do employees in different locations work together? Is there a hierarchy of locations (for instance, people at corporate HQ always win), or is there a department that has the ability to get things done? Was there a merger, and how are the people from the two sides of the merger treated? Is one side more influential than the other? Is there ongoing resentment about how the merger was handled? (Hint: Yes.)

7. Pick a solution and then look for a problem.

Perhaps you used a certain tool in a previous job? Perhaps that software was awesome? By all means, let’s use that option. Or maybe you’ve decided that XML is really cool. Why not push your organization to use XML?

No. No. Ten thousand times no.

Define the business problem first, then pick the solution. “I hate working with (or without) AwesomeSoftware” is not a business problem.

8. Allow IT to choose the solution while ignoring content creators.

traditional rock climbing rope and caribiner

Choose your tools carefully; your project success depends on them // flickr: iwona_kelly

Especially in larger companies, the IT organization is waterboarded when they fail to strongly encouraged to limit the number of software systems. As a result, your request for a specialized system will be met with suspicion. Why can’t you just use the default option?

In extreme cases, you will be told that you must use the default option. This is very often an enterprise document management system, which may or may not fit your needs. (Probably not.)

IT’s focus on limiting software is supposed to control overall IT costs. If the IT-recommended software doesn’t meet your content strategy requirements, then you must show a cost-benefit analysis. What are the benefits of the proposed (non-IT-approved) solution? Do these benefits outweigh the cost of configuring, supporting, and maintaining the solution?

9. Allow content creators to choose the solution while ignoring IT.

An IT-imposed solution is one extreme. At the other extreme, we find content creators making decisions based on their personal biases.

A former manager was an enormous typesetting geek, so now the content creators have a workflow that includes fine manual kerning. Does kerning add value? Will customer notice if kerning stops? Is support for sophisticated manual kerning a critical requirement?

What if “sophisticated kerning” rules out solutions that are otherwise a good fit?

Beware of content creators who advocate for a solution solely because it is the least disruptive option—for them. Again you must ask, does the solution meet the overall requirements?

10. Refuse to change.

“We’ve always done it that way.”

Content strategy failure is assured when new initiatives are met with the requirement that any new approach to content must preserve all of the weirdest features of the current approach.

Learn to identify change resistance masquerading as project constraints.

 

The best way to avoid content strategy failure is to bring Scriptorium as a consulting partner. Contact us today.

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:

DITA content strategy

July 28, 2014 by

How can you implement DITA content strategy? Is DITA itself a content strategy?

Map with dotted line indicating travel from source to destination.

Identifying your business goals is the key to content strategy

The answer is a resounding no. DITA is an architecture. DITA and content strategy are related, but “we use DITA” is not a content strategy. The content strategy process goes something like this:

  1. Identify your business goals. (Examples: “efficiently create information required by our regulators to sell our product” or “increase market share in Europe”)
  2. Based on your business goals, establish a content strategy. (Example: “deliver content in local language for European markets at the same time English is ready”)
  3. Based on the content strategy, establish requirements for your content lifecycle.
  4. Identify the constraints.
  5. Based on the requirements and constraints, identify a solution for developing, deploying, and delivering your content. (DITA is a possible solution.)

Although I strongly encourage you to start with strategy, I do know that DITA is a strong contender if you have the following requirements:

  • Topic-based authoring
  • Localization
  • Reuse
  • Lots of output formats

DITA has advantages and disadvantages. Here are a few:

DITA advantages

DITA is a good fit for typical technical communication requirements. It is an open standard and has significant vendor support.

DITA disadvantages

For many organizations, DITA is a huge change, so we have change management concerns. There are also writing challenges (modular content is harder than you might think) and technical challenges. The technology stack required to get output from DITA is not for the faint of heart.

Is DITA right for you?

Scuba divers

Once you have requirements and constraints, you can assess whether DITA makes sense for you. Image: NOAA

It might be. It might not be. Before asking about DITA content strategy, make sure that you have built your content strategy requirements. Need help? Contact us.

 

I did a DITA Content Strategy webcast as part of the 2013 easyDITA RockStar Summer Camp series.

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.

Webcast: The many facets of content strategy

July 16, 2014 by

In this webcast recording, Sarah O’Keefe discusses the future of content strategy.

The purpose of content strategy is to support your organization’s business goals. Content strategists need to understand how content across the organization—marketing, technical, and more—contributes to the overall business success.

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:

 

 

Keys to content strategy: consultants

July 8, 2014 by

Are you thinking about engaging a content strategy consultant? Here are some thoughts on successful content strategy consulting relationships.

Over at easyDITA, Stephen Morse wrote a great post about determining whether you need a DITA consultant:

A consultant can help you define where you want to go, then recommend the right people, process and technologies to ensure you reach your destination.

But that’s just the beginning. Once you decide that you need a content strategy consultant (or DITA consulting), then what? How do you make sure that your project is successful?

Rule #1. Understand your consultant’s scope of expertise.

The best consultant is the one who has deep expertise in your type of problem. Here at Scriptorium, we specialize in content strategy for technical content. If you need to deliver lots of content in many languages and diverse output formats, we can help you. Approximately 80 percent of our work revolves around XML and structured content; the rest is mostly unstructured FrameMaker. Need help with SEO? Look elsewhere.

Rule #2. Content strategy consultants have limited psychic abilities.

Zelda the fortune-telling dog with a crystal ball, just like a content strategy consultant

Content strategy consultants have limited psychic abilities // flickr: aussiegall

One of the most frustrating things that happens in our day-to-day work is that we carefully construct a recommendation, which is then shot down with a casual, “Oh, we can’t do that because of <REDACTED>.” <REDACTED> is nearly always important information that we should have had before we even started our work.

For example:

Client: Figure out the best solution for X.

Us: What are the constraints for X? Budget? Expense? Timing? What features are critical?

Client: A, B, and C.

Us (much later): We recommend solution S. It addresses A, B, and C in these ways.

Client: Oh, no, that won’t work. We can’t do that because (IT doesn’t allow SaaS | our CEO loves Word | our CEO hates purple | did I mention that we need to support WordStar?).

Rule #3. You are special. Your problem is not.

Over our (many) years of consulting, we have identified common problem patterns, like this one:

Our system worked fine, but now we have to scale up with lots of languages and/or lots of output formats. We cannot scale our current approach.

If your basic problem is scalability (or lack thereof), we know that we have a certain set of levers we can use, such as:

  • Automated formatting
  • Rigorous use of style guides
  • Consistent terminology

These items are the starting point for solving a scalability problem. We then add your unique content and organizational requirements to the mix to develop the right solution for you.

Rule #4: We need to trust each other.

When you bring in a consultant, you are taking a leap of faith. A great consultant will help you succeed, and all will be well. On the consulting side, we are also taking a leap of faith. Our business is built on our reputation, and a bad project will affect our reputation.

We understand the difficulty of establishing trust. Scriptorium does not resell CCMS or other software or receive referral fees from software vendors. This helps us to align our interests with our clients—our success depends on providing a good recommendation, not on referral income. Some of our projects last for years—we want to enjoy working with you and you with us. The alternative is a dreary implementation slog. So trust and a strong working relationship are critical to working with a content strategy consultant like Scriptorium.

 

Consultants: What are your rules for consulting success?
Clients: What do you need from your consultant?
Tell us in the comments.

Keys to content strategy: aligning expectations

June 24, 2014 by

An effective content strategy requires participation (preferably enthusiastic) from a diverse array of people. When you are communicating with executives, IT specialists, marketing writers, translation coordinators, and more, recognize that each participant (including you) begins with a certain set of expectations and biases.

For example, consider the proof of concept stage. What are the expectations for the proof of concept?

  • Engineers: show that something is technically feasible.
  • Marketing: show that we can produce something comparable to the highly designed content we produce now.

In one project, this mismatch of expectations caused huge problems. The question was something like, “Can we produce InDesign output from XML?” The answer, from the software side, was yes. But the proof-of-concept InDesign file was, let us say, aesthetically challenged. The marketing team looked at the very unattractive output and was ready to veto the entire workflow.

Hippopotamus: The HiPPO is the key to content strategy success

Don’t forget about the HiPPO!
flickr: frank_wouters

We have to have extreme clarity on the proof of concept. Are we showing the best-case scenario? “We created some initial output, and cleaned it up for the demo.” Are we showing the initial default output? “It’s ugly, but we can fix the formatting later; the technology works.” And most importantly, have we communicated those expectations or limitations to the people looking at the information?

Team members who are very visually oriented (most marketing and design staffers) need to see attractive demos. Team members who are very process-oriented (often IT and tech comm) need to see demos that promise efficiency. It’s also important to address not the elephant in the room, but the HiPPO—the Highest Paid Person’s Opinion.

Is it acceptable to spend six months on a proof of concept that simply moves your current PDF look and feel onto another production system? Do you need quick wins to keep momentum (and funding) going? How soon will legacy content move to the new system, or will it be updated in the old system?

If these assumptions and expectations are not aligned across the team, you are going to have some big project problems.

Other posts in the keys to content strategy series