Skip to main content
August 11, 2014

Content strategy failure in ten easy steps (premium)

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.