Keys to content strategy: consultants
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.
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.
About the author
Larry Kunz
Re Rule #2: I agree with you that the client needs to be up-front with reqirements, and that it almost always goes badly when they’re not.
But how do you deal with Rumsfeld Syndrome: when the client doesn’t know what they don’t know? The client might fail to mention that IT doesn’t allow SaaS, or we need to support WordStar, or whatever — because they either don’t know, or they have no idea it’s relevant. Do you have a mode of questioning that helps draw out this kind of information during the discovery stage?
Sarah O'Keefe
Hi Larry, good question. We try to extract the relevant information in interviews; IT is always on our list of key stakeholders. What’s troublesome is when (in your example), the IT group doesn’t tell us about the SaaS issue. We ask, “Are there any limitations on software; for example, do you allow SaaS software? What about open source software?” Response: “No problem.” What’s more common, though, is an obscure, unusual requirement. For example, we ran into some trouble years ago because we needed a specific (unique) plugin, which was made by a vendor in a “sensitive” country. Our government-affiliated client was extremely concerned about installing software that originated outside the United States. Some companies will either outright refuse to use open source software, or insist on lengthy license reviews before authorizing it. These situations can destroy project timelines, so it’s important to uncover them. A little trust goes a long way in ensuring that we find out about these constraints early in the project.
Al
the art in #3 is making the client feel their problem is special while basically using the framework to manage the approach. Kinda like using frozen chicken to create great homemade fajitas.
Matt Sullivan
Mmm…fajitas! The client failed to mention those as well!